[alsa-devel] Internal Mics and Speakers not visible in PulseAudio
tiwai at suse.de
Wed May 30 16:56:50 CEST 2012
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 . 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  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
- 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.
> David Henningsson, Canonical Ltd.
>  At least in Ubuntu's new Sound Settings UI.
> [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);
More information about the Alsa-devel