webrtc学习(二): audio_device之opensles

audio_device是webrtc的音频设备模块. 封装了各个平台的音频设备相关的代码

audio device 在android下封装了两套音频代码.

1. 通过jni调用java的media进行操作.

2. 直接通过opensl es的native c接口进行操作.

native 接口自然比较高效, 但缺点在于opensl 要求 android 2.3+.

OpenSL ES (Open Sound Library for Embedded Systems) 是无授权费、跨平台、针对嵌入式系统精心优化的硬件音频加速API

opensl的资料非常少, google了一遍, 也就找到两篇有点用的文章.

OpenSL ES for Android 对于代码是ndk samples 中的native-audio.

Lock-free audio IO with OpenSL ES on Android 另一篇opensl的应用.

webrtc 的example中提供了一个opensl es的例子. opensl_loopbakc(opensldemo-debug.apk) 用于示范 opensl的使用 (回放声音).

花了一点时间分析了下全部的流程, 因为无法调试, 所以看起来很烦. 线程处理的地方加了log才看明白.

主要有这几个类:

1. AudioDeviceBuffer

缓存类, 方法RegisterAudioCallback. 通过callback来通知数据采集(record), 或者请求数据(playout).

2. OpenSlesInput

record 的实现.

3. OpenSlesOutput

playout的实现.

4. SingleRwFifo

实现了一个无锁队列.

播放的流程:

1. 创建OpenSlesOutput 并且 AttachAudioBuffer, 初始化opensl的相关信息(engine, outmix等). 初始化需要的播放缓存.

2. StartPlayout中, 创建opensl 的audio player, 注册player 缓存播放的callback. 并对所有的播放缓存Enqueue, 然后创建音频数据处理线程CbThreadImpl

说明:　音频数据Enqueue到player. 就会播放出来, 并且每次播放完成后player会回调注册的callback.

3. CbThreadImpl的唤醒是由event_ 来控制的. 有kUnderrun 和 kNoUnderrun两种状态. kUnderrun 表示音频数据低于预计值. kNoUnderrun表示音频数据正常.

在callback(PlayerSimpleBufferQueueCallbackHandler)回调时的处理是这样的.

当fifo_中没有数据需要播放时, 以kUnderrun 唤醒CbThreadImpl.

当fifo_中有数据时, 把音频数据Enqueue 入player. 以kNoUnderrun 唤醒CbThreadImpl

void OpenSlesOutput::PlayerSimpleBufferQueueCallbackHandler(

    SLAndroidSimpleBufferQueueItf sles_player_sbq_itf) {

  if (fifo_->size() <= 0 || number_underruns_ > 0) {

    ++number_underruns_;

    event_.SignalEvent(kUnderrun, number_underruns_);

    return;

  }

  int8_t* audio = fifo_->Pop();

  if (audio)

  OPENSL_RETURN_ON_FAILURE(

      (*sles_player_sbq_itf)->Enqueue(sles_player_sbq_itf,

                                      audio,

                                      buffer_size_bytes_),

      VOID_RETURN);

  event_.SignalEvent(kNoUnderrun, 0);

}

4. 当CbThreadImpl被唤醒时. 如果是kUnderrun 则player会重新启动. 并重新把所有播放缓存Enqueue.

OPENSL_RETURN_ON_FAILURE(

      (*sles_player_itf_)->SetPlayState(sles_player_itf_,

                                        SL_PLAYSTATE_STOPPED),

      true);

  EnqueueAllBuffers();

  OPENSL_RETURN_ON_FAILURE(

      (*sles_player_itf_)->SetPlayState(sles_player_itf_,

                                        SL_PLAYSTATE_PLAYING),

      true);

如果是kNoUnderrun , 则开始处理.

while (fifo_->size() < num_fifo_buffers_needed_ && playing_) {

    int8_t* audio = play_buf_[active_queue_].get();

    fine_buffer_->GetBufferData(audio);

    fifo_->Push(audio);

    active_queue_ = (active_queue_ + 1) % TotalBuffersUsed();

  }

fine_buffer_ 的GetBufferData会自动处理10ms的数据. 如果数据不足, 则从audio buffer的callback –> NeedMorePlayData请求数据. 如果数据太多则存入缓存中.

fifo_ 把获取到的数据入栈. 当fifo_的大小等于num_fifo_buffers_needed_(预分配的播放缓存数量) 时, CbThreadImpl停止处理, 等待下次唤醒.

webrtc中的threadWrapper::create创建的线程. start的处理代码是这样的.

result |= pthread_create(&thread_, &attr_, &StartThread, this);

StartThread的代码:

bool alive = true;

  bool run = true;

  while (alive) {

    run = run_function_(obj_);

    CriticalSectionScoped cs(crit_state_);

    if (!run) {

      alive_ = false;

    }

    alive = alive_;

  }

run_function_ 就是create时, 传进去的函数.

所以opensl 的CbThreadImpl处理是不断被调用的. 这是我原先非常疑惑的一点( 没看threadwrapper的代码之前, 我并不知道CbThreadImpl会一直被调用).

录制的流程就不赘述了. 大体没啥差别.

opensl demo中是FakeAudioDeviceBuffer继承了AudioDeviceBuffer, 在GetPlayoutData中把record的数据交付给playout. 而不是通过外部的callback来实现.