Strange control interactions on Tegra Harmony

Strange control interactions on Tegra Harmony

[Stephen Warren]

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.

-- 
nvpublic

Re: Strange control interactions on Tegra Harmony

[Mark Brown]

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.

Re: Strange control interactions on Tegra Harmony

[Stephen Warren]

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.

-- 
nvpublic

Re: Strange control interactions on Tegra Harmony

[Stephen Warren]

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.

-- 
nvpublic

Re: Strange control interactions on Tegra Harmony

[Mark Brown]

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.