Repository navigation
Closed
Labels
ADLApplies to Alder Lake platformApplies to Alder Lake platformMTLApplies to Meteor Lake platformApplies to Meteor Lake platformP1Blocker bugs or important featuresBlocker bugs or important featuresSDWSoundWireSoundWireTGLApplies to Tiger LakeApplies to Tiger LakebugSomething isn't working as expectedSomething isn't working as expected
Milestone
Description
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%
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
- Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
- Kernel: {tip sof-dev}
- SOF: {tip main}
- Name of the topology file
- Topology: {sof-mtl-rt711-4ch.tplg}
- Name of the platform(s) on which the bug is observed.
- Platform: {MTL-RVP-SDW}
Metadata
Metadata
Assignees
Labels
ADLApplies to Alder Lake platformApplies to Alder Lake platformMTLApplies to Meteor Lake platformApplies to Meteor Lake platformP1Blocker bugs or important featuresBlocker bugs or important featuresSDWSoundWireSoundWireTGLApplies to Tiger LakeApplies to Tiger LakebugSomething isn't working as expectedSomething isn't working as expected

Activity
mszleszy commentedon Mar 10, 2023
@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
bardliao commentedon Mar 13, 2023
@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.
Do you know the proper way to do the conversion?
mszleszy commentedon Mar 13, 2023
bardliao commentedon Mar 13, 2023
Thanks @mszleszy
@keqiaozhang Could you test below change?
keqiaozhang commentedon Mar 16, 2023
@bardliao ,confirmed that above change can fix the issue on ADL. Please help to submit a PR.
[-][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[/+]bardliao commentedon Mar 16, 2023
The test result on TGL is still not good.

I will provide the IPC payload logs later.
BTW, I saw EQIIR is added in the topology. Can it cause the issue? @singalsu
singalsu commentedon Mar 16, 2023
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.
keqiaozhang commentedon Mar 16, 2023
It's TGL-IPC4 platform and the tplg name is cavs-sdw.tplg
singalsu commentedon Mar 16, 2023
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 withsof-ctl -n <number>.The 0 dB 40 Hz high-pass coefficients should be as next file
bardliao commentedon Mar 17, 2023
@mszleszy I can confirm the IPC payload is as we expected now.
dmesg_s16_capture.txt