I2S driver should have the ability to start in and out at the same time (IDFGH-15094)

[pggh]

Is your feature request related to a problem?

Certain uses cases require a complex test signal to be sent to a DAC and read a 'distorted' analog signal back using an ADC.
Depending on the analysis to be performed (eg. delay), it is required to have the internal (digital) delay between the output and input signal under control.

Describe the solution you'd like.

A function in the I2S driver that is able to start (enable) the rx and tx channels synchronously. Therefor if the dout would be externally connected to din instead of the DAC and ADC, the received data would be identical to the data sent. (first sample in the tx-data will be the first sample in the rx-data).
Even better would be a function that allows to specify the exact offset between sent and received data. This would allow to compensate the delays of the DAC and ADC as well.

Describe alternatives you've considered.

No response

Additional context.

If the peripheral module does not directly support this, it might be possible to loop-back the dout data to din using an unused pin (to prevent the real dout pin to output unwanted signals) and generate a synchronization signal in the driver to get the matching samples in output and input. Before the synchronization signal ends, the driver would then need to switch the dout and din to the correct pins without disabling/re-enabling the channels.

[L-KAYA]

@pggh Thanks for reporting!

Please correct me if my understanding is wrong. You want to know and adjust the digital data send latency to synchronize the DAC output and ADC input, right? And the best case is that ADC finished to read the last data in the program, meanwhile the current data is just sent to DAC.

I'm afraid that this may not possible to realize. Here is the data flow:

As you can see, there are too many stages in this data circle, for example, the DMA has arbitration, the DAC/ADC need time for conversion. Therefore, and the latency of each section is not totally fixed, which leads to the final latency unpredictable.

And the data flow speed is mainly decided by the sample rate, the faster the sample rate is, the shorter time the data will stay in these middle stage, i.e., some stages latency will be smaller (like ADC/DAC converter, FIFO), however, the others (like internal bus, DMA) are not affected. So, the latency is also non-linear against the sample rate.

That's why we can't control the latency precisely and totally at our will. Unless the hardware is designed to have precious latency in each stage, and have some method to compensate the non-linear latency.

[pggh]

@L-KAYA I think you are mixing 2 different concepts in your argument:

• the physical time (aka wall clock)
• the logical relation between in and out samples

For the following discussion lets ignore any cases where samples get lost due to insufficient buffers or performance.

You have output samples O0, O1, ... On what will be output by the I2S (to a DAC).
You get input samples I0, I1, ..., In that the I2S will provide to the application.

When you loop-back dout to din and start the tx and rx channels (currently with an unpredictable timing between them) you get some of the output samples back as input samples. It might me the case that (when the output starts before the input) some of the output samples (O0 .. Oj) get lost and O(j+1) .. On will be available as input samples I0 .. I(n-j) followed by some undefined/zero samples.
If the input starts before the output I0 .. Ik contain some undefined/zero samples and I(k+1) .. In will contain O0 .. O(n-k).

What this issue is about is to control the offset (j, k) between the logical samples and make it 0 or at least predicable. If the offset is 0 as desired, you preload and write the output samples O0 ... On to the tx channel and the samples I0 .. In you read from the input channel will contain exactly the data from the output samples.

Of course the physical time between you start preloading/writing the samples and the time read returns the first data will depend on the DMA buffer size and the FIFO sizes. At least 2*(DMA buffer + FIFO in samples)/sample_rate. Most likely more if the write/read does not happen immediately. That's ok. It is only relevant that the first sample read corresponds to the first sample written and so on.