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