在 JVM 中长时间录制音频时突然延迟

Question

我正在使用 JDK 版本 8 更新 201 实现一个实时（或至少尽可能接近实时）记录和分析音频的应用程序。在执行模拟测试时在应用程序的典型用例中，我注意到在连续录制几个小时的音频后，突然出现了一到两秒之间的延迟。到目前为止，没有明显的延迟。只是在这个临界点记录了几个小时之后，才开始出现这种延迟。

到目前为止我尝试了什么

为了检查我的音频采样计时代码是否有误，我注释掉了与计时相关的所有内容。这基本上让我有了这个更新循环，它会在音频样本准备好后立即获取它们（注意：Kotlin 代码）：

while (!isInterrupted) {
    val audioData = read(sampleSize, false)
    listener.audioFrameCaptured(audioData)
}

这是我的阅读方法：

fun read(samples: Int, buffered: Boolean = true): AudioData {
    //Allocate a byte array in which the read audio samples will be stored.
    val bytesToRead = samples * format.frameSize
    val data = ByteArray(bytesToRead)

    //Calculate the maximum amount of bytes to read during each iteration.
    val bufferSize = (line.bufferSize / BUFFER_SIZE_DIVIDEND / format.frameSize).roundToInt() * format.frameSize
    val maxBytesPerCycle = if (buffered) bufferSize else bytesToRead

    //Read the audio data in one or multiple iterations.
    var bytesRead = 0
    while (bytesRead < bytesToRead) {
        bytesRead += (line as TargetDataLine).read(data, bytesRead, min(maxBytesPerCycle, bytesToRead - bytesRead))
    }

    return AudioData(data, format)
}

然而，即使没有我这边的任何时间问题也没有解决。因此，我继续进行了一些实验，让应用程序运行使用不同的音频格式，这导致了非常混乱的结果（我将使用 PCM 签名的 16 位立体声音频格式，小端和示例默认为 44100.0 Hz 的速率，除非另有说明）：

在出现延迟之前必须经过的临界时间似乎因所使用的机器而异。在我的 Windows 10 台式电脑上，大约需要 6.5 到 7 小时。然而，在我的笔记本电脑上（也使用 Windows 10），相同的音频格式需要 4 到 5 个小时。
使用的音频通道数量似乎有影响。如果我将通道数量从立体声更改为单声道，延迟开始出现之前的时间在我的桌面上会翻倍，达到 13 到 13.5 小时之间。
将样本大小从 16 位减少到 8 位也会导致延迟开始出现之前的时间加倍。在我的桌面上大约需要 13 到 13.5 小时。
将字节顺序从小端更改为大端没有任何效果。
从立体声切换到物理麦克风也没有效果。
我尝试使用不同的缓冲区大小（1024、2048 和 3072 个样本帧）及其默认缓冲区大小打开该行。这也没有改变任何东西。
在延迟开始发生后刷新TargetDataLine 会导致所有字节在大约一到两秒内为零。在此之后我再次获得非零值。然而，延迟仍然存在。如果我在 临界点之前刷新 行，我不会得到那些零字节。

停止并重新启动 TargetDataLine 延迟出现后也不会改变任何东西。

然而，关闭并重新打开 TargetDataLine 确实消除了延迟，直到它在数小时后重新出现。

每十分钟自动刷新一次 TargetDataLines 内部缓冲区无助于解决问题。因此，内部缓冲区中的缓冲区溢出似乎不是原因。

使用并行垃圾收集器来避免应用程序冻结也无济于事。

使用的采样率似乎很重要。如果我将采样率加倍到 88200 赫兹，延迟开始发生在运行时间的 3 到 3.5 小时之间。

如果我使用我的 "default" 音频格式让它运行在 Linux 下，在运行大约 9 小时后它仍然运行没问题.

我得出的结论：

这些结果让我得出结论，在此问题开始发生之前我可以录制音频的时间取决于应用程序运行所在的机器和字节速率 (即音频格式的帧大小和采样率）。似乎成立（虽然我现在还不能完全确认这一点）因为如果我结合在 2 和 3 中所做的更改，我会假设我可以录制音频样本在延迟开始出现之前使用我的 "default" 音频格式时的四倍长（大约在 26 到 27 小时之间）。由于我还没有找到让应用程序运行这么长时间的时间，我只能说它运行正常了大约 15 个小时，然后由于时间限制我不得不停止它我这边。所以，这个假设还有待证实或否定。

根据要点 13 的结果，整个问题似乎只有在使用 Windows 时才会出现。因此，我认为它可能是 javax.sound.sampled API 的平台特定部分中的错误。

尽管我认为当这个问题开始发生时我可能已经找到了改变的方法，但我对结果并不满意。我可以定期关闭并重新打开线路以避免问题开始出现。但是，这样做会导致我无法捕获音频样本的任意少量时间。此外，Javadoc 声明某些行在关闭后根本无法重新打开。因此，这对我来说不是一个好的解决方案。

理想情况下，这整个问题根本不应该发生。有没有我完全遗漏的东西，或者我是否遇到了 javax.sound.sampled API 的限制？我怎样才能完全摆脱这个问题？

编辑：根据 Xtreme Biker 和 gidds 的建议，我创建了一个小示例应用程序。您可以在 Github repository.
中找到它

Answer 1

我在 Java 音频接口方面有（相当）丰富的经验。以下几点可能有助于指导您找到正确的解决方案：

这不是 JVM 版本的问题 - java 音频系统自 Java 1.3 或 1.5
java 音频系统是操作系统必须提供的任何音频接口 API 的穷人包装器。在 linux 中，它是 Pulseaudio 库，在 windows 中，它是直接显示音频 API（如果我没有记错的话）。
同样，音频系统 API 是一种遗留物 API - 一些功能无法使用或未实现，其他行为很奇怪，因为它们依赖于过时的设计（如果需要，我可以提供示例）。
这不是垃圾收集的问题 - 如果您对 "delay" 的定义是我所理解的（音频数据延迟 1-2 秒，这意味着您会在 1-2 秒后开始听到声音), 好吧，垃圾收集器不能使空白数据神奇地被目标数据行捕获，然后像往常一样在 2 秒的字节偏移量内追加数据。
这里最有可能发生的是硬件或驱动程序在某个时候为您提供了 2 秒的乱码数据，然后像往常一样传输其余数据，导致 "delay" 您正在经历。
它在 linux 上完美运行的事实意味着这不是硬件问题，而是与驱动程序相关的问题。
为了证实这个怀疑，您可以尝试通过 FFmpeg 捕获相同持续时间的音频，看看问题是否重现。
如果您使用的是专门的音频捕获硬件，最好联系您的硬件制造商并询问他您在 windows.
无论如何，在从头编写音频捕获应用程序时，我强烈建议尽可能远离 Java 音频系统。这对 POC 来说很好，但它是一个未维护的遗留物 API。 JNA 始终是一个可行的选择（我在 Linux 和 ALSA/Pulse-audio 中使用它来控制 Java 音频系统无法更改的音频硬件属性），因此您可以查找音频捕获示例在 C++ 中将 windows 转换为 Java。它将为您提供对音频捕获设备的精细控制，远远超过 JVM 提供的 OOTB。如果您想查看 living/breathing 可用的 JNA 示例，请查看我的 JNA AAC encoder 项目。
同样，如果您使用特殊的捕获 harwdare，制造商很可能已经提供了它自己的低级 C api 用于与硬件接口，您也应该考虑看看它.
如果情况并非如此，也许您和您的 company/client 应该考虑使用专门的捕获硬件（不一定是好贵）。

在 JVM 中长时间录制音频时突然延迟

Sudden delay while recording audio over long time periods inside the JVM

java

audio-recording

kotlin

javax.sound.sampled

到目前为止我尝试了什么

我得出的结论：