Android端获取WebRTC远端音频数据并禁用AudioTrack问题求助

核心问题是：禁用AudioTrack.write(WRITE_BLOCKING)后，线程失去了与音频播放节奏绑定的阻塞同步机制，导致nativeGetPlayoutData被频繁调用，native层在无播放约束的情况下返回重复/无效数据，最终生成异常大的错误音频文件。简单的Thread.sleep(10ms)精度不足，无法匹配音频硬件的精确时钟，因此效果不佳。

以下是三种可行的解决方案：

方案1：高精度时钟同步循环节奏 #

放弃固定时长的Thread.sleep，改用系统纳秒级时钟动态计算等待时间，保证每次循环间隔严格匹配音频块的播放时长（10ms）：

private class AudioTrackThread extends Thread {
  @Override
  public void run() {
    final long frameDurationNs = 10_000_000; // 10ms对应的纳秒数
    long lastFrameTimeNs = System.nanoTime();

    while (keepAlive) {
      // 从native层获取音频数据
      nativeGetPlayoutData(nativeAudioTrack, sizeInBytes);
      // 写入文件
      DumpToFile(byteBuffer, sizeInBytes);

      // 计算并等待剩余时间，保证循环间隔精确为10ms
      long currentTimeNs = System.nanoTime();
      long elapsedNs = currentTimeNs - lastFrameTimeNs;
      long waitNs = frameDurationNs - elapsedNs;
      if (waitNs > 0) {
        LockSupport.parkNanos(waitNs);
      }
      lastFrameTimeNs = System.nanoTime();
    }
  }
}

该方案通过动态调整等待时长，弥补了固定sleep的精度误差，能更精准地对齐音频播放节奏。

方案2：利用WebRTC原生回调机制（推荐） #

不要自行维护线程循环，改为让WebRTC在准备好播放数据时主动推送，从根源上避免同步问题：

1. 定义一个音频数据接收接口：

public interface AudioDataSink {
  void onAudioDataReceived(byte[] data, int size);
}

2. 在WebRtcAudioTrack中添加该接口的引用，并修改数据处理逻辑：

private AudioDataSink audioDataSink;

// 替换原有的audioTrack.write逻辑
if (audioDataSink != null) {
  byte[] data = new byte[sizeInBytes];
  byteBuffer.get(data);
  byteBuffer.flip(); // 重置缓冲区位置，供下次读取
  audioDataSink.onAudioDataReceived(data, sizeInBytes);
}

3. 实现该接口并处理文件写入：

audioDataSink = new AudioDataSink() {
  @Override
  public void onAudioDataReceived(byte[] data, int size) {
    DumpToFile(data, size);
  }
};

这种方式完全复用WebRTC原生的播放节奏控制逻辑，无需手动处理同步，稳定性最高。

方案3：模拟AudioTrack的阻塞逻辑 #

如果无法修改WebRTC核心代码，可以初始化一个空的AudioTrack，仅用它的阻塞写入机制来同步节奏（不实际输出音频）：

// 初始化仅用于同步的空AudioTrack
AudioTrack syncTrack = new AudioTrack(AudioManager.STREAM_VOICE_CALL,
                                      48000,
                                      AudioFormat.CHANNEL_OUT_MONO,
                                      AudioFormat.ENCODING_PCM_16BIT,
                                      sizeInBytes * 2, // 小缓冲区保证阻塞效果
                                      AudioTrack.MODE_STREAM);
syncTrack.play();

private class AudioTrackThread extends Thread {
  @Override
  public void run() {
    while (keepAlive) {
      nativeGetPlayoutData(nativeAudioTrack, sizeInBytes);
      DumpToFile(byteBuffer, sizeInBytes);

      // 写入空数据模拟WRITE_BLOCKING的阻塞行为
      syncTrack.write(new byte[sizeInBytes], 0, sizeInBytes, AudioTrack.WRITE_BLOCKING);
    }
    syncTrack.stop();
    syncTrack.release();
  }
}

该方案完全复用Android原生的音频同步机制，效果与原AudioTrack.write一致，缺点是会占用少量音频资源。

内容的提问来源于stack exchange，提问作者sysescool