[alsa-devel] snd_soc_jack_add_gpios vs. SOC_DAPM_PIN_SWITCH
I've set up headphone hack detection in my machine driver, using snd_soc_jack_new, snd_soc_jack_add_pins, and snd_soc_jack_add_gpios.
I've also created a control to allow the user to enable/disable the headphone jack:
static const struct snd_kcontrol_new harmony_controls[] = { SOC_DAPM_PIN_SWITCH("Headphone Jack"), };
On their own, both of these work fine.
However, if I use the control to disable the headphones, then unplug/replug the headphones, the jack detect seems to override the control, and I hear audio from the headphones.
Is this something that's known not yet implemented or was never intended to be used this way, or should I look further to find the issue?
FYI, sound/soc/samsung/smartq_wm8987.c has this same code structure, and I imagine will have the same issue.
Thanks.
On Mon, Jan 31, 2011 at 04:03:58PM -0800, Stephen Warren wrote:
However, if I use the control to disable the headphones, then unplug/replug the headphones, the jack detect seems to override the control, and I hear audio from the headphones.
Is this something that's known not yet implemented or was never intended to be used this way, or should I look further to find the issue?
Using these two together makes no sense. Either you manually control the state of the output or you manage it automatically.
Generally a PIN_SWITCH() should only be used to offer control if none is availabile within the CODEC - in the case of Harmony it wouldn't make much sense as there's plenty of control in the CODEC for what gets routed to the various outputs.
FYI, sound/soc/samsung/smartq_wm8987.c has this same code structure, and I imagine will have the same issue.
Probably.
Mark Brown wrote at Tuesday, February 01, 2011 4:34 AM:
On Mon, Jan 31, 2011 at 04:03:58PM -0800, Stephen Warren wrote:
However, if I use the control to disable the headphones, then unplug/replug the headphones, the jack detect seems to override the control, and I hear audio from the headphones.
Using these two together makes no sense. Either you manually control the state of the output or you manage it automatically.
I was thinking that the jack detect would be used to enable/disable widgets for power purposes, but with a manual override to allow SW to set up use cases where only the internal speakers were used, and never headphones.
That said, if that isn't something that's ever typically done, I'm fine not supporting that.
Generally a PIN_SWITCH() should only be used to offer control if none is availabile within the CODEC - in the case of Harmony it wouldn't make much sense as there's plenty of control in the CODEC for what gets routed to the various outputs.
IIRC, the codec controls allow selecting only what gets routed, but there wasn't an overall "enable/disable speakers" switch (the mute switch does not disable the DAPM widgets). One would have to disable all the routing options to disable the speaker amplifiers, which would entail remembering what those routing options were to restore them once the speakers were desired again. A manual switch avoids this.
On Tue, Feb 01, 2011 at 10:59:00AM -0800, Stephen Warren wrote:
Mark Brown wrote at Tuesday, February 01, 2011 4:34 AM:
Using these two together makes no sense. Either you manually control the state of the output or you manage it automatically.
I was thinking that the jack detect would be used to enable/disable widgets for power purposes, but with a manual override to allow SW to set up use cases where only the internal speakers were used, and never headphones.
That said, if that isn't something that's ever typically done, I'm fine not supporting that.
It's really uncommon - generally if headphones are inserted you want to play audio on them even if also using the speakers as when people have headphones in they may not be able to hear the speakers. Headphones are often pretty good earplugs too.
Generally a PIN_SWITCH() should only be used to offer control if none is availabile within the CODEC - in the case of Harmony it wouldn't make much sense as there's plenty of control in the CODEC for what gets routed to the various outputs.
IIRC, the codec controls allow selecting only what gets routed, but there wasn't an overall "enable/disable speakers" switch (the mute switch does not disable the DAPM widgets). One would have to disable all the routing options to disable the speaker amplifiers, which would entail remembering what those routing options were to restore them once the speakers were desired again. A manual switch avoids this.
It may make sense to have a pin switch for the speakers, it's much more of a userspace question if you want the speakers on when the headphones are inserted so they probably shouldn't be connected to the jack at all (as we discussed previously). Bear in mind that in the *very* common case where the outputs are connected to DACs only everything will get powered off when there's no audio playing anyway.
Having looked at the WM8903 again this probably does make most sense for the speakers.
participants (2)
-
Mark Brown -
Stephen Warren