技术宝典WebRTCADM源码流程分析

　　1、ADM基本架构1。1ADM的架构分析
　　WebRTC中，ADM（AudioDeviceManager）的行为由AudioDeviceModule来定义，具体由AudioDeviceModuleImpl来实现。
　　从上面的架构图可以看出AudioDeviceModule定义了ADM相关的所有行为（上图只列出了部分核心，更详细的请参考源码中的完整定义）。从AudioDeviceModule的定义可以看出AudioDeviceModule的主要职责如下：
　　初始化音频播放采集设备；
　　启动音频播放采集设备；
　　停止音频播放采集设备；
　　在音频播放采集设备工作时，对其进行操作（例如：Mute，AdjustVolume）；
　　平台内置3A开关的调整（主要是针对Android平台）；
　　获取当前音频播放采集设备各种与此相关的状态（类图中未完全体现，详情参考源码）
　　AudioDeviceModule具体由AudioDeviceModuleImpl实现，二者之间还有一个AudioDeviceModuleForTest，主要是添加了一些测试接口，对本文的分析无影响，可直接忽略。AudioDeviceModuleImpl中有两个非常重要的成员变量，一个是audiodevice，它的具体类型是std：：uniqueptr，另一个是audiodevicebuffer，它的具体类型是AudioDeviceBuffer。
　　其中audiodevice是AudioDeviceGeneric类型，AudioDeviceGeneric是各个平台具体音频采集和播放设备的一个抽象，由它承担AudioDeviceModuleImpl对具体设备的操作。涉及到具体设备的操作，AudioDeviceModuleImpl除了做一些状态的判断具体的操作设备工作都由AudioDeviceGeneric来完成。AudioDeviceGeneric的具体实现由各个平台自己实现，例如对于iOS平台具体实现是AudioDeviceIOS，Android平台具体实现是AudioDeviceTemplate。至于各个平台的具体实现，有兴趣的可以单个分析。这里说一下最重要的共同点，从各个平台具体实现的定义中可以发现，他们都有一个audiodevicebuffer成员变量，而这个变量与前面提到的AudioDeviceModuleImpl中的另一个重要成员变量audiodevicebuffer，其实二者是同一个。AudioDeviceModuleImpl通过AttachAudioBuffer（）方法，将自己的audiodevicebuffer对象传给具体的平台实现对象。
　　audiodevicebuffer的具体类型是AudioDeviceBuffer，AudioDeviceBuffer中的playbuffer、recbuffer是int16t类型的buffer，前者做为向下获取播放PCM数据的Buffer，后者做为向下传递采集PCM数据的Buffer，具体的PCM数据流向在后面的数据流向章节具体分析，而另一个成员变量audiotransportcb，类型为AudioTransport，从AudioTransport接口定义的中的两个核心方法不难看出他的作用，一是向下获取播放PCM数据存储在playbuffer，另一个把采集存储在recbuffer中的PCM数据向下传递，后续具体流程参考数据流向章节。1。2关于ADM扩展的思考
　　从WebRTCADM的实现来看，WebRTC只实现对应了各个平台具体的硬件设备，并没什么虚拟设备。但是在实际的项目，往往需要支持外部音频输入输出，就是由业务上层pushpull音频数据（PCM。。。），而不是直接启动平台硬件进行采集播放。在这种情况下，虽然原生的WebRTC不支持，但是要改造也是非常的简单，由于虚拟设备与平台无关，所以可以直接在AudioDeviceModuleImpl中增加一个与真实设备audiodevice对应的VirtualDevice（变量名暂定为virtualdevice），virtualdevice也跟audiodevice一样，实现AudioDeviceGeneric相关接口，然后参考audiodevice的实现去实现数据的采集（push）与播放（pull），无须对接具体平台的硬件设备，唯一需要处理的就是物理设备audiodevice与虚拟设备virtualdevice之间的切换或协同工作。
　　【免费分享】音视频学习资料包、大厂面试题、技术视频和学习路线图，资料包括（CC，Linux，FFmpegwebRTCrtmphlsrtspffplaysrs等等）有需要的可以后台私信扣1免费领取
　　2、ADM设备的启动2。1启动时机
　　ADM设备的启动时机并无什么特殊要求，只要ADM创建后即可，不过WebRTC的Native源码中会在SDP协商好后去检查一下是否需要启动相关的ADM设备，如果需要就会启动相关的ADM设备，采集与播放设备的启动二者是完全独立的，但流程大同小异，相关触发代码如下，自上而下阅读即可。
　　以下是采集设备启动的触发源码（前面几步还有其他触发入口，但后面是一样的，这里只做核心流程展示）：cricket：：VoiceChannelvoidVoiceChannel：：UpdateMediaSendRecvStatew（）｛boolsendIsReadyToSendMediaw（）；mediachannel（）SetSend（send）；｝cricket：：WebRtcVoiceMediaChannelvoidWebRtcVoiceMediaChannel：：SetSend（boolsend）｛for（autokv：sendstreams）｛kv。secondSetSend（send）；｝｝cricket：：WebRtcVoiceMediaChannel：：WebRtcAudioSendStreamvoidSetSend（boolsend）｛UpdateSendState（）；｝cricket：：WebRtcVoiceMediaChannel：：WebRtcAudioSendStreamvoidUpdateSendState（）｛if（sendsource！nullptrrtpparameters。encodings〔0〕。active）｛streamStart（）；｝else｛！sendsourcenullptrstreamStop（）；｝｝webrtc：：internal：：WebRtcAudioSendStreamvoidAudioSendStream：：Start（）｛audiostate（）AddSendingStream（this，encodersampleratehz，encodernumchannels）；｝webrtc：：internal：：AudioStatevoidAudioState：：AddSendingStream（webrtc：：AudioSendStreamstream，intsampleratehz，sizetnumchannels）｛检查下采集设备是否已经启动，如果没有，那么在这启动autoadmconfig。audiodevicemodule。get（）；if（！admRecording（））｛if（admInitRecording（）0）｛if（recordingenabled）｛admStartRecording（）；｝｝else｛RTCDLOGF（LSERROR）Failedtoinitializerecording。；｝｝｝
　　从上面采集设备启动的触发源码可以看出，如果需要发送音频，不管前面采集设备是否启动，在SDP协商好后，一定会启动采集设备。如果我们想把采集设备的启动时机掌握在上层业务手中，那么只要注释上面AddSendingStream方法中启动设备那几行代码即可，然后在需要的时候自行通过ADM启动采集设备。
　　以下是播放设备启动的触发源码（前面几步还有其他触发入口，但后面是一样的，这里只做核心流程展示）：cricket：：VoiceChannelvoidVoiceChannel：：UpdateMediaSendRecvStatew（）｛boolrecvIsReadyToReceiveMediaw（）；mediachannel（）SetPlayout（recv）；｝cricket：：WebRtcVoiceMediaChannelvoidWebRtcVoiceMediaChannel：：SetPlayout（boolplayout）｛returnChangePlayout（desiredplayout）；｝cricket：：WebRtcVoiceMediaChannelvoidWebRtcVoiceMediaChannel：：ChangePlayout（boolplayout）｛for（constautokv：recvstreams）｛kv。secondSetPlayout（playout）；｝｝cricket：：WebRtcVoiceMediaChannel：：WebRtcAudioReceiveStreamvoidSetPlayout（boolplayout）｛if（playout）｛streamStart（）；｝else｛streamStop（）；｝｝webrtc：：internal：：AudioReceiveStreamvoidAudioReceiveStream：：Start（）｛audiostate（）AddReceivingStream（this）；｝webrtc：：internal：：AudioStatevoidAudioState：：AddReceivingStream（webrtc：：AudioReceiveStreamstream）｛检查下播放设备是否已经启动，如果没有，那么在这启动autoadmconfig。audiodevicemodule。get（）；if（！admPlaying（））｛if（admInitPlayout（）0）｛if（playoutenabled）｛admStartPlayout（）；｝｝else｛RTCDLOGF（LSERROR）Failedtoinitializeplayout。；｝｝｝
　　从上面播放设备启动的触发源码可以看出，如果需要播放音频，不管前面播放设备是否启动，在SDP协商好后，一定会启动播放设备。如果我们想把播放设备的启动时机掌握在上层业务手中，那么只要注释上面AddReceivingStream方法中启动设备那几行代码即可，然后在需要的时候自行通过ADM启动播放设备。2。2启动流程
　　当需要启动ADM设备时，先调用ADM的InitXXX，接着是ADM的StartXXX，当然最终是透过上面的架构层层调用具体平台相应的实现，详细流程如下图：
　　关于设备的停止
　　了解了ADM设备的启动，那么与之对应的停止动作，就无需多言。如果大家看了源码，会发现其实停止的动作及流程与启动基本上是一一对应的。3、ADM音频数据流向3。1音频数据的发送
　　上图是音频数据发送的核心流程，主要是核心函数的调用及线程的切换。PCM数据从硬件设备中被采集出来，在采集线程做些简单的数据封装会很快进入APM模块做相应的3A处理，从流程上看APM模块很靠近原始PCM数据，这一点对APM的处理效果有非常大的帮助，感兴趣的同学可以深入研究下APM相关的知识。之后数据就会被封装成一个Task，投递到一个叫rtpsendcontroller的线程中，到此采集线程的工作就完成了，采集线程也能尽快开始下一轮数据的读取，这样能最大限度的减小对采集的影响，尽快读取新的PCM数据，防止PCM数据丢失或带来不必要的延时。
　　接着数据就到了rtpsendcontroller线程，rtpsendcontroller线程的在此的作用主要有三个，一是做rtp发送的拥塞控制，二是做PCM数据的编码，三是将编码后的数据打包成RtpPacketToSend（RtpPacket）格式。最终的RtpPacket数据会被投递到一个叫RoundRobinPacketQueue的队列中，至此rtpsendcontroller线程的工作完成。
　　后面的RtpPacket数据将会在SendControllerThread中被处理，SendControllerThread主要用于发送状态及窗口拥塞的控制，最后数据通过消息的形式（type：MSGSENDRTPPACKET）发送到Webrtc三大线程之一的网络线程（NetworkThread），再往后就是发送给网络。到此整个发送过程结束。3。2数据的接收与播放
　　上图是音频数据接收及播放的核心流程。网络线程（NetworkThread）负责从网络接收RTP数据，随后异步给工作线程（WorkThread）进行解包及分发。如果接收多路音频，那么就有多个ChannelReceive，每个的处理流程都一样，最后未解码的音频数据存放在NetEq模块的packetbuffer中。与此同时播放设备线程不断的从当前所有音频ChannelReceive获取音频数据（10ms长度），进而触发NetEq请求解码器进行音频解码。对于音频解码，WebRTC提供了统一的接口，具体的解码器只需要实现相应的接口即可，比如WebRTC默认的音频解码器opus就是如此。当遍历并解码完所有ChannelReceive中的数据，后面就是通过AudioMixer混音，混完后交给APM模块处理，处理完最后是给设备播放。
　　原文链接：技术宝典WebRTCADM源码流程分析