SSI and PCM Format

[paul_katarzis]

I am trying to understand how to write platform, codec, and machine drivers for ALSA SoC. I will be using the SSI platform driver written by Freescale, my own codec driver, and will link the two in a machine driver. I am having some trouble understanding the PCM formats given by the SNDRV_PCM_FMTBIT_* definitions and how to correctly set the PCM format field in snd_soc_dai_driver structures. I tried looking elsewhere online but unfortunately a lot of the documentation related to ALSA is either ambiguous or just non existent.

• What is the meaning of big-endian and little-endian in the SNDRV_PCM_FMTBIT_* definitions? Is it a statement about how multi-byte PCM data is stored in memory? Is it a statement about the order in which bytes are sent across an audio interface such as I2S? Is it a statement about the order in which bits are sent across an audio interface such as I2S?
  
• The Linux SSI driver written by Freescale says the following in a comment about PCM format: "The SSI has a limitation in that the samples must be in the same byte order as the host CPU. This is because when multiple bytes are written to the STX register, the bytes and bits must be written in the same order." Is this saying that if a multi-byte PCM data value is stored in big-endian in memory then it will be written to the STX register with the most significant byte in the lower end of the register?
• The codec that I am using requires data over I2S to be sent most significant bit first with multi-byte data sent in big-endian. The data will be stored in big-endian within the codec. Because of this, I set the PCM data format as big-endian in the snd_soc_dai_driver structure of my codec driver. I noticed that the Linux SSI driver written by Freescale sets the PCM data format as little-endian in its snd_soc_dai_driver. Will there be a fundamental incompatibility in the snd_soc_dai_link structure of my machine driver that connects SSI and the codec?
• According to the SSI section of the i.MX6 Quad reference manual, there doesn't seem to be a restriction as to whether or not PCM data has to be signed or unsigned. However, the Linux SSI driver written by Freescale sets the format to only signed when setting up its snd_soc_dai_driver structure. Why is this?

[igorpadykov]

Hi Paul

*  for alsa data endian definitions one can look at alsa project documentation and alsa mail lists.

PCM - MultimediaWiki 

ALSA project - the C library reference: Helper Functions 

[alsa-devel] WM9712 - Big and little endian format conversion. 

*  right, data bytes and bits written in STX register use the same order
as arranged in memory. So SSI module has not special "endian" settings/conversions.

> Is this saying that if a multi-byte PCM data value is stored in big-endian in memory
>then it will be written to the STX register with the most significant byte in the lower end of the register?

in general, SSI data bit/byte order remains the same as it was arranged in memory. May be useful to look at
sect.61.8.2.1 Data Alignment Formats Supported i.MX6DQ Reference Manual
https://www.nxp.com/docs/en/reference-manual/IMX6DQRM.pdf

*  NXP sound drivers support limited number of codecs and pcm formats. One can refer to

sect.7.1.1 ALSA Sound Driver Introduction attached Linux Manual. Full list of alsa formats can be found on

ALSA project - the C library reference: PCM Interface 

*  Linux SSI driver written by NXP (Freescale) does not support all alsa formats. Supported only

configurations presented in NXP reference boards. Other formats can be added by customers themselves.

Below some useful links for adding support for new formats:
ALSA is not supporting 16 bits signed audio · Issue #173 · raspberrypi/firmware · GitHub 
c++ - Signed 16-bit ALSA PCM data to U8 Conversion on Linux - Stack Overflow 

Best regards

igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[paul_katarzis]

Hello Igor,

Thank you for your response. I will try to dig deeper into ALSA documentation for some answers. I would like to confirm my understanding of the SSI STX register using an example. Suppose the processor stores data in little-endian and the STX register is configured for MSB aligned 16-bit data. Suppose I want to transmit the value 0x2211. This value is stored at address N as a 32 bit value as follows:

N+0: 0x11

N+1: 0x22

N+2: 0x00

N+3: 0x00

When this value is moved into the STX register it will look like 0x00002211. However, because of the 16 bit MSB setting of the STX register, only 0x0000 is transmitted. To transmit the value correctly it would have to be stored in memory as the following 32 bit value:

N+0: 0x00

N+1: 0x00

N+2: 0x11

N+3: 0x22

When this value is moved into the STX register it will look like 0x22110000. Since the STX register is MSB aligned for 16 bit data, 0x22111 will be transmitted.

Is this correct?

[igorpadykov]

Hi Paul

from sect.61.8.2.1 Data Alignment Formats Supported Reference Manual:

"With MSB alignment, the most significant byte is bits 31 through 24 of the data register
if the word length is larger than or equal to 16 bits."

so seems value 0x2211 will appear as 0x22110000 :

Best regards

igor