Repository navigation
[BUG][CML][HDA] fixed distortion pattern at the beginning of recording on headset pipeline #2101
Description
Describe the bug
run arecord on headset capture pipeline, you will see volume keeps high at the beginning, even there is no sound. check the recorded wave, you can see a fixed distortion pattern, and all headset recorded waves have the same distortion.
if no headset connected when run arecord, no distortion found.
To Reproduce
run arecord -Dhw:0,0 -fs32_le -r 48000 -c 2 -i -vvv headset.wav
Reproduction Rate
10/10
Environment
- Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
- Name of the topology file
- Topology: {sof-hda-generic-2ch.tplg}
- Name of the platform(s) on which the bug is observed.
- Platform: {Dell HDA platform with ALC 3204 codec}
Activity
lgirdwood commentedon Nov 18, 2019
@singalsu @bardliao what do you think, this could just be the mic powering UP.
plbossart commentedon Nov 18, 2019
likely something in the HDaudio codec driver and/or bad settings applied?
bardliao commentedon Nov 19, 2019
Looks like a power up pop. @aiChaoSONG How long will the max volume continue? Will you see the same issue on DMIC recording?
aiChaoSONG commentedon Nov 19, 2019
@bardliao only see this on headset capture pipeline, and the max volume duration is very short, about 0.35s.
bardliao commentedon Nov 19, 2019
So I think it is a codec issue (or limitation). I think we can close this issue since there is nothing we can do.
singalsu commentedon Nov 19, 2019
This would be fixed by inserting a high-pass IIR EQ into capture path. If someone with access to this device and test an enhanced topology can contact me I can make a patch to sof-hda-generic-2ch.tplg to test with.
singalsu commentedon Nov 19, 2019
@bardliao @aiChaoSONG Can you please check if SOF PR #2109 helps for this.
lgirdwood commentedon Nov 20, 2019
@singalsu good work, btw this is worthy of a technical note on sof-decs i.e. a small howto.
singalsu commentedon Nov 20, 2019
I was able to repeat this issue with a device that I have. There's no volume ramp happening in capture, I'll try to make a fix for this and related problems thesofproject/linux#1463 and thesofproject/linux#1480.
The length of DC pulse is in my device even longer, almost 5 seconds. I think this needs both the volume ramp fix and the DC block filter.
plbossart commentedon Nov 20, 2019
thanks @singalsu for looking into this.
singalsu commentedon Nov 20, 2019
I have a fix under development that is done in firmware to launch a volume ramp in beginning of copy() operations if the driver control sequence has not initiated it. I don't think it can be fixed in driver in simple way because the PM controls cache hides the unmute transition from firmware.
Combination of ramp and DC block works well but I need to eliminate the volume setting dependent ramp length variation for the start ramp (use the whole topology defined time even if the gain request is much lower than max. volume).
lgirdwood commentedon Nov 21, 2019
@singalsu can we have topology tuple flags for ramp up/down at stream start, this way we can turn it off/on as needed.
singalsu commentedon Nov 22, 2019
We have a single token for ramp length but the same length is used for both start and during streaming. The ramp is turned off by setting length to zero.
singalsu commentedon Jan 24, 2020
@aiChaoSONG The PR #2109 is merged so I re-tested this on a WHL HDA platform with headset disconnected. The start waveform is now clean so I think this can be closed.
singalsu commentedon Jan 24, 2020
Closing this issue.