what is the difference between SNDRV_PCM_FMTBIT_S24_LE and SNDRV_PCM_FMTBIT_S24_3LE

what is the difference between SNDRV_PCM_FMTBIT_S24_LE and SNDRV_PCM_FMTBIT_S24_3LE

[Zhang wei]

There are two definitions In the file include/sound/asound.h
SNDRV_PCM_FORMAT_S24_3LE and SNDRV_PCM_FORMAT_S24_LE.

What is the difference between them? 

Thanks a lot.

zw

Re: what is the difference between SNDRV_PCM_FMTBIT_S24_LE and SNDRV_PCM_FMTBIT_S24_3LE

[Clemens Ladisch]

Zhang wei wrote:
> SNDRV_PCM_FORMAT_S24_3LE and SNDRV_PCM_FORMAT_S24_LE.
>
> What is the difference between them?

SNDRV_PCM_FORMAT_S24_3LE stores the 24 in three bytes, and is used only
for USB.

SNDRV_PCM_FORMAT_S24_LE stores the 24 bits in the lower bits of a 32-bit
word, and is almost never used.

Most devices that support 24 bits use SNDRV_PCM_FORMAT_S32_LE, which
stores the sample's bits in the upper bits of a 32-bit word.


Regards,
Clemens

Re: what is the difference between SNDRV_PCM_FMTBIT_S24_LE and SNDRV_PCM_FMTBIT_S24_3LE

[Clemens Ladisch]

(please do not drop the mailing list from replies.)

Zhang wei wrote:
> I do not really understand. For example,an codec is wm8985 ...

The SNDRV_PCM_* symbols specify the format in which samples are
stored in memory.

I do not know how ASoC maps these symbols to on-the-wire formats.

>>Most devices that support 24 bits use SNDRV_PCM_FORMAT_S32_LE, which
>>stores the sample's bits in the upper bits of a 32-bit word.
>
> But how to distinguish the SNDRV_PCM_FORMAT_S24_LE and the REAL
> SNDRV_PCM_FORMAT_S32_LE?

If a 24-bit sample with the value 0x123456 is stored in memory, it looks
like this:
SNDRV_PCM_FORMAT_S24_LE: 56 34 12 00
SNDRV_PCM_FORMAT_S32_LE: 00 56 34 12


Regards,
Clemens

Re: what is the difference between SNDRV_PCM_FMTBIT_S24_LE and SNDRV_PCM_FMTBIT_S24_3LE

[Gabriel M. Beddingfield]

On 04/11/2013 02:35 AM, Clemens Ladisch wrote:
> (please do not drop the mailing list from replies.)
>
> Zhang wei wrote:
>> I do not really understand. For example,an codec is wm8985 ...
>
> The SNDRV_PCM_* symbols specify the format in which samples are
> stored in memory.
>
> I do not know how ASoC maps these symbols to on-the-wire formats.

The SNDRV_PCM_* symbol specifies the format of the audio in RAM, and 
transfers that audio to the digital audio interface (DAI) on the CPU 
side.  (E.g. the OMAP McBSP.)

The on-the-wire format is set up by the ASoC machine driver (i.e. "sound 
card.")  It will configure the CPU DAI (e.g. the OMAP McBSP) and the 
codec (e.g. wm8985) to expect the same "on-the-wire" format.  For 
example, in sound/soc/omap/omap-twl4030.c (beagleboard's machine driver) 
the on-the-wire format is done in omap_twl4030_hw_params() like this 
(edited for brevity):

         fmt =   SND_SOC_DAIFMT_I2S |
                 SND_SOC_DAIFMT_NB_NF |
                 SND_SOC_DAIFMT_CBM_CFM;

         /* Set codec DAI configuration */
         ret = snd_soc_dai_set_fmt(codec_dai, fmt);

         /* Set cpu DAI configuration */
         ret = snd_soc_dai_set_fmt(cpu_dai, fmt);

The CPU DAI is responsible for converting the SNDRV_PCM_* format into 
the serial format.  Therefore, the conversions that it supports is 
totally hardware-dependent.

-gabriel

Re: what is the difference between SNDRV_PCM_FMTBIT_S24_LE and SNDRV_PCM_FMTBIT_S24_3LE

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 814 bytes --]

On Thu, Apr 11, 2013 at 08:27:21AM -0700, Gabriel M. Beddingfield wrote:
> On 04/11/2013 02:35 AM, Clemens Ladisch wrote:

> >I do not know how ASoC maps these symbols to on-the-wire formats.

> The SNDRV_PCM_* symbol specifies the format of the audio in RAM, and
> transfers that audio to the digital audio interface (DAI) on the CPU
> side.  (E.g. the OMAP McBSP.)

...

> The CPU DAI is responsible for converting the SNDRV_PCM_* format
> into the serial format.  Therefore, the conversions that it supports
> is totally hardware-dependent.

The drivers should in general be defaulting to using exactly the right
number of bits on the wire, aside from the marginal efficiency gains
if hardware has limitations they tend to be an inability to cope with
extra BCLKs so this improves robustness and compatibility.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]