You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
sof audio pipeline with the format of 24bit doesn't work on HDA platform #700
If pipeline format is set to 24bit, no sound could be heard in headphone on HDA platform.
It is caused by sample data layout. SOF supports S24_LE, and each sample format is like pattern of 0ddd, d stands for data. Samples are padded with 0‟s at the MSB. And link dma copys samples directly to hda bus.
But hda bus requires samples layout like pattern of ddd0. Samples are padded with 0‟s at the LSB to left justify the sample within the container.
So we need to add a format converter in FW to convert 0ddd to ddd0.
changed the title [-]sof audio pipeline doesn't support format of 24bit on HDA platform[/-][+]sof audio pipeline doesn't work with format of 24bit on HDA platform[/+]on Dec 11, 2018
changed the title [-]sof audio pipeline doesn't work with format of 24bit on HDA platform[/-][+]sof audio pipeline with the format of 24bit doesn't work on HDA platform[/+]on Dec 11, 2018
But hda bus requires samples layout like pattern of ddd0. Samples are padded with 0‟s at the LSB to left justify the sample within the container.
I think it's not like that. HDA bus requires nothing, you can just pass 24b with any padding so it doesn't matter for pass-through, but it will fail in processing components, because it expects MSB pad.
8bit shifter on HDA dma ends sounds like a solution, but I don't know yet if it's the best solution. I'd need to look at it.
@RanderWang We came to similar conclusions running 24/32 loopback test on WHL and ICL with ALC700 codec (using topology without volume components). When we were playing data with HDA pattern ddd0, recorded data had the same pattern ddd0. But when SOF patterned data was played 0ddd, we recorded data with patrern 0dd0. So its obvious that patterns doesn't match and some sort of converter should be implemented.
This can be made transparent to user by adding the volume automatically to any pipe that uses this DAI endpoint. You will need to create an M4 file for HDA (called intel-hda.m4) like we already have for SSP. This will define some macros for creating HDA Intel DAI's that will automatically add the volume control.
@RanderWang Please setup volume via topology to make S24_LE to S32_LE conversion. With that format the 24 bits signal is in the high part of the word. I assume the state of bits[7:0] does not matter for your application.
Or do you really mean we need big endian byte order swapping (packing of word bits to ram with bits[31:24] to lowest byte address, etc. like some RISC processors do)?
Activity
[-]sof audio pipeline doesn't support format of 24bit on HDA platform[/-][+]sof audio pipeline doesn't work with format of 24bit on HDA platform[/+][-]sof audio pipeline doesn't work with format of 24bit on HDA platform[/-][+]sof audio pipeline with the format of 24bit doesn't work on HDA platform[/+]jajanusz commentedon Dec 11, 2018
I think it's not like that. HDA bus requires nothing, you can just pass 24b with any padding so it doesn't matter for pass-through, but it will fail in processing components, because it expects MSB pad.
8bit shifter on HDA dma ends sounds like a solution, but I don't know yet if it's the best solution. I'd need to look at it.
zrombel commentedon Dec 11, 2018
@RanderWang We came to similar conclusions running 24/32 loopback test on WHL and ICL with ALC700 codec (using topology without volume components). When we were playing data with HDA pattern ddd0, recorded data had the same pattern ddd0. But when SOF patterned data was played 0ddd, we recorded data with patrern 0dd0. So its obvious that patterns doesn't match and some sort of converter should be implemented.
lgirdwood commentedon Dec 19, 2018
@zrombel volume control can convert formats if needed and @singalsu is the person to ask about it.
singalsu commentedon Dec 19, 2018
@zrombel It sounds like volume should in that case convert to S32_LE. Does it matter if the LSB side bits(7:0) in PCM samples are not zeros?
E.g. the DMIC 24 bit data format is similarly MSB aligned and it is treated in the pipelines as S32_LE.
RanderWang commentedon Dec 20, 2018
@lgirdwood If volume is used, does user need to add a bespoke volume in topology?
lgirdwood commentedon Dec 20, 2018
@RanderWang if you need volume then it must be added to pipeline via topology.
RanderWang commentedon Dec 21, 2018
@lgirdwood I discussed with @keyonjie , for this case, it is a limitation of hda dma, and it should be transparent to user. How do you think about it?
lgirdwood commentedon Dec 21, 2018
This can be made transparent to user by adding the volume automatically to any pipe that uses this DAI endpoint. You will need to create an M4 file for HDA (called intel-hda.m4) like we already have for SSP. This will define some macros for creating HDA Intel DAI's that will automatically add the volume control.
RanderWang commentedon Dec 24, 2018
Hi @singalsu , we need a volume function to support s24le to s24be. Does this exist?
singalsu commentedon Jan 2, 2019
@RanderWang Please setup volume via topology to make S24_LE to S32_LE conversion. With that format the 24 bits signal is in the high part of the word. I assume the state of bits[7:0] does not matter for your application.
Or do you really mean we need big endian byte order swapping (packing of word bits to ram with bits[31:24] to lowest byte address, etc. like some RISC processors do)?
RanderWang commentedon Jan 3, 2019
@singalsu , yes, I get your idea, S24_LE to S32_LE. I agree with you and I will check the topology later