Question

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

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

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或Nokia 1等低端设备），没有任何延迟。

问题是：：在某些设备（Archos 55 Cobalt（API 23）和OnePlus One（API 23））上，声音非常缓慢，尤其是当我同时提取2个音频文件时时间（这样我就可以同时播放它们），而相同的代码可以在功能不强的设备（如诺基亚1）上正常工作。

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

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

感谢您的帮助。

Answer 1

第一件事是您不应该在音频回调内部进行提取和解码，因为这将阻塞音频回调，直到发生解码为止，这将导致持续欠载。

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

第二，“相当懒惰”是什么意思？信号路径中有许多延迟源，包括：

触摸事件到达应用所需的时间
如果您是从另一个线程启动流，则第一次音频回调开始所花费的时间
涡旋解码发生所需的时间
音频帧到达音频设备所花费的时间
渲染的音频到达扬声器或耳机所需的时间（输出路径上可以有DSP来改善声学质量，例如噪声消除，低音增强等）

我意识到这个问题已经很老了，因此很可能不再相关了，但是有兴趣了解您的情况。

Android Oboe库在一些设备上比较落后

1 个答案: