Android
音频常见问题排查
更新时间： 2022/11/25 11:50:54
本文汇总了集成 NERTC SDK 的云信开发者在应用上线后遇到的常见音频问题及对应的问题排查思路，帮助您分析问题可能原因、全面自查及配合网易云信技术支持工程师解决问题。
常见音频问题包括：
无声或声音小
音频数据传输链路如下：
问题原因
出现无声或声音小的常见原因有：
- 物理设备存在问题或者无录音权限，导致不能正常采集或播放音频。
- 设置的播放音量过低，或者由于 API 使用姿势不当，导致静音或停止本端音频采集。
步骤1 问题自查
-
排查是发送端问题还是接收端问题。
- 如果房间里所有人都听不到，则可能是发送端问题。
- 如果房间里部分人听不到，则可能是接收端问题。
-
排查音频设备是否有问题，是否具有录音权限。
建议使用自带录音机的 App 录制声音或者播放音乐测试设备是否正常。
NERTC SDK 通过录音设备采集房间内成员的音频信号，将其录制下来以后播放给远端用户收听。
-
根据不同客户端排查物理设备的相关设置是否正常。
iOS 端-
其他 App 的音频抢占了音频硬件设备。
- 检查手机上是否有其它正在运行的 App 录音（包括siri），结束相关进程。
- 重新进入 RTC 房间。
-
在音视频通话过程中，Category 不是 AVAudioSessionCategoryPlayAndRecord， 导致录音线程无法启动。
Android 端App 切换到后台，导致音频采集异常结束。
建议采取必要的应用保活方案。
Windows 端- 设备 Boost 没有正确设置，导致采集的声音太小。
- 部分麦克风采集有指定方向或者有距离限制，需要对着某个角度说话或者离麦克风更近，麦克风才能正常采集声音，用户声音才会正常。
- 硬件的自动增益（AGC）模块有问题，导致没有采集到声音。
-
打开声音设置窗口，在属性 > 高级界面查看是否有音量增强等设置。如果勾选了音量增加相关设置，请取消勾选。
-
重新测试声音是否能正常采集。
-
-
-
排查发送端的相关 API 的值设置是否正确。
- adjustRecordingSignalVolume：调节采集音量的大小。数值越大，音量越大，具体请参见设置通话音量。
- muteLocalAudioStream：确认是否开启了本地静音。
- enablelocalaudio：已开启本地语音。
- enableAudioVolumeIndication：已启用说话者音量提示。
-
排查接收端的相关 API 的值设置是否正确。
adjustPlaybackSignalVolume：调节音频流在本地播放的音量。如果设置为 0 或数值太小，会导致没有声音，或声音太小。
步骤2 监控通话质量
步骤3 联系技术支持
如果通过以上步骤，问题仍无法解决，请联系网易云信技术支持工程师，并提供以下信息，方便工程师快速定位问题：
| 信息类别 | 信息详情 |
|---|---|
| 必要信息 | 房间名称（channelName）。 |
| 无声或音量小的用户的 uid。 | |
| 音频 Dump 文件。获取步骤请参见获取音频 Dump 文件。 | |
| 辅助信息 | SDK 日志文件。具体如何获取日志请参见 SDK 的日志从哪里获取。 |
声音忽大忽小
音频数据传输链路如下：
问题原因
出现声音忽大忽小现象的常见原因有：
- 移动端（Android 或 iOS）的 SDK 在语音通话模式下默认开启距离传感器，因此若人脸与移动设备时近时远，就会造成声音输出路由在扬声器和听筒之间切换。
- 声音发送端的用户距离麦克风时近时远或者没有完全对准麦克风说话，也会造成声音的采集音量忽大忽小。
- 设备硬件的噪声消除（ANC）和回声消除（AEC）的效果不佳，在某些情况下会导致部分语音的缺失。
步骤1 问题自查
-
检查是否因为是距离传感器的检测，声音输出的路由在扬声器和听筒之间切换。
-
检测发送端的音频录音设备是否正常，可以调整使用方式和距离，或者更换录音设备。
建议使用自带录音机的 App 录制声音或者播放音乐测试设备是否正常。
NERTC SDK 通过录音设备采集房间内成员的音频信号，将其录制下来以后播放给远端用户收听。
步骤2 监控通话质量
步骤3 联系技术支持
如果通过以上步骤，问题仍无法解决，请联系网易云信技术支持工程师，并提供以下信息，方便工程师快速定位问题：
| 信息类别 | 信息详情 |
|---|---|
| 必要信息 | 出现声音忽大忽小现象的房间名称（channelName）。 |
| 声音忽大忽小的用户 ID（uid）、使用的设备类型和系统版本、使用的音频设备信息和使用场景。 | |
| 音频 Dump 文件。获取步骤请参见获取音频 Dump 文件。 | |
| 辅助信息 | SDK 日志文件。具体如何获取日志请参见 SDK 的日志从哪里获取。 |
| 出现声音忽大忽小的具体时间段。 |
回声
音频数据传输链路如下：
问题原因
出现音频回声的常见原因有：
-
入会的其他设备回声消除效果不佳。原理图如下：
上图中，对端（用户 B） 的扬声器将接收到的音频 A 播放出来，又被对端的麦克风采集为回声 A，但由于对端设备硬件的回声消除（AEC）效果不佳，此回声 A 会再次和对端麦克风采集的音频 B 一起通过网络传输给本端（用户 A），本端就会听到部分自己的声音。
-
入会的各方设备开启了录音，且物理距离较近（1m 左右）；或者本端用户处于混响效果比较明显的空间里。
-
本端的录音、播放设备连接了不同的芯片设备，比如：播放设备连接了声卡，而录音设备连接了电脑。
-
本端用户开启了 SDK 的耳返功能，或者在 Windows 平台上开启了麦克风监听功能（即在麦克风属性里勾选了监听麦克风选项）。
-
在加入 RTC 房间连麦的同时，也进行了 CDN 拉流拉取了包含自己的流的混流（通常表现为人声和回声的时差为 3 秒左右）。
步骤1 问题自查
- 依次关闭入会各方的的麦克风，若能确定回声源，则让产生回声的用户调低播放音量或使用耳机后重新入会。
- 在各方设备物理距离较近的情况下，增大距离或者尝试使用耳机后重新入会。
- 检查耳返功能或麦克风监听功能是否开启，若开启则关闭对应功能。
- 若存在 CDN 拉流的情况，在连麦成功后及时释放播放器实例和资源。
步骤2 联系技术支持
如果通过以上步骤，问题仍无法解决，请联系网易云信技术支持工程师，并提供以下信息，方便工程师快速定位问题：
| 信息类别 | 信息详情 |
|---|---|
| 必要信息 | 出现音频回声的房间名称（channelName）。 |
| 听到回声和产生回声的用户 ID（uid），产生回声的用户使用的设备类型（是否开启扬声器或使用其他外接设备）和使用场景。 | |
| 音频 Dump 文件。获取步骤请参见获取音频 Dump 文件。 | |
| 辅助信息 | SDK 日志文件。具体如何获取日志请参见 SDK 的日志从哪里获取。 |
| 产生回声的具体时间段。 |
噪声
音频数据传输链路如下：
问题原因
出现音频噪声的常见原因有：
- 入会的几方都录音，且物理距离较近（1m 左右）。
- 产生噪声的用户设备所处的物理环境中存在较大的环境噪声，比如麦克风对着风扇、麦克风跟衣服摩擦等。
- 音频录音设备在异常情况下会造成较大的电流噪声，比如外置声卡、耳麦等接触不良或损坏。
- 本端和远端设备都存在回声没有完全消除的情况，并且由于自动增益（AGC）模块或者设备系统自身处理又会把小的声音循环放大，形成噪声。
- 部分 Android 设备系统将收到的音频信号里的噪声信号处理后，可能会让噪声听起来明显。
- 在设备性能达到瓶颈的时候（比如 CPU 持续达到 100%），由于数据不能及时处理，造成因为数据不连续导致的杂音。
步骤1 问题自查
- 在各方设备物理距离较近的情况下，增大距离或者尝试使用耳机后重新入会。
- 若存在较大的环境噪声干扰，可以尝试换到安静的场所，避免麦克风被风扇和摩擦影响。
- 检测音频连接设备是否存在异常，若存在异常则可以更换、重连设备后再次加入通话。
- 检测设备的性能是否已经达到瓶颈（比如 CPU 持续达到 100%）。
步骤2 联系技术支持
如果通过以上步骤，问题仍无法解决，请联系网易云信技术支持工程师，并提供以下信息，方便工程师快速定位问题：
| 信息类别 | 信息详情 |
|---|---|
| 必要信息 | 出现噪声的房间名称（channelName）。 |
| 产生噪声和听到噪声的用户 ID（uid）、使用的设备类型和系统版本、使用的音频设备信息和使用场景。 | |
| 音频 Dump 文件。获取步骤请参见获取音频 Dump 文件。 | |
| 辅助信息 | SDK 日志文件。具体如何获取日志请参见 SDK 的日志从哪里获取。 |
| 产生噪声的具体时间段。 |
声音卡顿
音频数据传输链路如下：
问题原因
出现声音卡顿的常见原因有：
- 网络不稳定，比如网络信号差或带宽不足的情况下，会引起丢包或抖动，如果弱网应对处理没有完全做好，会造成声音的卡顿。
- 设备性能消耗过大，比如 CPU 过载的情况下，如果采集或者播放线程没有及时处理和收发数据，会出现声音卡顿的现象。
- 本端有电话呼入，导致其他 App 抢占录音资源。
- 使用原始音频数据的回调（
onRecordFrame），如果是默认的支持读写模式，但针对回调数据的处理不够及时，会阻塞数据线程，从而造成声音的卡顿。 - API 使用姿势不当，比如短时间内频繁开启或关闭本地音频采集和发送（
enableLocalAudio）。
步骤1 问题自查
假设用户 A 听到用户 B 的声音出现卡顿，问题排查的思路如下：
- 排查接收端的问题：
- 检测用户 A 的设备是否存在性能消耗过大的情况。
- 若 CPU 占用偏大，可以尝试关闭没有必要的应用程序或重启设备后重新入会。
- 若 CPU 占用良好，则执行下一步。
- 在服务监控平台上查看用户 A 的音频下行丢包率、卡顿率和下行码率，以检查通话时用户 A 的下行网络情况。
- 若下行丢包率、卡顿率比较高或下行码率比较低，可以尝试将网络切换到稳定的 4G 或 Wi-Fi。
- 若下行网络良好，则执行下一步。
- 检查用户 A 是否开启了原始音频数据的回调，若开启则可以尝试关闭对应功能，然后重新入会。
- 排查发送端的问题：
- 在服务监控平台上查看用户 B 的音频采集音量和发送音量，以排查用户 B 的设备采集问题。
- 若采集音量和发送音量的数据显示不稳定，请检查用户 B 使用的音频采集设备。
- 若音量数据显示正常，则执行下一步。
- 在服务监控平台上查看用户 B 的音频上行丢包率和上行码率，以检查通话时用户 B 的上行网络情况。
- 若上行丢包率比较高或上行码率比较低，可以尝试将网络切换到稳定的 4G 或 Wi-Fi。
- 若上行网络良好，则执行步骤 2。
关于服务监控平台如何使用，具体请参考质量数据监控。
步骤2 联系技术支持
如果通过以上步骤，问题仍无法解决，请联系网易云信技术支持工程师，并提供以下信息，方便工程师快速定位问题：
| 信息类别 | 信息详情 |
|---|---|
| 必要信息 | 出现声音卡顿的房间名称（channelName）。 |
| 产生声音卡顿和听到声音卡顿的用户 ID（uid）、使用的设备类型和系统版本、使用的音频设备信息和使用场景。 | |
| 音频 Dump 文件。获取步骤请参见获取音频 Dump 文件。 | |
| 辅助信息 | SDK 日志文件。具体如何获取日志请参见 SDK 的日志从哪里获取。 |
| 出现声音卡顿现象的具体时间段。 |
声音延迟
音频数据传输链路如下：
问题原因
出现声音延迟的常见原因有：
- 网络本身存在较大的时延，或者存在丢包和抖动的情况造成接收端的 JitterBuffer 增大，从而造成较明显的声音延迟的现象。
- 设备性能消耗过大，比如 CPU 过载的情况下，如果采集或者播放线程没有及时处理和收发数据，会出现声音延迟的现象。
- 如果开启硬件的 built-in AEC 处理，会造成额外的声音延迟。
- 在 Android 设备上使用不同的音频模式（JAVA 或 OpenSL ES），声音的延迟也会存在差别。
问题自查
假设用户 A 听到用户 B 的声音出现延迟，问题排查的思路如下：
- 排查接收端的问题：
- 检测用户 A 的设备是否存在性能消耗过大的情况。
- 若 CPU 占用偏大，可以尝试关闭没有必要的应用程序或重启设备后重新入会。
- 若 CPU 占用良好，则执行下一步。
- 在服务监控平台上查看用户 A 的音频下行丢包率、卡顿率和下行码率，以检查通话时用户 A 的下行网络情况。
- 若下行丢包率、卡顿率比较高或下行码率比较低，可以尝试将网络切换到稳定的 4G 或 Wi-Fi。
- 若下行网络良好，则执行下一步。
- 查看用户 A 的设备的音频设置参数。
- 判断是否开启了硬件的 built-in AEC 处理，若开启则可以尝试关闭。
- 判断音频模式是 JAVA 或 OpenSL ES，若音频模式是 JAVA，可以尝试改为 OpenSL ES。
- 排查发送端的问题：
- 在服务监控平台上查看用户 B 的音频采集音量和发送音量，以排查用户 B 的设备采集问题。
- 若采集音量和发送音量的数据显示不稳定，请检查用户 B 使用的音频采集设备。
- 若音量数据显示正常，则执行下一步。
- 在服务监控平台上查看用户 B 的音频上行丢包率和上行码率，以检查通话时用户 B 的上行网络情况。
- 若上行丢包率比较高或上行码率比较低，可以尝试将网络切换到稳定的 4G 或 Wi-Fi。
- 若上行网络良好，则执行步骤 2。
关于服务监控平台如何使用，具体请参考质量数据监控。
步骤2 联系技术支持
如果通过以上步骤，问题仍无法解决，请联系网易云信技术支持工程师，并提供以下信息，方便工程师快速定位问题：
| 信息类别 | 信息详情 |
|---|---|
| 必要信息 | 出现声音延迟的房间名称（channelName）。 |
| 听到声音延迟的用户 ID（uid）、使用的设备类型和使用场景。 | |
| 音频 Dump 文件。获取步骤请参见获取音频 Dump 文件。 | |
| 辅助信息 | SDK 日志文件。具体如何获取日志请参见 SDK 的日志从哪里获取。 |
| 出现声音延迟现象的具体时间段。 |
