Add possibility to preload I2S DMA buffer with actual data (IDFGH-6847)

[CarlosDerSeher]

If I want to start audio at a precise moment in time this will be kind of hard with the current implementation of I2S driver. There is no mechanism to fill the whole DMA buffer with actual data before starting transmission. Instead the driver will tx zero samples and if done it will send the now free tx buffer using a queue which will enable the user to add new data using i2_write(). I couldn't find a reliable solution to start audio at a precise moment using combinations of i2s_stop(), i2s_zero_dma(), i2s_write() and i2s_start() there has always been some jitter.

A possible solution I could think of would be to add the possibility to register a custom callback function in i2s_driver_install() which will be called from i2s_start(). This callback should be given access to the full I2S object so we can manipulate buffers and this object directly, giving users more low level control on i2s.

[L-KAYA]

Yes, the current driver has a lot of limitations, so we are now planning to have a driver-NG on i2s driver. It's a good idea to have an API that can send the valid data at the time that you call it. The new driver of I2S will release in v5.0.

[CarlosDerSeher]

@L-KAYA I see, so when is v5.0 expected to be released? And such functionality will be included there? At current master, after quickly checking, I didn't see much difference in how the driver works/is setup

[egnor]

I bumped into this as well. The I2S driver has certainly changed a lot in master, and the documentation is more extensive. However, on inspection, this particular buffering limitation/bug/misfeature appears not to have changed.

If handle->msg_queue were prefilled on start with every buffer (since they're all empty), we would at least not have to wait for an entire buffer loop-through of silence before any sound comes out the way we do now.

If it were possible to call i2s_channel_write() (the i2s_write() equivalent in the new API) with the peripheral in READY but not RUNNING state, then that would allow a full buffer from the jump.

(In general the buffering approach of this driver leaves something to be desired...)

[CarlosDerSeher]

That's a pitty. I have to say I didn't look into master recently because I solved my problem by pulling in i2s driver code as a custom component and adding a function which will prefill DMA buffers with valid data and resets all pointers. It still would be nice to have a API which can do that natively...

[CarlosDerSeher]

Looks promising. Thanks for the changes