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:
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.
Hello,
Really 24-bit data format without padding (not aligned) is not supported.
Have a great day,
Yuri
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Hi Yuri,
Thanks for the reply. I was pretty sure from experimentation and code reading that the driver doesn't support non-aligned 24-bit data. I guess my real question is if the driver doesn't support SNDRV_PCM_FMTBIT_S24_3LE, why does it present this as a support format? I'd consider this a pretty obvious bug that should be fixed. Do you know if there is anyway of either bug reporting or patch submission to Freescale's Linux repo from the community?
Thanks,
~Matt