Repository navigation
[BUG][ADL]: maxim 98373 speaker pop sound when switching audio output device #6379
Description
Describe the bug
98373 speaker pop sound occurred on upstream adl-004-drop-stable and main branch as well.
experiment:
- bypass all smart amp DSM, lib module and binary.
- moving FE SSP stop sequence before BE amp shutdown.
both still have pop sound.
To Reproduce
- plug in headset
- playing music on Youtube.com.
- switching audio devices by CRAS UI
- speaker pop suddenly when switching audio routing path back to speaker.
Reproduction Rate
100%
Expected behavior
no pop sound.
Environment
-
Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
- Kernel: 5.10
- SOF: upstream adl-004-drop-stable, main branch
-
Name of the topology file
- Topology: sof-adl-max98373-nau8825.tplg
-
Name of the platform(s) on which the bug is observed.
- Platform: ADL
Screenshots or console output
attachment. kernel logs. sof-logger trace logs.
- 300Hz pop noise capture
- trace logs
- dmesg
- pop noise.wav
Activity
macchian commentedon Oct 7, 2022
dmesg_pop.txt
sof_trace_trace.log
macchian commentedon Oct 7, 2022
Noise_without_DSM.zip
macchian commentedon Oct 7, 2022
RanderWang, need your advices.
macchian commentedon Oct 11, 2022
@lgirdwood, @mwasko, pop also be reproduced on main branch, any comments?
plbossart commentedon Oct 12, 2022
@macchian your dmesg log seems wrong, it contains major errors:
plbossart commentedon Oct 12, 2022
@macchian we need to experiment with simpler setups at the hw: device level, i.e. without CRAS in the picture
Suggestions:
a) play on headset, stop 10s, play on amp, and check if there is any pop.
b) play on the amp while playing on the headset
c) try to play on the headset, wait 500ms and play on the amp with a script to simulate a switch.
macchian commentedon Oct 13, 2022
my bad... wrong file. reattached the correct one.
dmesg_pop.txt
macchian commentedon Oct 13, 2022
@plbossart Thanks for your advices! As you mentioned, I write a script spk_switch_on_off.sh and gen a 1k_sine_48k_16bits_60s.wav
1k_sine_48k_16bits_60s.zip
spk_switch_on_off.zip
The script is playing 1k sine wav in background and every 500ms switching speaker(-D hw:0,0) to headphone (-D hw:0,1) repeatedly.
Summarize test result below:
a) play on headset, stop 10s, play on amp, and check if there is any pop.
b) play on the amp while playing on the headset
c) try to play on the headset, wait 500ms and play on the amp with a script to simulate a switch.
mengdonglin commentedon Oct 14, 2022
@macchian It's not likely to be SOF FW or driver issue, as the firmware and driver are not really involved in switching endpoints. It's more likely to be a codec or machine driver or UCM issue.
16 remaining items
bardliao commentedon Oct 27, 2022
BTW, If someone can probe the I2S pins physically with a logic analyzer to get the audio data from I2S pins directly, it would be
a better way to clarify where is the pop from.
bardliao commentedon Oct 27, 2022
I can hear pop noise when speaker playback starts AND stops. And I also hear obvious pop noise when headphone playback stops.
The test wav is 1K_0dB.zip
ujfalusi commentedon Oct 27, 2022
@bardliao, can you isolate the pop with dapm_pop_time of 2 seconds?
Does the codec have Mute switch on headset, speaker? Does toggling it produces pop noise as well?
bardliao commentedon Oct 28, 2022
@ujfalusi @lgirdwood @macchian I am pretty sure the pop is from the codec itself after doing some experiment.
There are two speaker codecs (left and right) in the device.
And a pop is generated when a speaker is started and stopped. That's why we can hear two pops when speaker playback starts and two pops when speaker playback stops.
If I set dapm_pop_time = 2sec, there are some "da" "da" sound in the transition stage.
Below is the dmesg tested with dapm_pop_time = 2000, I added some empty line when I hear pop.
There is no single mute switch for speaker, but we have "Spk Switch" that can enable/disable Speakers.
controls.txt
And I can hear the pop when I set
amixer -c0 cset name='Left Spk Switch' 0andamixer -c0 cset name='Left Spk Switch' 1during playback is running.However, there is no "da" "da" noise when I switch "Spk Switch" on or off.
Below is the dmesg when I switch 'Left Spk Switch'.
Intel Audio DSP doesn't know user is switching the "Spk Switch", so, the audio data is consistent.
It implies that the pop is generated when the codec is doing the enabling/disabling process.
Like
Queue Left Amp Enable: reg=0x202b, 0x1/0x1
Queue Left Amp Enable: reg=0x202b, 0x0/0x1
bardliao commentedon Oct 28, 2022
@macchian Do you know if they do anything to prevent the codec driver from accessing the codec registers?
For example, let regcache_cache_only be always true, or use the dummy codec driver instead of max98373 codec driver.
If they didn't do that, the codec driver will still act as usual, and it didn't prove the pop is not from the enabling/disabling process.
macchian commentedon Nov 2, 2022
Hi all,
As per working with @bardliao and @ryans-lee from Maxim, I summarize the pop test results below:
a. turn off left Spk global_en first
#echo 0 0x20FF > /sys/kernel/debug/regmap/i2c-MX98373:01 (One pop sound)
b. then turn off right Spk global_en
#echo 0 0x20ff > /sys/kernel/debug/regmap/i2c-MX98373:00 (One pop sound)
c. turn on right spk global_en again
#echo 1 0x20ff > /sys/kernel/debug/regmap/i2c-MX98373:00 (speaker sound not resume sound when set global_en on)
So in this case, I only observe pop when running right spk global_en off.
Pop occurs:
1 pop occurs when aplay starting, 2 pop occur when aplay stopped. [Confirmed]
static const struct snd_soc_dapm_widget max98373_dapm_widgets[] = {
SND_SOC_DAPM_DAC_E("Amp Enable", "HiFi Playback",
─ MAX98373_R202B_PCM_RX_EN, 0, 0, max98373_dac_event,
┼ SND_SOC_NOPM, 0, 0, max98373_dac_event,
SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_POST_PMD |
SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_PRE_PMD),
static int max98373_probe(struct snd_soc_component *component)
MAX98373_R2043_AMP_EN,
MAX98373_SPK_EN_MASK, 1);
─
┼ regmap_write(max98373->regmap, MAX98373_R202B_PCM_RX_EN, 0x1);
plbossart commentedon Dec 13, 2022
@bardliao can you provide a summary? My understanding is that the issue is at the codec driver level?
bardliao commentedon Dec 13, 2022
@plbossart There are 2 issues.
a. When we run aplay with a 1k tone and stop during playback, we will hear a noise due to the discontinuous audio.
b.
We measured the I2S signal from I2S pins with a logic analyzer and the captured signal looks good. So, I don't think it is a SOF issue.
macchian commentedon Feb 8, 2023
refer to #7048 and #4179
johnylin76 commentedon Feb 8, 2023
FYI, the production build for ADL-P devices have been migrated from adl-004 to rpl-001, which means the fix commit should be merged back to rpl-001-drop-stable instead.
lgirdwood commentedon Feb 21, 2023
@macchian can we close ?
macchian commentedon Feb 22, 2023
@lgirdwood Yes, the remaining fix PR #4179 has approved and to be merged. We can close it. Thanks!