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