Hi All,
I'm come across a curiosity with the SSI driver in Linux that I was hoping to get some insight on. When opening an ALSA device that uses the fsl_ssi under the hood and you use 24-bit packed data format (snd_pcm_format_s24_3le), it appears that it still treats it like padded 24-bit (snd_pcm_format_s24_le). I think what is happening is that the DMA engine is simply reading the packed 24_3le data and stuffing it right in the ssi fifo (still packed). I'm guessing this is because of one of two things:
- First, maybe the intent was to have the DMA engine do the unpacking before putting it in the FIFO (via a custom DMA program in the SDMA engine) and this just never got implemented
- Second, the support for 24_3le format (SNDRV_PCM_FMTBIT_S24_3LE in the fsl_ssi.c driver) was never intended to be supported and should be removed
You can show the effects of this bug by using a tool like aplay, opening the hardware directly avoiding ALSA's re-sample/re-format and playing a wav file that is 24-bit. If you look at the SSI output on a scope, you will see that every fourth byte from the wav file data is dropped because it is effectively getting treated as padding when writing to the 32-bit input of the SSI FIFO. (aplay -D hw:0 24bit_file.wav).
I'm trying to figure out if I'm missing something here, or if this is actually a bug.
