1
完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
问题描述:
连接Mic并设置I2S后工作不正常,想请教下是不是我参数设置有误。 已知信息: Mic输出的音频为24位大端数据,为标准Philips格式(数据延后一个clk),且要求channel为32位宽(datasheet要求SCK频率为WS的64倍)。 现象: 使用逻辑分析仪抓包发现每个channel的sck数量始终等于代码中定义的采样深度(bits_per_sample),与通道深度无关(bits_per_chan)。例如(bits_per_sample=24,bits_per_chan=32)时抓包发现左声道只有24个clk,bits_per_sample=16时左声道只有16个clk。 抓包结果如图,实际在左声道时只有16个clk出来。 实际效果 预期效果: 如图,预期应该在每个通道设置有32个clk出来,但是实际只采样最前面的24(16)个bit到内存中,下图效果是将bits_per_sample 设置为32时得到的,但是这样设置的话,虽然每个channel是32bit了,但是采样到的最低一个字节为无意义的信号(mic在第24bit发出后就高阻态了),浪费宝贵的空间不说,需要软件再做处理,又要浪费cpu时间。 期望效果 此外,我也尝试了(代码中注释掉的)i2s_set_clk,使用该函数后也同样无法将channel的深度设置为32。 // ESP_ERROR_CHECK(i2s_set_clk(I2S_MIC_BUS_PORT, I2S_MIC_SAMPLE_RATE, (I2S_BITS_PER_CHAN_32BIT << 16) | I2S_BITS_PER_SAMPLE_24BIT, I2S_CHANNEL_MONO)); 根据IDF的doc所述,set_clk方法的第三个参数的高16位用于指示channel有多少个bits宽,低16bit用于指示channel里的数据有多少个bit宽,但是实测并没有产生等于高16位所指示的数量的clk。 /* You can reset parameters by calling 'i2s_set_clk' 根据现象推断,设置的bits_per_chan未起到作用,请问是我哪里设置有问题还是这是IDF中/硬件中的问题? 如果是代码参数设置问题,请指出如何实现所需功能(bits_per_chan的意义何在,如何使用)。 如果是库或者硬件问题,请指点下哪个版本的IDF或芯片解决了这个问题。 感激不尽 环境: IDF:v5.0-dev-595-g98ad01e5fc Mic:INMP441 24bit I2S MCU:ESP32-WROOM-32U (rev版本暂未查,可能比较老,但errata里未找到相关信息,应该不重要) 不重要的环境(Win10+VisualStudio2022,供电使用IdealDiode线或了USB与外部电源)
|
|
相关推荐
1个回答
|
|
从您的描述来看,问题可能出在I2S配置上。在I2S通信中,bits_per_sample 和 bits_per_chan 是两个不同的概念:
1. bits_per_sample:每个采样点的位数,即每个音频样本的数据宽度。在您的例子中,Mic输出的音频为24位大端数据。 2. bits_per_chan:每个通道的数据宽度。在您的例子中,datasheet要求channel为32位宽。 根据您的描述,逻辑分析仪抓包结果显示每个channel的sck数量始终等于bits_per_sample,而不是bits_per_chan。这可能导致数据传输不完整或错误。 为了解决这个问题,您可以尝试以下步骤: 1. 检查I2S配置:确保您的I2S配置正确地设置了bits_per_sample和bits_per_chan。根据您的描述,bits_per_sample应为24,bits_per_chan应为32。 2. 检查时钟配置:确保SCK频率设置正确。根据您的描述,SCK频率应为WS的64倍。检查您的时钟配置是否满足这个要求。 3. 检查数据对齐:由于Mic输出的是24位大端数据,确保您的I2S配置正确地处理了数据对齐。这可能需要在接收端进行一些额外的处理,以确保数据正确地对齐到32位通道宽度。 4. 检查数据接收逻辑:确保您的数据接收逻辑能够正确地处理bits_per_sample和bits_per_chan。这可能包括在接收到每个采样点后,将其扩展到bits_per_chan的宽度。 5. 使用调试工具:使用逻辑分析仪或其他调试工具,仔细检查I2S通信过程中的数据和时钟信号。这可以帮助您找到问题所在,并确保数据传输正确。 通过以上步骤,您应该能够找到问题所在并解决I2S通信不正常的问题。如果问题仍然存在,请检查硬件连接和Mic本身是否存在问题。 |
|
|
|
只有小组成员才能发言,加入小组>>
1143 浏览 1 评论
582浏览 6评论
480浏览 5评论
有没有办法在不使用混杂模式的情况下实现Wifi驱动程序接收缓冲区访问中断呢?
465浏览 5评论
466浏览 4评论
441浏览 4评论
小黑屋| 手机版| Archiver| 德赢Vwin官网 ( 湘ICP备2023018690号 )
GMT+8, 2024-12-23 19:15 , Processed in 0.946098 second(s), Total 79, Slave 63 queries .
Powered by 德赢Vwin官网 网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
德赢Vwin官网 观察
版权所有 © 湖南华秋数字科技有限公司
德赢Vwin官网 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191 工商网监 湘ICP备2023018690号