EC200U ql_aud_record_stream_start_ex 接口问题

技术专题 Quecopen方案
1

在opensdk里，使用ql_aud_record_stream_start_ex录制 5s的数据 为什么有**27,241 kb **
随便取了一次打印日志，反正就是很大
粗略的在回调函数里打印了下日志，基本都是1-3帧的返回长度，文档写的不是20ms返回一次吗

	config.channels = 1;
	config.samplerate = 8000;
	config.amrnb_param.amrnb_mode = AMRNB_MODE_475;

4.75kbps 13字节一帧， 按照20ms一帧的理论值，1s 不才50帧吗？50x13x5 哪有这么夸张
这个接口录制返回的数据都多少了，然后偏偏ql_aud_play_stream_start 播放是正常的，大概也就5s左右。

我从远端接收语音包后组合，传入这个播放接口，整个组合发送就跟被加速了一样，单帧或者批量少帧调用这个接口就是dededede的声音根本听不清
明确了远端也是相同格式，音频帧都是04开头的，中间也没有丢包，包的数量和数据都没问题。但是远端录制的帧就不会像这个接口一样一秒能出这么多数据的。然后远端发送的音频下载播放也ok的啊

最后ql_aud_pcm_open的poc模式又只支持pcm的格式，但是我音频需要的是amr-nb的格式，也没看到有什么其他转换的方法和其他录制播放的接口。

底板：LTEOPENEVB-KIT
模组：EC200UCNAP-N05-SGNSA
外置codec：alc5616 ？会跟这个有关系吗

我就觉得很离谱，流式的录制接口数据量这么大，我要是存队列的去逐帧发送，模块压力也爆大啊。对接的技术找的开发就会说接口没问题，迭代这么多次了。。。。他自己也不去试试我也是佩服

2

根据您描述的现象，录制数据量巨大很可能是打印单位混淆导致，实际录制输出的可能是原始 PCM 数据而非编码后的 AMR-NB 帧。在 QuecOpen 录音流接口中，若参数设置与外部 codec 不匹配，回调输出的数据长度可能与预期不符。

针对您的问题，有以下几点可确认和排查：

  • 数据量单位：建议先检查日志中 27,241 的单位是否为 Byte。若实际是 27,241 Byte（约 26.6 KB），配合 8 kHz / 16 bit / 单声道 PCM 计算，5 秒理论数据量约为 78 KB，如录制时间略短或 bit 位宽不同则接近该值；若确实是 27 MB 则极不合理，可重点排查外置 codec ALC5616 的采样率与接口配置是否一致。
  • AMR 编码：ql_aud_record_stream_start_ex 的回调数据在未额外调用编码函数时，通常输出原始 PCM 流。文档中的 amrnb_param 可能仅用于后续播放或内部封装，未使能自动编码，从而导致回调数据长度按 PCM 计算。
  • 外置 Codec 影响：底板 LTEOPENEVB-KIT 搭载的 ALC5616 需要额外的 I²S 和时钟配置，若其工作模式或采样率与模组预期不符，会影响录音的实际数据产出，建议检查 codec 初始化逻辑。
  • 远端播放问题：ql_aud_play_stream_start 是流式播放接口，要求按 20ms 等间隔逐帧写入。一次性写入多个帧会导致缓冲区溢出、播放加速和声音异常，应改为用定时器每 20ms 写入 1 帧（13 字节）数据。
  • 格式转换：若确认必须使用 AMR-NB，可尝试 QuecOpen 中的 AMR 软件编码 API（如存在）或改用 ql_aud_pcm_open 以 PCM 格式与远端协商，目前未查到即开即用的 PCM 转 AMR 硬件接口。

当前知识库及公开资料中未能直接定位到与您完全匹配的帖子与文档，如仍无法解决，请等待技术工程师进一步协助。

本回答仅供参考。若问题已解决，可标记为 :white_check_mark:解决方案 ；若仍有疑问，请等待官方技术人员回复，最终请以专业解答为准。

4

我看你有通过移远技术支持反馈过这个问题，请问您的问题解决了吗？