At Fri, 30 Nov 2012 01:11:51 +0100, David Henningsson wrote:
On 11/29/2012 04:21 PM, Takashi Iwai wrote:
Instead of limiting the automatic input-source selection only to the mics (internal, external and dock mics), allow it for generic inputs, e.g. switching between the rear line-in and the front mic.
It's been a frequent demand from desktop machines, and we already do it for the headphone auto-mute, so no reason to avoid it now.
The logic is to check the attribute and location of input pins, and enable the automatic selection feature only if all such pins are in different locations (e.g. internal, front, rear, etc) and line-in or mic pins. That is, if multiple input pins are assigned to a single location, the feature isn't enabled because we don't know the priority.
Hmm, I'm a bit worried about this, partially because it makes things inconsistent between codecs (and kernel versions, too).
The behavior change is an open question, yes. If we'd like to be conservative, auto_mic can be set to 0 except for non-laptop cases.
In current PulseAudio, we disable the internal mic if any other mic is being detected as plugged in. But if there are other switches, say "front mic" and "rear mic", we don't do such disabling. Now you're disabling one of them automatically in the kernel, but for one codec only.
Porting this to other codecs shouldn't be too hard.
So my point is, when both "Front mic" and "Rear mic" are plugged in, we don't know whether to present to the user to choose between "Front Mic" and "Rear Mic", or to disable one of them.
The input is exclusive, so one of them is chosen. It's the front one. This is the same logic as we have for the headphone. Practically seen, the headphone auto-mute over line-out is working just because headphone jacks are implemented in only two ways: a headphone jack on a laptop or a headphone jack on a front panel. Thus, we do "choose the front" implicitly by the auto-mute feature.
And, the implementation for the generic auto-mic follows this logic. Prefer front to rear.
One could possibly argue that the absence of a "Input Source" and "Capture Source" would indicate some form of auto-switch, but I wonder if this would really be a safe indicator...
Heh, actually I expected this kind of response. A few more patches I'm going to post will add "Capture Source" back even for auto-mic mode, in addition to a new "Auto-Mic Mode" enum switch. In that way, you'll have almost full controls.
thanks,
Takashi