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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
