关键字:VOIP,AudioUnit,AudioQueue,RemoteIO
问题描述
VOIP通话,iOS底层音频方式采用AudioUnit机制,本来也挺好,但是会有遇到CS域来电时RemoteIO挂死的问题
[1876:492456] 20:46:05.584 WARNING: [AVAudioSession Notify Thread] 1250: AURemoteIO::Stop: error 0x10000004 calling TerminateOwnIOThread
[1876:492846] 20:46:05.586 ERROR: [AURemoteIO::IOThread] >aurioc> 1499: [email protected]: IOThread exiting with error 0x10004002
[1876:492456] 20:46:05.592 ERROR: [AVAudioSession Notify Thread] AVAudioSessionPortImpl.mm:52: ValidateRequiredFields: Unknown selected data source for Port iPhone 麦克风 (type: MicrophoneBuiltIn)
[1876:492456] 20:46:05.601 ERROR: [AVAudioSession Notify Thread] AVAudioSessionPortImpl.mm:52: ValidateRequiredFields: Unknown selected data source for Port iPhone 麦克风 (type: MicrophoneBuiltIn)
[1876:492456] 20:46:05.606 ERROR: [AVAudioSession Notify Thread] AVAudioSessionPortImpl.mm:52: ValidateRequiredFields: Unknown selected data source for Port iPhone 麦克风 (type: MicrophoneBuiltIn)
[1876:492456] 20:46:05.612 ERROR: [AVAudioSession Notify Thread] AVAudioSessionPortImpl.mm:52: ValidateRequiredFields: Unknown selected data source for Port iPhone 麦克风 (type: MicrophoneBuiltIn)
[1876:492456] 20:46:05.614 ERROR: [AVAudioSession Notify Thread] AVAudioSessionPortImpl.mm:52: ValidateRequiredFields: Unknown selected data source for Port iPhone 麦克风 (type: MicrophoneBuiltIn)
挂死就挂死吧,如果能强制关闭也行,问题是他一定要等25S左右,才出错误,在这之前,所有对音频设备的接口调用都会被阻塞住.这就成问题了.
本来场景可以这样做,iOS监听到收到CS域来电,发通知,HOLD通话,底层实现是直接销毁媒体控制对象.在CS域电话挂断后(不挂断,单纯切回APP无效,抢不回来)
发UNHOLD动作,这时重建媒体,结果由于对媒体的动作被阻塞住,导致执行动作的底层线程被阻塞住了,媒体在信令发出后15S内没能建立(直接挂CS电话),被对端挂了.
反复跟踪,搜索,终于发现stackoverflow上有几个问题和这个相关,提示是去采用AudioQueue,没想到这里还有一个坑.
代码集成后发现问题倒是解决了,但是音质卡顿,和之前的算法完全无法相比.
分析,发现AudioQueue上报数据有延迟.视数据缓冲区大小,20ms~1S之内,区别还挺大的.
AudioUnit上报数据的间隔基本是均匀的,20ms左右,故WebRTC底层发送时就根本不做延时.直接认为采集是均匀的就行.
而AudioUnit在上报数据大小为250ms以下时,会每隔10个包左右,延迟256ms一次,而且这延时也没有带来更多的数据;超过500ms以后,延迟才比较均匀,700多ms一次的延时间隔.