根本原因是缓冲区（bufferSize）设置过大导致数据堆积，双缓冲机制使数据写入后需等待缓冲填满或触发阈值才发声；低延迟目标应控制在50ms内，对应缓冲≈sampleRate×bytesPerFrame×0.05，并需实测验证底层采纳情况。
Java 中 SourceDataLine 播放音频出现明显延迟，根本原因通常是缓冲区（bufferSize）设置过大，导致数据堆积、播放滞后。这不是代码写错了，而是默认配置没适配实时性需求。
为什么增大 bufferSize 反而增加延迟？
SourceDataLine 的缓冲区是“双缓冲”结构：应用往其中写入数据，音频子系统从另一端读取并输出。缓冲区越大，系统能容忍的处理抖动越强，但代价是固有延迟升高——数据写入后要等整个缓冲区填满或触发播放阈值才会真正发声。
常见误区是认为“大缓冲更稳”，实际在语音通话、音效反馈、MIDI 响应等场景下，必须牺牲部分鲁棒性换取低延迟。
- 默认
AudioFormat下，DataLine.Info返回的推荐缓冲大小常为 1–2 秒（如 44100Hz × 2 字节 × 2 秒 ≈ 176KB），远超必要 - 真实低延迟目标应在 50ms 以内，对应缓冲大小 ≈
sampleRate × bytesPerFrame × 0.05 - 过小（如 line.write() 阻塞或丢帧），表现为爆音或中断
如何计算并设置合理的 buffer size？
不能硬编码固定值，需根据采样率、位深、声道数和目标延迟动态算出，并用 AudioSystem.getLine() 尝试获取最接近的支持值。
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
int sampleRate = 44100; int channels = 2; int bitsPerSample = 16; float targetLatencySec = 0.03f; // 30ms <p>int frameSize = channels <em> (bitsPerSample / 8); int bufferSizeInBytes = (int) Math.ceil(sampleRate </em> frameSize * targetLatencySec);</p><p>// 获取 line 时传入自定义 info，而非用 AudioSystem.getRecommendedBufferSize() DataLine.Info info = new DataLine.Info(SourceDataLine.class, format, bufferSizeInBytes); SourceDataLine line = (SourceDataLine) AudioSystem.getLine(info); line.open(format, bufferSizeInBytes); // 显式指定</p>
注意：bufferSizeInBytes 是建议值，底层驱动可能向上对齐（如 4096 字节边界），调用 line.getBufferSize() 确认最终生效值。
write() 调用节奏与 underrun 防御
即使缓冲区设得合理，如果 line.write() 写入不及时，仍会触发 underrun——此时线程阻塞或跳帧，延迟感知反而更差。
- 不要等缓冲区空了再写；保持持续供数，剩余空间建议始终 > 20% 缓冲大小
- 用
line.available()判断可写入字节数，避免盲目write() - 关键路径避免在 write() 前做耗时运算（如解码、滤波），优先用预处理或线程分离
- 首次
line.start()后，前几次 write() 延迟略高属正常，后续应稳定
平台差异与 fallback 策略
Windows（WASAPI）、macOS（Core Audio）、Linux（PulseAudio/ALSA）对最小缓冲支持差异极大。Java 层无法绕过这些限制：
- Windows 上，JDK 17+ 默认使用 WASAPI，最低稳定延迟约 10–15ms；旧版 JDK 或禁用 WASAPI 时可能退化到 100ms+
- Linux 下 PulseAudio 默认缓冲 200ms，需改
/etc/pulse/daemon.conf中default-fragments和default-fragment-size-msec - 务必检查
line.isControlSupported(FloatControl.Type.MASTER_GAIN)等是否可用——不可用常意味着走的是兼容模式，延迟不可控
真正难的不是算出那个数字，而是确认当前 JVM + OS 组合下，你设的 bufferSize 是否被底层音频栈真正采纳。每次变更后，用示波器 App 或音频分析工具实测端到端延迟，比看文档更可靠。
