28.01.2020 16:19, Jon Hunter пишет:
On 28/01/2020 08:59, Ben Dooks wrote:
On 27/01/2020 19:23, Dmitry Osipenko wrote:
27.01.2020 22:20, Dmitry Osipenko пишет:
24.01.2020 19:50, Jon Hunter пишет:
On 23/01/2020 19:38, Ben Dooks wrote:
On 07/01/2020 01:39, Dmitry Osipenko wrote: > 06.01.2020 22:00, Ben Dooks пишет: >> On 05/01/2020 10:53, Ben Dooks wrote: >>> >>> >>> On 2020-01-05 01:48, Dmitry Osipenko wrote: >>>> 05.01.2020 03:04, Ben Dooks пишет: >>>>> [snip] >>>>> >>>>> I've just gone through testing. >>>>> >>>>> Some simple data tests show 16 and 32-bits work. >>>>> >>>>> The 24 bit case seems to be weird, it looks like the 24-bit >>>>> expects >>>>> 24 bit samples in 32 bit words. I can't see any packing >>>>> options to >>>>> do 24 bit in 24 bit, so we may have to remove 24 bit sample >>>>> support >>>>> (which is a shame) >>>>> >>>>> My preference is to remove the 24-bit support and keep the 32 >>>>> bit in. >>>>> >>>> >>>> Interesting.. Jon, could you please confirm that 24bit format >>>> isn't >>>> usable on T30? >>> >>> If there is an option of 24 packed into 32, then I think that would >>> work. >>> >>> I can try testing that with raw data on Monday. >> >> I need to check some things, I assumed 24 was 24 packed bits, it >> looks >> like the default is 24 in 32 bits so we may be ok. However I need to >> re-write my test case which assumed it was 24bits in 3 bytes >> (S24_3LE). >> >> I'll follow up later, > > Okay, the S24_3LE isn't supported by RT5640 codec in my case. I > briefly > looked through the TRM doc and got impression that AHUB could re-pack > data stream into something that codec supports, but maybe it's a > wrong > impression. > _________________________________
I did a quick test with the following:
sox -n -b 16 -c 2 -r 44100 /tmp/tmp.wav synth sine 500 vol 0.5 sox -n -b 24 -c 2 -r 44100 /tmp/tmp.wav synth sine 500 vol 0.5 sox -n -b 32 -c 2 -r 44100 /tmp/tmp.wav synth sine 500 vol 0.5
The 16 and 32 work fine, the 24 is showing a playback output freq of 440Hz instead of 500Hz... this suggests the clock is off, or there is something else weird going on...
I was looking at using sox to create such as file, but the above command generates a S24_3LE file and not S24_LE file. The codec on Jetson-TK1 supports S24_LE but does not support S24_3LE and so I cannot test this. Anyway, we really need to test S24_LE and not S24_3LE because this is the problem that Dmitry is having.
Ben is S24_3LE what you really need to support?
Dmitry, does the following fix your problem?
diff --git a/sound/soc/tegra/tegra30_i2s.c b/sound/soc/tegra/tegra30_i2s.c index dbed3c5408e7..92845c4b63f4 100644 --- a/sound/soc/tegra/tegra30_i2s.c +++ b/sound/soc/tegra/tegra30_i2s.c @@ -140,7 +140,7 @@ static int tegra30_i2s_hw_params(struct snd_pcm_substream *substream, audio_bits = TEGRA30_AUDIOCIF_BITS_16; sample_size = 16; break; - case SNDRV_PCM_FORMAT_S24_LE: + case SNDRV_PCM_FORMAT_S24_3LE: val = TEGRA30_I2S_CTRL_BIT_SIZE_24; audio_bits = TEGRA30_AUDIOCIF_BITS_24; sample_size = 24; @@ -318,7 +318,7 @@ static const struct snd_soc_dai_driver tegra30_i2s_dai_template = { .channels_max = 2, .rates = SNDRV_PCM_RATE_8000_96000, .formats = SNDRV_PCM_FMTBIT_S32_LE | - SNDRV_PCM_FMTBIT_S24_LE | + SNDRV_PCM_FMTBIT_S24_3LE | SNDRV_PCM_FMTBIT_S16_LE, }, .capture = { @@ -327,7 +327,7 @@ static const struct snd_soc_dai_driver tegra30_i2s_dai_template = { .channels_max = 2, .rates = SNDRV_PCM_RATE_8000_96000, .formats = SNDRV_PCM_FMTBIT_S32_LE | - SNDRV_PCM_FMTBIT_S24_LE | + SNDRV_PCM_FMTBIT_S24_3LE | SNDRV_PCM_FMTBIT_S16_LE, }, .ops = &tegra30_i2s_dai_ops,
Jon
It should solve the problem in my particular case, but I'm not sure that the solution is correct.
The v5.5 kernel is released now with the broken audio and apparently getting 24bit to work won't be trivial (if possible at all). Ben, could you please send a patch to fix v5.5 by removing the S24 support advertisement from the driver?
I also suspect that s32 may need some extra patches and thus could be worthwhile to stop advertising it as well.
As far as I am aware that works and we can hit the audio rates for it.
I ran a test on Tegra124 Jetson-TK1 and 24-bit playback seems to work as Ben has indicated. So I don't think it is broken.
Have you tried to replicate my case by playing the video file?
Can you try Ben's testcase on Tegra30 (ie. generate a tone using sox and use aplay to play)?
Surely I can try, but only if you'll share the sample file with me and give precise instructions how to test it.