I2S data offset when stream is interrupted

carlocaione — Mon, 20 May 2024 08:15:47 GMT

The setup

Using the EVK MIMXRT685 as I2S SLAVE configured as:

TDM / DSP mode A (mono)
48kHz (SCK at ~25MHz)
16 slots (channels) per frame
512 SCK per frame
32 SCK per slot
32 bits of audio data per slot, left aligned
WS pulsed for one SCK time
Data sampled on WS rising edge

The following is a sample trace:

Now let's see what is the problem.

The problem

I'm interested in the RX path, that is using the EVK to record data received on the I2S interface sent for example by a PC. For the sake of simplicity let's assume that from the PC I'm streaming data only of the first channel out of 16.

We can do that by doing for example on a Linux machine:

speaker-test -r 48000 -c 16 -f 1000 -F S32_LE -D hw:APE,1 -t sine -s 1

With this command we are sending through the I2S interface a stream of data at 48kHz / 16 channels / S32_LE with a 1kHz sine wave only on the first channel, all the other channels are silent.

We try to send this data through several times, but instead of waiting for the stream to finish, we interrupt the streaming several times by pressing CTRL+C and giving the command again. This is possibly interrupting the stream of data mid-frame and restarting it from scratch.

What do we expect to see on the EVK side

We would expect to see in the I2S RX buffer something like this when the command is running (each 0 and X is 1 byte):

CH1  CH2  CH3  CH4  CH5  CH6  CH7  CH8  CH9  CH10 CH11 CH12 CH13 CH14 CH15 CH16 CH1  CH2  CH3...
XXXX 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 XXXX 0000 0000...

That is we expect to see data only on the Channel 1 and zeros on all the other channels when the command is streaming out data.

What we actually see on the EVK side

What actually happens is that the data is found on a different channel than 1. An offset is introduced in the recorded data.

For example:

CH1  CH2  CH3  CH4  CH5  CH6  CH7  CH8  CH9  CH10 CH11 CH12 CH13 CH14 CH15 CH16 CH1  CH2  CH3...
0000 0000 0000 0000 0000 0000 XXXX 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000...

In this case the data that is supposed to be on CH1, it is found on CH7 instead.

The reproducer

At https://gist.github.com/carlocaione/5c471fd25f083110e6c9f3c426874f29 the reproducer for the problem.

Since we need 16 channels we are using two FLEXCOMM interfaces with signal sharing and we use a ping-pong linked transfer onto two different buffers.

If we set a breakpoint at line 80 and we try to reproduce the issue, we can see that the execution stops at that line after a few attempts because valid data was found in channel 7 instead than channel 1.

A theory about the issue

What is possibly happening is that when we stop the streaming of data in the middle of the frame, the data in the FIFO up to that point is still flushed in memory, causing the offset when the streaming starts again at a later time.

Position in the RX buffer: CH1  CH2  CH3  CH4  CH5  CH6  CH7  CH8  CH9  CH10 CH11 CH12 CH13 CH14 CH15 CH16
Data transmitted :         XXXX 0000 0000 0000 0000 0000 XXXX 0000 0000 0000 0000 0000 0000 0000 0000 0000 
                           ^                             ^
                           RX is started                 Here we stop the streaming and start it again

Open questions

A reasonable expectation to me about the behaviour of I2S + DMA is that when the data is flushed to memory, this is done in chunks that are multiple of the size of the frame (64 bytes in this case) otherwise how can we detect when only part of the frame has been flushed to memory especially when using loop descriptors?

回复： I2S data offset when stream is interrupted

Gavin_Jia — Fri, 28 Jun 2024 07:22:15 GMT

Hi @carlocaione ,

I apologize for the late response. I have spent the time contacting the relevant internal experts to address the issues you mentioned.

Now there's a couple of pieces of information that I need to check with you, the first being how the PC is connected to the board, the

1. Audio from PC via USB Audio

2. Audio interface from PC directly connected to the board's codec

3. PC directly outputs I2S data by some means and then connects to the Flexcomm interface

Also, can you help with the waveform graph of the I2S at the moment when Ctrl-C is performed? This will help us to localize the problem. Thanks in advance!

Best regards,
Gavin

Re: I2S data offset when stream is interrupted

carlocaione — Fri, 28 Jun 2024 07:47:41 GMT

Hi @Gavin_Jia the problem was confirmed and better analysed here https://github.com/nxp-mcuxpresso/mcux-sdk/issues/197 I was also able to find a workaround that I describe in that thread. So I'm going to close this ticket down and people can refer to the github issue for more informations

topic I2S data offset when stream is interrupted in i.MX RT Crossover MCUs