On 23/01/2020 21:59, Ben Dooks wrote: > 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. Yes that is going to be a problem. I assume that your codec wants a 256*fs MCLK? Maybe in that case you are better off having the codec drive the bit clock and fsync? Is 24-bit critical to what you are doing? Otherwise maybe we should drop the 24-bit support for now and just keep 32-bit. Jon -- nvpublic
