Skip to content

[BUG] Headset capture does not work with S16_LE format on IPC4-SDW platforms #7240

Closed

Description

@keqiaozhang

Describe the bug
I was trying to enable alsabat test for headset capture on MTL platforms, I found that if I test capture with s16_le on MTL-SDW, the max peak always 99%-100%. The recorded wav is full of noise. But with same amixer settings, S32_LE works well. it can record the real data without noise. This issue should be a regression, but not sure how long it has existed.

Console output

arecord -Dhw:0,1 -f s16_le -r 48000  -c 2 test.wav -vvv -d 5
Recording WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
Hardware PCM card 0 'sof-soundwire' device 1 subdevice 0
Its setup is:
  stream       : CAPTURE
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 2
  rate         : 48000
  exact rate   : 48000 (48000/1)
  msbits       : 16
  buffer_size  : 16384
  period_size  : 4096
  period_time  : 85333
  tstamp_mode  : NONE
  tstamp_type  : MONOTONIC
  period_step  : 1
  avail_min    : 4096
  period_event : 0
  start_threshold  : 1
  stop_threshold   : 16384
  silence_threshold: 0
  silence_size : 0
  boundary     : 4611686018427387904
  appl_ptr     : 0
  hw_ptr       : 0
Max peak (8192 samples): 0x00007ff6 #################### 99%
Max peak (8192 samples): 0x00007ffc #################### 99%
Max peak (8192 samples): 0x00007ffe #################### 99%
Max peak (8192 samples): 0x00008000 #################### 100%
Max peak (8192 samples): 0x00007ffc #################### 99%
Max peak (8192 samples): 0x00007ffe #################### 99%
Max peak (8192 samples): 0x00007ffe #################### 99%
Max peak (8192 samples): 0x00007ff0 #################### 99%
Max peak (8192 samples): 0x00007ff2 #################### 99%
Max peak (8192 samples): 0x00008000 #################### 100%
Max peak (8192 samples): 0x00007ff8 #################### 99%
Max peak (8192 samples): 0x00007ff8 #################### 99%
Max peak (8192 samples): 0x00008000 #################### 100%
Max peak (8192 samples): 0x00008000 #################### 100%
....

To Reproduce
arecord -Dhw:0,1 -f s16_le -r 48000 -c 2 test.wav -vvv -d 5

Reproduction Rate
100%

image

Expected behavior
A clear and concise description of what you expected to happen.

Impact
What impact does this issue have on your progress (e.g., annoyance, showstopper)

Environment

  1. Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
    • Kernel: {tip sof-dev}
    • SOF: {tip main}
  2. Name of the topology file
    • Topology: {sof-mtl-rt711-4ch.tplg}
  3. Name of the platform(s) on which the bug is observed.
    • Platform: {MTL-RVP-SDW}

Activity

  1. added
    bugSomething isn't working as expected
    P1Blocker bugs or important features
    SDWSoundWire
    MTLApplies to Meteor Lake platform
    on Mar 10, 2023
  2. mszleszy commented on Mar 10, 2023

    @mszleszy

    @keqiaozhang during debugging of #6723
    I've noticed that sw is doing bit conversion improperly when using sdw topology - Binding 32/32bit sink with 16/32bit source
    that will cause glitches in captured data (confirmed in fw testing framework)

    Are you able to check if it's not the same case?
    I can help with that but I'll need ipc & payload logs

  3. bardliao commented on Mar 13, 2023

    @bardliao
    Collaborator

    @mszleszy It seems that we do 16/32 -> 16/16 conversion. Please see the log below and the full dmesg log is attached dmesg_sdw_s16_capture.txt.

    [  337.592506] snd_sof:sof_ipc4_widget_setup: sof-audio-pci-intel-mtl 0000:00:1f.3: Create widget copier.host.10.1 instance 1 - pipe 10 - core 0
    [  337.592527] snd_sof:sof_ipc4_log_header: sof-audio-pci-intel-mtl 0000:00:1f.3: ipc tx      : 0x40010004|0x10015: MOD_INIT_INSTANCE [data size: 84]
    [  337.592916] snd_sof:sof_ipc4_log_header: sof-audio-pci-intel-mtl 0000:00:1f.3: ipc tx reply: 0x60000000|0x10015: MOD_INIT_INSTANCE
    [  337.593122] snd_sof:sof_ipc4_log_header: sof-audio-pci-intel-mtl 0000:00:1f.3: ipc tx done : 0x40010004|0x10015: MOD_INIT_INSTANCE [data size: 84]
    [  337.593166] Message payload: 00000000: 0000066f 00000180 000000c0 00000001
    [  337.593184] Message payload: 00000010: 0000bb80 00000020 ffffff10 00000001
    [  337.593201] Message payload: 00000020: 00000000 00001002 0000bb80 00000010
    [  337.593215] Message payload: 00000030: ffffff10 00000001 00000000 00001002
    [  337.593229] Message payload: 00000040: 00000000 00000100 00000180 00000001
    [  337.593240] Message payload: 00000050: 00000000
    

    Do you know the proper way to do the conversion?

  4. mszleszy commented on Mar 13, 2023

    @mszleszy

    @mszleszy It seems that we do 16/32 -> 16/16 conversion. Please see the log below and the full dmesg log is attached dmesg_sdw_s16_capture.txt.

    [  337.592506] snd_sof:sof_ipc4_widget_setup: sof-audio-pci-intel-mtl 0000:00:1f.3: Create widget copier.host.10.1 instance 1 - pipe 10 - core 0
    [  337.592527] snd_sof:sof_ipc4_log_header: sof-audio-pci-intel-mtl 0000:00:1f.3: ipc tx      : 0x40010004|0x10015: MOD_INIT_INSTANCE [data size: 84]
    [  337.592916] snd_sof:sof_ipc4_log_header: sof-audio-pci-intel-mtl 0000:00:1f.3: ipc tx reply: 0x60000000|0x10015: MOD_INIT_INSTANCE
    [  337.593122] snd_sof:sof_ipc4_log_header: sof-audio-pci-intel-mtl 0000:00:1f.3: ipc tx done : 0x40010004|0x10015: MOD_INIT_INSTANCE [data size: 84]
    [  337.593166] Message payload: 00000000: 0000066f 00000180 000000c0 00000001
    [  337.593184] Message payload: 00000010: 0000bb80 00000020 ffffff10 00000001
    [  337.593201] Message payload: 00000020: 00000000 00001002 0000bb80 00000010
    [  337.593215] Message payload: 00000030: ffffff10 00000001 00000000 00001002
    [  337.593229] Message payload: 00000040: 00000000 00000100 00000180 00000001
    [  337.593240] Message payload: 00000050: 00000000
    

    Do you know the proper way to do the conversion?
    @bardliao
    Modules before are working on 32/32 and capture copier module is expecting16/32 on input. There is no module doing 32/32 to 16/32 conversion before.
    I think this module should do conversion from 32/32 -> 16/16 conversion
    payload would look something like that:

     00000000: 0000066f 00000180 000000c0 00000001
    00000010: 0000bb80 00000020 ffffff10 00000001
    00000020: 00000000 **00002002** 0000bb80 00000010
    00000030: ffffff10 00000001 00000000 00001002
    00000040: 00000000 00000100 00000180 00000001
    00000050: 00000000
    
  5. bardliao commented on Mar 13, 2023

    @bardliao
    Collaborator

    Thanks @mszleszy
    @keqiaozhang Could you test below change?

    diff --git a/tools/topology/topology2/cavs-sdw.conf b/tools/topology/topology2/cavs-sdw.conf
    index aa76bb35e5ab..ab768bb11a71 100644
    --- a/tools/topology/topology2/cavs-sdw.conf
    +++ b/tools/topology/topology2/cavs-sdw.conf
    @@ -184,6 +184,7 @@ Object.Pipeline {
                                    # 32 -> 16 bits conversion is done here,
                                    # so in_bit_depth is 32 (and out_bit_depth is 16).
                                    in_bit_depth    32
    +                               in_valid_bit_depth      32
                            }
                    }
            ]
  6. added
    TGLApplies to Tiger Lake
    ADLApplies to Alder Lake platform
    on Mar 16, 2023
  7. keqiaozhang commented on Mar 16, 2023

    @keqiaozhang
    CollaboratorAuthor

    Could you test below change?

    @bardliao ,confirmed that above change can fix the issue on ADL. Please help to submit a PR.

  8. changed the title [-][BUG] Headset capture does not work with S16_LE format on MTL-SDW[/-] [+][BUG] Headset capture does not work with S16_LE format on IPC4-SDW platforms[/+] on Mar 16, 2023
  9. added this to the v2.5 milestone on Mar 16, 2023
  10. bardliao commented on Mar 16, 2023

    @bardliao
    Collaborator

    The test result on TGL is still not good.
    MicrosoftTeams-image (22)

    I will provide the IPC payload logs later.

    BTW, I saw EQIIR is added in the topology. Can it cause the issue? @singalsu

  11. singalsu commented on Mar 16, 2023

    @singalsu
    Collaborator

    The test result on TGL is still not good.

    It looks like clipping and high-pass. What topology name is this? The EQ should not be amplifying type unless it's south-complex direct attach DMIC.

    Is this IPC3 or IPC4. I recall there was a gain reset patch for 100% volume, and in some cases in IPC3 100% volume is +20 or +40 dB.

  12. keqiaozhang commented on Mar 16, 2023

    @keqiaozhang
    CollaboratorAuthor

    Is this IPC3 or IPC4

    It's TGL-IPC4 platform and the tplg name is cavs-sdw.tplg

  13. singalsu commented on Mar 16, 2023

    @singalsu
    Collaborator

    Is this IPC3 or IPC4

    It's TGL-IPC4 platform and the tplg name is cavs-sdw.tplg

    Since it's tplg2 it's harder to check what actually is in the topology (no .conf produced from m4). Can you ssh to such device and find out numid of IIR (amixer controls | grep -i iir) in the path that clipped as seen above, and then get the filter coefficients with sof-ctl -n <number>.

    The 0 dB 40 Hz high-pass coefficients should be as next file

    $ cat eq_iir_highpass_40hz_0db_48khz.txt
    877023059,0,88,50438144,0,0,0,0,88,2,1,0,0,0,0,0,0,1,1,0,0,0,0,3229146956,2139532835,536156946,3222653403,536156946,0,32690,
    
    
  14. bardliao commented on Mar 17, 2023

    @bardliao
    Collaborator

    @mszleszy I can confirm the IPC payload is as we expected now.

    [   79.803257] Message payload: 00000000: 0000066f 00000180 000000c0 00000001
    [   79.803281] Message payload: 00000010: 0000bb80 00000020 ffffff10 00000001
    [   79.803304] Message payload: 00000020: 00000000 00002002 0000bb80 00000010
    [   79.803325] Message payload: 00000030: ffffff10 00000001 00000000 00001002
    [   79.803346] Message payload: 00000040: 00000000 00000100 00000180 00000001
    [   79.803489] Message payload: 00000050: 00000000
    

    dmesg_s16_capture.txt

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    ADLApplies to Alder Lake platformMTLApplies to Meteor Lake platformP1Blocker bugs or important featuresSDWSoundWireTGLApplies to Tiger LakebugSomething isn't working as expected

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions