[pulseaudio-discuss] Internal Mics and Speakers not visible in PulseAudio

[Takashi Iwai]

At Wed, 30 May 2012 14:46:48 +0200,
David Henningsson wrote:
> 
> Posted to both alsa-devel and pulseaudio-discuss lists, as this is a 
> cross issue.
> 
> PulseAudio tries to figure out what equipment is present on the machine 
> using the mixer. If it finds e g "Headphone Playback Volume", "Headphone 
> Playback Switch", or "Headphone Jack", it assumes that a headphone is 
> present and creates a headphone port. If it finds no ports, it creates a 
> fallback "Analog Output" port.
> 
> Now assume that we have a laptop with speakers and a headphone jack, but 
> with only a "Master Playback Volume", and a "Headphone Jack" for the 
> jack detection.
> PulseAudio will take the "Headphone Jack", and create a headphone port. 
> Now, if this port is currently unconnected/unavailable, it will not show 
> up at all [1]. As a result, the internal speakers - for which no port 
> was created - will be essentially unusable.
> 
> Now, I thought this was a problem with a pair of machines only, that we 
> could easily quirk on the PulseAudio side. But after looking through 
> Ubuntu bugs and posting a blog post [2] about the issue, I have now 
> collected 21 different machines affected, mostly on the input side. 
> Several Realtek chips are affected on the dmic side, and some older 
> STAC92xx chips have problems in both directions.
> So it becomes evident to me, that this is something that needs to be 
> fixed pretty fast.
> 
> So, to move forward, we need to expose these speakers and internal mics 
> to userspace. A very simple (untested) patch is attached. This would 
> make "Internal Mic Jack" and "Speaker Jack" show up. Note that the 
> actual status can be overridden/ignored on the PulseAudio side - the 
> importance here is the sign that there are internal mics and speakers, 
> so that the PulseAudio ports get created.
>
> I could develop it a little to make sure we don't actually do any jack 
> detection for these pins but always return them as being true/present.
> That is, if you approve the idea? I admit that the "Internal Mic Jack" 
> is somewhat misleading/hacky as the internal mic is not connected to any 
> physical jack, but it seems like the simplest way of resolving the 
> problem currently.

I've thought of a similar change, but I postponed it because of some
concerns:
- the control actually is no-op as it's a fixed pin;
  IOW, should we really perform the jack-detection verb on such a pin?
- as you mentioned, should it be really named as "Jack"?

The second point is just a matter of formality.  We can regard "Jack"
as the suffix to indicate the pin information.  But the behavior jack
ctl of such fixed pins should be defined exactly.


Takashi

> 
> 
> -- 
> David Henningsson, Canonical Ltd.
> https://launchpad.net/~diwic
> 
> [1] At least in Ubuntu's new Sound Settings UI.
> 
> [2] 
> http://voices.canonical.com/david.henningsson/2012/05/22/three-audio-bugs-in-12-04/
> [2 expose-intmic.patch <text/x-patch (7bit)>]
> diff --git a/sound/pci/hda/hda_jack.c b/sound/pci/hda/hda_jack.c
> index 2dd1c11..61becde 100644
> --- a/sound/pci/hda/hda_jack.c
> +++ b/sound/pci/hda/hda_jack.c
> @@ -312,7 +312,7 @@ static int add_jack_kctl(struct hda_codec *codec, hda_nid_t nid,
>  		return 0;
>  	def_conf = snd_hda_codec_get_pincfg(codec, nid);
>  	conn = get_defcfg_connect(def_conf);
> -	if (conn != AC_JACK_PORT_COMPLEX)
> +	if (conn == AC_JACK_PORT_NONE)
>  		return 0;
>  
>  	snd_hda_get_pin_label(codec, nid, cfg, name, sizeof(name), &idx);