[alsa-devel] Internal Mics and Speakers not visible in PulseAudio

[David Henningsson]

On 05/30/2012 04:56 PM, Takashi Iwai wrote:
> 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?

I don't think we should perform the actual verb on these devices.

> - 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.

I would like us to be able to distinguish the "phantom" Jacks from the 
real ones. We can do this either by
  1) Adding a third state - this might require us to change the type 
from BOOLEAN to something else, I don't know how backwards compatible 
such a change could be, or
  2) Instead of calling them "Jack", we could have another suffix [1]. 
We could still have them as BOOLEAN and always return TRUE.

  3) This is probably a bit overkill, as PulseAudio can do without that 
functionality anyway, but one could consider the speaker presence 
turning to FALSE when headphones are plugged in and then back to TRUE 
when headphones are unplugged - but only if "Automute mode" is enabled.

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

[1] s/J/H ;-)