08.01.2020 14:37, Jon Hunter пишет: > > 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 chatted with Sameer about this, so yes the AHUB can repack, but there > is a problem with S24_LE where if we try to extract 24-bits we actually > get the upper 24-bits and not the lower LSBs in the 32-bit data element. > So actually we don't support S24_LE. > > Ben do you need 24-bit support or 32-bit or both? Any updates? Should we revert all the applied patches for now?
