Skip to content

sof audio pipeline with the format of 24bit doesn't work on HDA platform #700

Closed

Description

@RanderWang

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.

Activity

  1. 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
  2. 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
  3. jajanusz commented on Dec 11, 2018

    @jajanusz
    Contributor

    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.

  4. added
    bugSomething isn't working as expected
    on Dec 11, 2018
  5. zrombel commented on Dec 11, 2018

    @zrombel

    @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.

  6. lgirdwood commented on Dec 19, 2018

    @lgirdwood
    Member

    @zrombel volume control can convert formats if needed and @singalsu is the person to ask about it.

  7. singalsu commented on Dec 19, 2018

    @singalsu
    Collaborator

    @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.

  8. RanderWang commented on Dec 20, 2018

    @RanderWang
    CollaboratorAuthor

    @lgirdwood If volume is used, does user need to add a bespoke volume in topology?

  9. lgirdwood commented on Dec 20, 2018

    @lgirdwood
    Member

    @RanderWang if you need volume then it must be added to pipeline via topology.

  10. RanderWang commented on Dec 21, 2018

    @RanderWang
    CollaboratorAuthor

    @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?

  11. lgirdwood commented on Dec 21, 2018

    @lgirdwood
    Member

    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.

  12. RanderWang commented on Dec 24, 2018

    @RanderWang
    CollaboratorAuthor

    Hi @singalsu , we need a volume function to support s24le to s24be. Does this exist?

  13. singalsu commented on Jan 2, 2019

    @singalsu
    Collaborator

    @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)?

  14. RanderWang commented on Jan 3, 2019

    @RanderWang
    CollaboratorAuthor

    @singalsu , yes, I get your idea, S24_LE to S32_LE. I agree with you and I will check the topology later

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

P2Critical bugs or normal featuresWHLApplies to WhiskeyLake platformbugSomething isn't working as expected

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions