On 30/01/2020 09:31, Clemens Ladisch wrote:
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.
Which is wrong, since this is exactly what the hardware implements.
The DMA fetches 32 bit words, and then the front end dispatches only
24 bits of these to the I2S/TDM
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
https://www.codethink.co.uk/privacy.html
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
