android - 音频延迟问题

Question

在我要创建的应用程序中，我遇到了一些技术障碍。我在应用程序中有两个音乐轨道。例如，用户导入音乐背景作为第一轨道。第二条路径是用户根据扬声器设备(或耳机)播放的第一首轨道的节奏录制的语音。此时我们面临延迟。在应用中录制和播放后，用户会听到音轨之间失去同步，这是由于麦克风和扬声器延迟造成的。

首先，我尝试通过过滤输入声音来检测延迟。我使用 android 的 AudioRecord 类和方法 read()。此方法用音频数据填充我的短数组。 我发现这个数组的初始值为零，所以我决定在开始将它们写入输出流之前将它们剪掉。 所以我将这些零视为麦克风的“预热”延迟。这种方法正确吗？这个操作给出了一些结果，但并没有解决问题，在这个阶段，我离那个还很远。

但更糟糕的情况是启动扬声器和播放音乐之间的延迟。我无法过滤或检测到这种延迟。我试图创建一些计算延迟的校准功能。我通过扬声器播放“哔”的声音，当我开始播放时，我也开始计算时间。然后，我开始录音并聆听麦克风检测到的声音。当我在应用程序中识别出这个声音时，我会停止测量时间。我重复这个过程几次，最终值是这些结果的平均值。这就是我尝试测量设备延迟的方式。现在，当我有这个值时，我可以简单地将第二条轨道向后移动以实现两个记录的同步(我会丢失一些最初的录音毫秒数，但我跳过这种情况，目前，有一些可能性可以修复它) . 本来以为这样就可以解决问题了，结果发现并没有想象的那么简单。我在这里发现了两个问题: 1.同时播放两个轨道时延迟 2. 设备音频延迟随机。

第一个:我使用 AudioTrack 类播放两个轨道，然后像这样运行方法 play():

val firstTrack = //creating a track
val secondTrack = //creating a track

firstTrack.play()
secondTrack.play()

此代码会导致播放轨道的阶段出现延迟。现在，我什至不必考虑录制时的延迟问题；我无法无延迟地同时播放两首轨道。我用一些外部音频文件(未记录在我的应用程序中)对此进行了测试 - 我正在使用上面的代码启动相同的音频文件，我可以看到延迟。我也用 MediaPlayer 类尝试过，结果相同。在这种情况下，我什至尝试在调用回调 OnPreparedListener 时播放轨道:

val firstTrack = //AudioPlayer
val secondTrack = //AudioPlayer

second.setOnPreparedListener {
  first.start()
  second.start()
}

这并没有帮助。 我知道Android 还提供了一个类SoundPool。根据文档，同时播放轨道会更好，但我不能使用它，因为它只支持小音频文件，这不能限制我。 我该如何解决这个问题？如何同时精确地开始播放两条轨道？

第二:音频延迟不是确定性的 - 有时它更小，有时它很大，而且它不在我的控制范围内。因此，测量设备延迟可以提供帮助，但同样无法解决问题。

总结一下:是否有任何解决方案可以为我提供每个设备(或应用程序 session ？)的准确延迟或检测实际延迟的其他触发器，以便在同时播放两个轨道时提供最佳同步？

提前致谢!

Answer 1

为卡拉 OK 应用同步音频很困难。您似乎面临的主要问题是输出流中的可变延迟。

这几乎可以肯定是由“预热”延迟引起的:从在背景音轨上点击“播放”到音频设备(例如耳机)呈现第一帧音频数据所花费的时间。这可能有很大的差异并且难以测量。

要尝试的第一个(也是最简单的)事情是在构造您的 AudioTrack 时使用 MODE_STREAM 并在开始之前用 bufferSizeInBytes 数据对其进行填充调用播放 ( more here )。这应该会导致更低、更一致的“预热”延迟。

更好的方法是使用 Android NDK有一个连续运行的音频流，它只是输出静音，直到你点击播放的那一刻，然后立即开始发送音频帧。这里唯一的延迟是连续输出延迟。

如果您决定走这条路，我建议您查看 Oboe library (完全披露:我是作者之一)。

回答您的一个具体问题...

有没有办法以编程方式计算音频输出流的延迟？

是的。解释这一点的最简单方法是使用 code sample (这是用于 AAudio API 的 C++，但使用 Java AudioTrack 的原理是相同的):

// Get the index and time that a known audio frame was presented for playing
int64_t existingFrameIndex;
int64_t existingFramePresentationTime;
AAudioStream_getTimestamp(stream, CLOCK_MONOTONIC, &existingFrameIndex, &existingFramePresentationTime);

// Get the write index for the next audio frame
int64_t writeIndex = AAudioStream_getFramesWritten(stream);

// Calculate the number of frames between our known frame and the write index
int64_t frameIndexDelta = writeIndex - existingFrameIndex;

// Calculate the time which the next frame will be presented
int64_t frameTimeDelta = (frameIndexDelta * NANOS_PER_SECOND) / sampleRate_;
int64_t nextFramePresentationTime = existingFramePresentationTime + frameTimeDelta;

// Assume that the next frame will be written into the stream at the current time
int64_t nextFrameWriteTime = get_time_nanoseconds(CLOCK_MONOTONIC);

// Calculate the latency
*latencyMillis = (double) (nextFramePresentationTime - nextFrameWriteTime) / NANOS_PER_MILLISECOND;

注意事项:此方法依赖于音频硬件报告的准确时间戳。我知道这适用于 Google Pixel 设备，但听说它在其他设备上不太准确，所以 YMMV。