1

在我的 Android 应用程序中，我使用 Oboe 库和 Vorbisfile 库来提取、处理音频样本并将其重定向到音频输出。

为了简单起见，这里是我一直在做的事情的快速概述（在这里使用 hello-oboe 示例）：

oboe::DataCallbackResult PlayAudioEngine::onAudioReady(oboe::AudioStream *audioStream, void *audioData, int32_t numFrames)
{
    // init:
    if (mBufferSizeSelection != kBufferSizeAutomatic && audioStream->getBufferSizeInFrames() != mBufferSizeSelection * mFramesPerBurst)
    {
        audioStream->setBufferSizeInFrames(mBufferSizeSelection * mFramesPerBurst);
    }

    // audio extraction:
    if (audioStream->getFormat() == oboe::AudioFormat::Float)
    {
        // extract audio samples using vorbisfile...
        // put the extracted audio samples in audioData...
    }
    else
    {
        // extract audio samples using vorbisfile...
        // put the extracted audio samples in audioData...
    }
    return oboe::DataCallbackResult::Continue;
}

这段代码在大多数设备上都非常有效（我在 10 多台设备上进行了测试，包括 Galaxy S3 mini 或诺基亚 1 等低端设备），没有任何延迟。

问题是：在某些设备上（Archos 55 Cobalt (API 23) 和 OnePlus One (API 23)），声音很迟钝，特别是如果我同时提取 2 个音频文件（这样我可以同时播放它们），而在诺基亚 1 等功能较弱的设备上，相同的代码也可以正常工作。

我也尝试设置mBufferSizeSelection为 4 甚至 8，但完全没有变化。

有没有人经历过类似的事情？我错过了什么？

谢谢你的帮助。

4

1 回答 1

1

首先，您不应该在音频回调中进行提取和解码，因为这将阻止音频回调，直到发生解码，这将导致持续欠载。

而是在设置流之后（调用之后AudioStreamBuilder::openStream）进行解码。这样，当音频回调发生时，您的 PCM 数据将立即准备好。

其次，您所说的“相当滞后”是什么意思？信号路径中有许多滞后源，包括：

  • 触摸事件到达应用程序所需的时间
  • 如果您从另一个线程启动流，则第一个音频回调开始所需的时间
  • 进行 vorbis 解码所用的时间
  • 音频帧到达音频设备所需的时间
  • 渲染的音频到达扬声器或耳机所需的时间（输出路径上可以有 DSP 以改善声学质量，例如降噪、低音增强等）

我意识到这个问题已经很老了，所以很可能不再相关，但很想听听你的进展情况。

于 2018-12-07T11:51:22.863 回答