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停止处理, 等待下次唤醒.    5.    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来实现.