24.01.2020 01:11, Dmitry Osipenko пишет: > 24.01.2020 00:59, Ben Dooks пишет: >> 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 should have checked pll_a_out0 rate, for 24bit 2ch, I get >> pll_a_out at which makes: >> >> 11289600/(24*2*44100) = 5.3333333333 >> >> For some reason the PLL can't get a decent divisor for this. > > Have you tried to adjust the predefined PLLA rate? Please see > tegra_clk_init_table in drivers/clk/tegra/clk-tegra30.c. Will be > interesting if it works with that. > > Sowjanya said that the PLLA rate setup is going to be moved to the audio > driver [1], maybe that's what we already need for 24bit. > > [1] https://lkml.org/lkml/2020/1/21/744 Actually, tegra_asoc_utils_set_rate() sets the PLLA rate, but the values are hardcoded there. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
