在JVM中长时间记录音频时出现突然的延迟

Fab*_* B. 16 java audio-recording kotlin javax.sound.sampled

我正在实现一个使用JDK Version 8 Update 201实时(或至少尽可能接近实时)记录和分析音频的应用程序。在执行模拟该应用程序典型用例的测试时,我注意到在连续录制了几个小时的音频后,突然延迟了一到两秒钟。到目前为止,还没有明显的延迟。只是在这个关键的记录点持续了几个小时之后才开始出现这种延迟。

到目前为止我尝试过的

为了检查我用于计时音频样本的代码是否错误,我注释掉了与计时有关的所有内容。这基本上使我离开了这个更新循环,该循环会在音频样本准备好后立即获取它们(请注意:Kotlin代码):

while (!isInterrupted) {
    val audioData = read(sampleSize, false)
    listener.audioFrameCaptured(audioData)
}
Run Code Online (Sandbox Code Playgroud)

这是我的读取方法:

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)
}
Run Code Online (Sandbox Code Playgroud)

但是,即使没有我的帮助,问题也没有得到解决。因此,我继续进行一些实验,并让应用程序使用不同的音频格式运行,这导致了非常混乱的结果(我将使用PCM签名的16位立体声音频格式,其字节序少,采样率44100.0 Hz默认情况下,除非另有说明):

  1. 根据所使用的机器,延迟出现之前必须经过的关键时间似乎有所不同。在我的Windows 10台式电脑上,它大约需要6.5到7个小时。但是,在我的笔记本电脑(也使用Windows 10)上,相同的音频格式大约需要4到5个小时。
  2. 所使用的音频通道数量似乎有影响。如果我将声道数量从立体声更改为单声道,则延迟开始出现之前的时间会在台式机上加倍,介于13到13.5小时之间。
  3. 将样本大小从16位减小到8位也会导致延迟开始出现之前的时间加倍。在我的桌面上的13到13.5小时之间的某个时间。
  4. 将字节顺序从小字节序更改为大字节序无效。
  5. 从立体声混音切换到物理麦克风也不起作用。
  6. 我尝试使用不同的缓冲区大小(1024、2048和3072样本帧)及其默认缓冲区大小打开行。这也没有改变任何东西。
  7. 延迟开始发生刷新TargetDataLine 将导致所有字节为零,持续大约一到两秒钟。此后,我再次获得非零值。但是,延迟仍然存在。如果在临界点之前刷新该行,则不会得到那些零字节。
  8. 延迟出现停止并重新启动TargetDataLine 也不会更改任何内容。
  9. 但是,关闭并重新打开TargetDataLine确实可以避免延迟,直到它在几个小时后重新出现为止。
  10. 每十分钟自动刷新一次TargetDataLines内部缓冲区无助于解决问题。因此,内部缓冲区中的缓冲区溢出似乎不是原因。
  11. 使用并行垃圾收集器来避免应用程序冻结也无济于事。
  12. 使用的采样率似乎很重要。如果我将采样率提高一倍至88200 Hertz,则延迟将开始在3到3.5个小时的运行时间之间发生。
  13. 如果我让它使用“默认”音频格式在Linux下运行,则在经过大约9个小时的运行时间后,它仍然可以正常运行。

我得出的结论:

这些结果使我得出的结论是,在此问题开始发生之前,我可以记录音频的时间取决于运行应用程序的机器,并且取决于音频的字节率(即帧大小和采样率)。音频格式。这似乎保持正确(尽管到目前为止我还不能完全确认这一点),因为如果结合2和3中所做的更改,我会假设我可以录制音频样本的时间是原来的四倍(介于26到200之间)。 27小时),就像在延迟开始出现之前使用“默认”音频格式时一样。由于我还没有足够的时间让应用程序运行这么长时间,因此我只能说,由于时间限制,在不得不停止它之前,它可以正常运行约15个小时。因此,这一假设仍有待确认或否定。

根据项目符号13的结果,似乎整个问题仅在使用Windows时出现。因此,我认为可能是javax.sound.sampled API的特定于平台的部分中的错误。

即使我认为当此问题开始发生时我可能已经找到了改变的方法,但我对结果并不满意。我可以定期关闭并重新打开该行,以免该问题开始出现。但是,这样做将导致我花费很少的时间,而我无法捕获音频样本。此外,Javadoc指出某些行在关闭后根本无法重新打开。因此,对于我而言,这不是一个好的解决方案。

理想情况下,整个问题都不应该发生。我是否完全缺少某些东西,或者我在使用javax.sound.sampled API可能遇到的限制?我该如何摆脱这个问题?

编辑:通过Xtreme Biker和gidds的建议,我创建了一个小示例应用程序。您可以在此Github存储库中找到它。

She*_*gon 6

我在Java音频接口方面有(相当)丰富的经验。以下几点对指导您找到正确的解决方案可能有用:

  1. JVM版本无关紧要-Java音频系统自Java 1.3或1.5以来几乎没有升级
  2. Java音频系统是操作系统必须提供的任何音频接口API的穷人包装。在linux中,它是Pulseaudio库;对于Windows,这是直接显示音频API(如果我没记错的话)。
  3. 同样,音频系统API属于传统API-有些功能无法使用或无法实现,其他行为则很奇怪,因为它们取决于过时的设计(如果需要,我可以提供示例)。
  4. 这不是垃圾收集的问题-如果您对“延迟”的定义符合我的理解(音频数据会延迟1-2秒,这意味着您会在1-2秒后开始收听内容),那么,垃圾收集器不能导致空白数据被目标数据行神奇地捕获,然后像往常一样在2秒内附加字节偏移量的数据。
  5. 这里最有可能发生的事情是硬件或驱动程序在某个时候为您提供了2秒的乱码数据,然后像往常一样流送其余数据,导致您遇到“延迟”。
  6. 它在Linux上完美运行的事实意味着这不是硬件问题,而是与驱动程序相关的问题。
  7. 为了证实这种怀疑,您可以尝试通过FFmpeg捕获音频的持续时间相同,并查看是否重现了该问题。
  8. 如果您使用的是专用音频捕获硬件,则最好与硬件制造商联系,并向他询问您在Windows上面临的问题。
  9. 无论如何,当从头开始编写音频捕获应用程序时,我强烈建议尽可能远离Java音频系统。对POC很好,但它是未维护的旧版API。JNA始终是一个可行的选择(我在Linux中将其与ALSA / Pulse-audio一起使用来控制Java音频系统无法更改的音频硬件属性),因此您可以在Windows中使用C ++查找音频捕获示例并将其转换为Java。它可以使您对音频捕获设备进行更精细的控制,远远超过了JVM提供的OOTB。如果您想看看有生命/呼吸可用的JNA示例,请查看我的JNA AAC编码器项目。
  10. 同样,如果您使用特殊的捕获手段,那么制造商很有可能已经提供了它自己的低级C api来与硬件接口,并且您也应该考虑一下。
  11. 如果不是这种情况,也许您和您的公司/客户应该考虑使用专门的捕获硬件(不必那么昂贵)。