I2S API should support hardware that is enforcing specific physical width of the RX/TX data samples

[mnkp]

During the development of the I2S driver for NXP LPC devices #32054 it was identified that the design of I2S API does not match well hardware limitations imposed by the platform.

When the user sends data to the I2S driver they are placed in one large buffer and passed to the driver via i2s_write system call. So far the I2S API assumed that the data are always packed in an optimum way. E.g. an 8-bit sample will require one byte of storage. That is, to send 16 8-bit samples we will need a buffer of size 16. However, the NXP LPC device is not able to cope with such data. Its DMA engine can do 32-bit transfers only. It can transfer one 32-bit sample or two 16-bit samples at minimum. To support such case each 8-bit data sample in the buffer passed to i2s_write system call would need to occupy 2 bytes.

One possible solution would be to let the application determine the physical size of a single data sample expected by the driver via a new function call. ALSA library has snd_pcm_format_physical_width() which lets the application figure out the sizeof single data sample.

Alternatively we would need to add an extra configuration parameter telling the driver the format that the data is provided in. Or handle such cases via a dedicated driver specific read/write functions.

The initial discussion related to this issue took place in #32054.

API meeting 2021.03.23:

• No firm conclusion, though options would be:
• Add a format parameter of sorts to the config function, or a function that returns the required sample size in bytes
• Treat the read/write functions in this driver as device-specific and so add i2s_lpc_read/write
• Reach out to the SoF folks to try and see how common this occurrence may be: cc @lgirdwood and @lyakh and @marc-hb: is it common that i2s peripherals require data in formats that do not match the output I2S stream?

Originally posted by @carlescufi in #32054 (comment)

[mnkp]

Better to configure sample format in another I2S API call before you call this write(). I would probably use ALSA API for guidance here e.g.

https://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#gabc748a500743713eafa960c7d104ca6f
Originally posted by @lgirdwood in #32054 (comment)

I checked the ALSA API but couldn't find anything that would allow to specify physical width of the data sample. Something that snd_pcm_format_physical_width() would return.

That said, the PCM format specification states

Enumerator	Description
SND_PCM_FORMAT_S8	Signed 8 bit
SND_PCM_FORMAT_S24_LE	Signed 24 bit Little Endian using low three bytes in 32-bit word
SND_PCM_FORMAT_S24_3LE	Signed 24bit Little Endian in 3bytes format

Which seems to indicate that SND_PCM_FORMAT_S8 takes always one physical byte, since otherwise they would not need to distinguish between different 24-bit formats.

Btw, ALSA has two flavors of write() - blocking and non blocking. I'm assuming your version will block ? I'm also assuming that your API is not using DMA and directly programming the audio data to the I2S port FIFO ? (otherwise it's better to use a circular audio buffer).

In our case blocking / non blocking behavior is configurable. The specific mechanism used to transfer the data depends on the driver but they all use DMA since we're dealing with large amount of data.

[zephyrbot]

Hi @anangl,

This issue, marked as an Enhancement, was opened a while ago and did not get any traction. It was just assigned to you based on the labels. If you don't consider yourself the right person to address this issue, please re-assing it to the right person.

Please take a moment to review if the issue is still relevant to the project. If it is, please provide feedback and direction on how to move forward. If it is not, has already been addressed, is a duplicate, or is no longer relevant, please close it with a short comment explaining the reason.

@mnkp you are also encouraged to help moving this issue forward by providing additional information and confirming this request/issue is still relevant to you.

Thanks!