对讲机开发,对讲延时的问题

简介: 笔记

通过查看Log发现,是由于按下PTT键播放Tone音时影响了录音的启动,该Tone音使用的是STREAM_CALL类型,于是修改为STREAM_MUSIC后解决此问题。

分析过程如下:


log分析


建议你们梳理一下上层的流程和配置。你上层开启的stream可能有问题。
08-05 13:24:54.267   145  1898 D AudioPolicyManagerSPRD: startOutput() is_voip_set 0,stream 0,
08-05 13:24:54.267   145  1898 D AudioPolicyManagerSPRD: startOutput() outputDesc->mRefCount[AudioSystem::VOICE_CALL] 1
08-05 13:24:54.267   145   315 D AudioPolicyService: AudioCommandThread() processing set parameters string sprd_voip_start=true, io 0
08-05 13:24:54.267   145   315 V AudioFlinger: setParameters(): io 0, keyvalue sprd_voip_start=true, calling pid 145
08-05 13:24:54.267   145   315 W audio_hw_primary: adev_set_parameters, kvpairs : sprd_voip_start=true
AudioSystem::VOICE_CALL这个设置会让sprd_voip_start打开。直到13:24:54.867 tone音播放结束,关闭voip:
08-05 13:24:54.867   145   315 D AudioPolicyService: AudioCommandThread() processing set parameters string sprd_voip_start=false, io 0
08-05 13:24:54.867   145   315 V AudioFlinger: setParameters(): io 0, keyvalue sprd_voip_start=false, calling pid 145
之后,才开始真正的录音:
08-05 13:24:54.867   145  2174 D audio_hw_primary: : in_read sco stop  and do standby  // 这时 sco的read才关闭
// 正常声卡录音设备才打开
08-05 13:24:54.907   145   357 W audio_hw_primary: open s_tinycard in
08-05 13:24:54.917   145   357 W audio_hw_primary: open s_tinycard successfully
08-05 13:24:54.967   145  2174 E audio_hw_primary: start_input_stream pcm_open_0
08-05 13:24:54.967   145  2174 W audio_hw_primary: rec_mode(3), sample_rate(8000)
08-05 13:24:54.977  1867  2175 D oem_dsp : first record dequed
08-05 13:24:54.977   145  2174 W audio_hw_primary: extendArraySize=118, eq_size=52, dp_size=38
08-05 13:24:54.977   145  2174 I audio_hw_primary: record process module created is successful.
也就是说在“in_read sco stop  and do standby”后才可能录音,13:24:54.267 ~ 13:24:54.867之间的都是通话相关的流程(dsp控制vbc和codec设备),不可能录到音。
从log看直到13:24:54.977,才录到第一帧。
08-05 13:24:54.977  1867  2175 D oem_dsp : first record dequed
之前都是录不到的:
08-05 13:24:54.957  1867  1888 W oem_dsp : recorder read none frame


目录
相关文章
|
存储 消息中间件 NoSQL
延时消息常见实现方案
延时消息常见实现方案
延时消息常见实现方案
|
传感器 算法
RTOS中相对延时和绝对延时的区别
RTOS中相对延时和绝对延时的区别
110 1
|
编解码 测试技术
srt推拉流延时性能测试
srt推拉流延时性能测试
328 0
srt推拉流延时性能测试
|
Web App开发 监控 算法
详解 WebRTC 高音质低延时的背后 — AGC(自动增益控制)
本文将结合实例全面解析 WebRTC AGC 的基本框架,一起探索其基本原理、模式的差异、存在的问题以及优化方向。
详解 WebRTC 高音质低延时的背后 — AGC(自动增益控制)
|
存储 消息中间件 NoSQL
一口气说出 6 种实现延时消息的方案,还有谁不会?!
一口气说出 6 种实现延时消息的方案,还有谁不会?!
|
消息中间件
延时队列优化 (2)
在这里新增了一个队列QC,绑定关系如下,该队列不设置TTL时间
延时队列优化 (2)
|
消息中间件 存储 NoSQL
延迟消息的五种实现方案
生产者把消息发送到消息队列中以后,并不期望被立即消费,而是等待指定时间后才可以被消费者消费,这类消息通常被称为延迟消息。延迟消息的应用场景其实是非常的广泛,比如以下的场景:
728 0
延迟消息的五种实现方案
|
Web App开发 缓存 网络协议
揭秘阿里云 RTS SDK 是如何实现直播降低延迟和卡顿
简介: RTS NetSDK是未来直播和通信一体化SDK的基石。在RTS NetSDK之上,加一个Multimedia Framework,以及QoS消息处理,就可以构成一个一体化SDK。这对于已经有自己的Framework的客户来说是个好消息,不需要为直播和通信分别开发软件了,同时也简化了直播连麦场景的实现。
423 0
揭秘阿里云 RTS SDK 是如何实现直播降低延迟和卡顿
|
存储 监控 网络协议