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? Jon -- nvpublic
