AudioTrack 滞后：获取缓冲区超时

Question

我在 Android 手机上播放 WAV，方法是加载文件并通过 FileInputStream > 将字节输入 AudioTrack.write() 中。缓冲输入流>数据输入流方法。音频播放得很好，当它播放时，我可以轻松地动态调整采样率、音量等，并具有良好的性能。然而，一首曲目需要大约两秒的时间才能开始播放。我知道 AudioTrack 有不可避免的延迟，但这太荒谬了。每次我播放一首曲目时，我都会得到这样的信息：

03-13 14:55:57.100: WARN/AudioTrack(3454): obtainBuffer timed out (is the CPU pegged?) 0x2e9348 user=00000960,     server=00000000
03-13 14:55:57.340: WARN/AudioFlinger(72): write blocked for 233 msecs, 9 delayed writes, thread 0xba28

我注意到，从手机开机时起，每次播放曲目时，延迟写入计数都会增加一（即使是在多个会话中）。块时间始终为 230 - 240 毫秒，考虑到该设备上的最小缓冲区大小为 9600 (9600 / 44100)，这是有意义的。我在互联网上无数次搜索中都看到过这条消息，但它通常似乎与根本不播放音频或跳过音频有关。就我而言，这只是一个延迟的开始。

我在高优先级线程中运行所有代码。这是我正在做的事情的一个删减但功能齐全的版本。这是我的播放类中的线程回调。再说一遍，这有效（现在只能播放 16 位、44.1kHz、立体声文件），只是需要很长时间才能启动，并且每次都会收到 acquireBuffer/延迟写入消息。

public void run() {

    // Load file
    FileInputStream mFileInputStream;
    try {
        // mFile is instance of custom file class -- this is correct, 
        // so don't sweat this line
        mFileInputStream = new FileInputStream(mFile.path());
    } catch (FileNotFoundException e) {
        // log
    }

    BufferedInputStream mBufferedInputStream = new BufferedInputStream(mFileInputStream, mBufferLength);
    DataInputStream mDataInputStream = new DataInputStream(mBufferedInputStream);

    // Skip header
    try {
        if (mDataInputStream.available() > 44) {
            mDataInputStream.skipBytes(44);
        }
    } catch (IOException e) {
        // log
    }

    // Initialize device
    mAudioTrack = new AudioTrack(
        AudioManager.STREAM_MUSIC, 
        ConfigManager.SAMPLE_RATE, 
        AudioFormat.CHANNEL_CONFIGURATION_STEREO, 
        AudioFormat.ENCODING_PCM_16BIT, 
        ConfigManager.AUDIO_BUFFER_LENGTH,
        AudioTrack.MODE_STREAM
    );
    mAudioTrack.play();

    // Initialize buffer
    byte[] mByteArray = new byte[mBufferLength];
    int mBytesToWrite = 0;
    int mBytesWritten = 0;

    // Loop to keep thread running
    while (mRun) {

        // This flag is turned on when the user presses "play"
        while (mPlaying) {

            try {
                // Check if data is available
                if (mDataInputStream.available() > 0) {

                    // Read data from file and write to audio device
                    mBytesToWrite = mDataInputStream.read(mByteArray, 0, mBufferLength);
                    mBytesWritten += mAudioTrack.write(mByteArray, 0, mBytesToWrite);

                }
            }
            catch (IOException e){
                // log
            }                
        }   
    }
}

如果我能够克服人为的长延迟，我可以通过在稍后的可预测位置开始写入（即，当我开始播放文件时跳过最小缓冲区长度）来轻松处理继承延迟。

Answer 1

我遇到了类似的问题，尽管我使用 RandomAccessFile 而不是 BufferedInputStream 来读取 PCM 数据。问题是文件 I/O 太慢。我怀疑即使使用缓冲流也会遇到这个问题，因为 I/O 仍然在与音频处理相同的线程上进行。

解决方案是有两个线程：一个线程从文件中读取缓冲区并将它们排队到内存中，另一个线程从此队列中读取数据并将其写入音频硬件。我使用 ConcurrentLinkedQueue 来完成此任务。

我使用相同的技术进行录音，使用 AudioRecord，但方向相反。关键是将文件 I/O 放在单独的线程上。

Answer 2

派对回答这个问题有点晚了，但以防万一它对将来的任何人有帮助 - 我遇到了这个确切的问题，代码与问题中的代码非常相似，其中创建了 AudioTrack 并设置为播放，但未写入立即地。

我发现在开始写入之前立即创建 AudioTrack 可以消除延迟。由于某种原因，AudioTrack 似乎不喜欢坐在空缓冲区中。

就上面的代码而言，您想做类似的事情

mAudioTrack=null;
while (mRun) 
{ 

    // This flag is turned on when the user presses "play" 
    while (mPlaying) 
    { 

        try 
        { 
            if (mAudioTrack==null) {   
                mAudioTrack = new AudioTrack(AudioManager.STREAM_MUSIC, ConfigManager.SAMPLE_RATE,AudioFormat.CHANNEL_CONFIGURATION_STEREO, AudioFormat.ENCODING_PCM_16BIT,ConfigManager.AUDIO_BUFFER_LENGTH,AudioTrack.MODE_STREAM);   
                mAudioTrack.play();   
            }
            // Rest of the playback code here
        }
    }
    mAudioTrack=null;
}