[alsa-devel] (no subject)

[Clemens Ladisch]

Ben Dooks wrote:
> On 29/01/2020 00:17, Dmitry Osipenko wrote:
>> 28.01.2020 21:19, Jon Hunter пишет:
>>> On 28/01/2020 17:42, Dmitry Osipenko wrote:
>>>> 28.01.2020 15:13, Mark Brown пишет:
>>>>> On Mon, Jan 27, 2020 at 10:20:25PM +0300, Dmitry Osipenko wrote:
>>>>>> 24.01.2020 19:50, Jon Hunter пишет:
>>>>>
>>>>>>>                  .rates = SNDRV_PCM_RATE_8000_96000,
>>>>>>>                  .formats = SNDRV_PCM_FMTBIT_S32_LE |
>>>>>>> -                          SNDRV_PCM_FMTBIT_S24_LE |
>>>>>>> +                          SNDRV_PCM_FMTBIT_S24_3LE |
>>>>>
>>>>>> It should solve the problem in my particular case, but I'm not sure that
>>>>>> the solution is correct.
>>>>>
>>>>> If the format implemented by the driver is S24_3LE the driver should
>>>>> advertise S24_3LE.
>>>>
>>>> It should be S24_LE, but seems we still don't know for sure.
>>>
>>> Why?
>> /I think/ sound should be much more distorted if it was S24_3LE, but
>> maybe I'm wrong.
>
> S24_3LE is IICC the wrong thing and we can't support it on the tegra3

There are three ways of arranging 24-bit samples in memory:

S24_3LE: 24-bit samples in 24-bit words without padding
S24_LE:  24-bit samples in 32-bit words, aligned to the LSB
S32_LE:  24-bit samples in 32-bit words, aligned to the MSB

It is very unlikely that your hardware implements S24_LE.

If a S32_LE driver wants to describe how many bits are actually used, it
should install a msbits constraint (snd_pcm_hw_constraint_msbits()).


Regards,
Clemens