[00:06:49.411,024] <inf> i2s_nrfx: I2S MCK frequency: 256000, actual PCM rate: 8000
Hi,
Error code 11 is -EAGAIN, which simply means the I2S TX queue was full and i2s_write() timed out waiting for a free slot. This is expected if audio buffers are queued faster than the I2S hardware can transmit them. When this happens, one of the way could be to wait for some micro seconds and retry i2s_write().
Also note that as previously recommended increasing NUM_BLOCKS only adds more application buffers; it doesn’t change the driver’s internal TX queue size. To check that part, could you please share the relevant section of your prj.conf, especially any I2S or nrfx-related options?
Regarding MCK, you don’t need to generate it separately in code when I2S is set up as master.
Best Regards,
Syed Maysum
what changes i made my code to get proper transmission
Best Regards
Sharon
Hi,
Thanks for sharing the details and prj.conf. With retry pacing in place and CONFIG_I2S_NRFX_TX_BLOCK_COUNT=8, the earlier -EAGAIN TX queue behavior should now be handled correctly on the application side.
Regarding MCK: the nRF I2S peripheral does support generating MCK at 256x LRCK as shown here in master mode using the appropriate I2S ratio configuration. The current log shows 32x LRCK simply because of the current I2S clock configuration, not due to a hardware limitation.
The remaining question is whether your codec strictly requires 256x LRCK or just recommends it. If it is required, the next step would be to adjust the I2S configuration (ratio and MCK frequency) to generate MCK for the selected sample rate and verify that this frequency is achievable and within the codec’s tolerance.
Best Regards,
Syed Maysum
i2s require 4mhz
Thanks for sharing the details and prj.conf. With retry pacing in place and CONFIG_I2S_NRFX_TX_BLOCK_COUNT=8, the earlier -EAGAIN TX queue behavior should now be handled correctly on the application side.
i got same -eagen error
Thanks for sharing the details and prj.conf. With retry pacing in place and CONFIG_I2S_NRFX_TX_BLOCK_COUNT=8, the earlier -EAGAIN TX queue behavior should now be handled correctly on the application side.
i got same -eagen error