[alsa-devel] Strange control interactions on Tegra Harmony
Mark,
I performed some testing on the patch to enable Harmony's internal speaker that I recently posted, and found a few strange interactions between the mixer controls.
The relevant controls that appear are in alsamixer are:
Headphone (mute + volume) [default: unmuted, high volume]
Speaker (mute + volume) [default: unmuted, high volume]
Left/Right Speaker Mixer DACL/DACR/Left Bypass/Right Bypass (switch, default muted/off)
Now, if I start playing something, and go enable Right Speaker Mixer DACR, I hear the sound on the speaker. Muting this control turns off the speaker. However, unmuting again doesn't turn the speaker back on.
This exact same behavior is seen for Right Speaker Mixer DACL/Left Bypass. For Left Bypass at least, that's odd, since the ADC path shouldn't be active to Capture anything and bypass it back, and there's no mic attached.
The Right Speaker Right Bypass control works the first and all subsequent times. Perhaps that's something to do with it being the last entry in wm8903.c's right_speaker_mixer[] array?
Finally, the muting either the Headphone and Speaker controls actually affects both the headphone and speaker outputs in all cases, rather than just the output the control is named for.
I briefly started to debug this, and notice that the SND_SOC_DAPM_SPK event function isn't being called at all in the cases where muting doesn't toggle as expected.
I didn't manage to trace the code through the entire ASoc code-base yet, but initial indications were that some register writes for the speaker mixer routing setup weren't sticking - i.e. I'd toggle a control to unmuted, exit alsamixer, restart alsamixer, and the control wouldn't be in the state I'd placed it.
Can you comment on this? I can certainly continue to debug it, but I figured it might be immediately obvious to you what the problem was e.g. if the same thing had happened on other platforms/codecs.
Thanks.
On Thu, Jan 27, 2011 at 10:20:22AM -0800, Stephen Warren wrote:
The Right Speaker Right Bypass control works the first and all subsequent times. Perhaps that's something to do with it being the last entry in wm8903.c's right_speaker_mixer[] array?
Possibly, though given the way DAPM processes those arrays I'd be a bit surprised if it made a difference. More likely to be that the bypass paths is one of the simpler and more direct paths in the CODEC.
I briefly started to debug this, and notice that the SND_SOC_DAPM_SPK event function isn't being called at all in the cases where muting doesn't toggle as expected.
I noticed something similar while developing a new driver the other day but didn't get a chance to chase it down yet. It's likely something got confused, possibly with the recent changes to propagate DAPM state between contexts, but that's just a guess as it's the most invasive thing that happened there recently.
Can you comment on this? I can certainly continue to debug it, but I figured it might be immediately obvious to you what the problem was e.g. if the same thing had happened on other platforms/codecs.
I'm on holiday tomorrow so can't have a proper look at live systems - if you've not got anywhere by Monday I should be able to sort it then.
Mark Brown wrote at Thursday, January 27, 2011 11:49 AM:
On Thu, Jan 27, 2011 at 10:20:22AM -0800, Stephen Warren wrote:
The Right Speaker Right Bypass control works the first and all subsequent times. Perhaps that's something to do with it being the last entry in wm8903.c's right_speaker_mixer[] array?
Possibly, though given the way DAPM processes those arrays I'd be a bit surprised if it made a difference. More likely to be that the bypass paths is one of the simpler and more direct paths in the CODEC.
I found the issue, and sent patch "ASoC: Use card as parameter to exported PM functions". I was nearly there the last time I looked at this a couple days back.
The issue with both the headphone and speaker mute controls muting both outputs is something else though.
Stephen Warren wrote at Thursday, January 27, 2011 3:00 PM:
I found the issue, and sent patch "ASoC: Use card as parameter to exported PM functions". I was nearly there the last time I looked at this a couple days back.
The issue with both the headphone and speaker mute controls muting both outputs is something else though.
Hmm. This issue happens when I run:
aplay foo.wav
But not when I run:
aplay -D hw:0,0 foo.wav
I deleted /etc/asound.conf (which set the default sink to pulse), and the problem went away. I guess I won't bother investigating this anymore right now.
On Thu, Jan 27, 2011 at 02:55:07PM -0800, Stephen Warren wrote:
Stephen Warren wrote at Thursday, January 27, 2011 3:00 PM:
The issue with both the headphone and speaker mute controls muting both outputs is something else though.
Hmm. This issue happens when I run:
aplay foo.wav
But not when I run:
aplay -D hw:0,0 foo.wav
I deleted /etc/asound.conf (which set the default sink to pulse), and the problem went away. I guess I won't bother investigating this anymore right now.
This sounds like the driver's happy and something in userspace is trying to be too clever about things.
participants (2)
-
Mark Brown
-
Stephen Warren