[alsa-devel] [PATCH 4/5] ALSA: hda - Implement shared front mic/hp jack for HP Z220

[Takashi Iwai]

At Fri, 30 Nov 2012 09:46:29 +0100,
David Henningsson wrote:
> 
> On 11/30/2012 08:57 AM, Takashi Iwai wrote:
> > At Fri, 30 Nov 2012 01:33:27 +0100,
> > David Henningsson wrote:
> >>
> >> On 11/29/2012 04:21 PM, Takashi Iwai wrote:
> >>> HP Z220 with ALC221 codec has a front jack that should work as both
> >>> the front mic and the secondary headphone.  This patch adds a new
> >>> mixer enum to change the jack behavior.
> >>
> >> Hmm, in principle I don't like this hack.
> >
> > I don't like either, but there was some demand for such feature...
> 
> Heh, that was not too surprising :-)
> 
> >> In many machines, both front
> >> jacks could probably work as anything (line in, line out, headphones,
> >> mic, etc), and that goes for many pins on many machines, and we would
> >> end up with a ton of ALSA kcontrols and an incredibly complex parsing
> >> machine.
> >
> > Actually we can (or should) add "xxx Jack Mode" enum to every jack in
> > future.  See below.
> >
> >> I would recommend a user to use hda-jack-retask in these cases, instead
> >> of cluttering the kernel code.
> >
> > Well, hda-jack-retask is a nice debugging tool, but it's not intended
> > for the actual user interface for daily use.
> 
> Maybe we should consider making the reconfiguration more lightweight in 
> the kernel then, so that hda-jack-retask (or a more simplistic GUI) can 
> be used for daily use?

I don't think any tool accessing hwdep to fiddle with the codec verb
isn't suitable for normal usage.  For any normal usage, the only
access is via control API.

> > Also, a big missing
> > piece is the automatic retasking via jack detection as a headphone.
> 
> Through impedance sensing? Does the ALC221 support that?

No.  Otherwise it'd be easier :)

> >> If you insist though, a slightly more consistent mechanism would be to
> >> use the same approach as we did with the single 3-pin jacks (on some
> >> Asus machines, IIRC), where selecting the Capture/Input Source would
> >> retask the pin, instead of adding a separate "Jack Mode" switch.
> >
> > I thought of that, too.  OTOH, "xx Jack Mode" enum is already present
> > for IDT codecs over years.  This isn't used for configuring the I/O
> > direction of jacks but choosing bias levels.  Why not applying the
> > same logic for I/O direction switch?
> 
> This might work for this particular case, but sounds like it could 
> become a confusing set of alsa-mixer controls (and hairy kernel code to 
> control them all!) - e g, what if two jacks that currently are not 
> headphones both want to be headphones, and they have independent volume 
> controls? Which one will be controlled by "Headphone Volume"?
> 
> As an example of current code that I have trouble understanding and 
> fixing bugs in, is the badness calculation feature. This sounds like it 
> could be even worse.

I think the only confusions will be the conflict between the multi-io
channel mode and individual retasking, and the conflict between the
capture source and individual retasking.

The basic topology is determined statically at the probe time based on
the initial configuration.  If a jack is already listed in multi-io
mode, the output can be toggled by the channel mode, so we either
don't add the output to the jack mode enum or do change the enum value
forcibly when the channel mode is changed.

If a jack isn't in multi-io but is still capable to be an output, we
need to check which DAC it can connect without disturbing the existing
routing.  Only if it can be connected to either a line-out DAC a
headphone DAC, we can add a hook -- i.e. an additional enum item of
this jack mode.

When a mic jack is retasked as headphone and it's the current capture
source, what should we do?  In my previous implementation, it was
easy, because it's just one of two, so forced to switch to another.
But in a general implementation, there can be more.

OTOH, setting the mic as the capture source itself doesn't "break".
You'll get no input, but it's what user chooses now.  So, maybe the
intelligent selection of other source could be better done in the same
place where the jack-detection-and-do-select is done (e.g. PA).

A remaining problem in the scenario above is possible conflicts of the
new DAC hooks.  The routes to a DAC might be exclusive with each other
from both front and rear mics.  Though, I don't think this would
happen on most of codecs.


> > Windows have capabilities to tune each jack as well.  This is a
> > long-standing TODO, and I think "* Jack Mode" enum is the natural way
> > to implement it.  (How to let user setting it is another question.
> > I can imagine that PA could ask user once when a jack is detected.)
> 
> Yes, some kind of "advanced" tab in the sound settings where things can 
> be reconfigured would be nice.
> 
> > About your alternative proposal: the problem by extending the input
> > source selection is that this jack is supposed to be a front mic jack
> > as default.  So, this is always listed in the capture source imux.
> 
> Well, if the "Capture Source" switches to "Rear Line In", then it does 
> not hurt if we retask the front to headphone automatically.
> But if you're going to implement auto-switching based on impedance 
> sensing, this alternative proposal might fail anyway?

It'd be a different logic, yes.

> >> Also, the jack detection won't work well with PulseAudio, if I read the
> >> code correctly PulseAudio will think a front mic has been inserted
> >> regardless of the mode. You have been warned :-)
> >
> > Yeah, it's a concern.  Currently it's no issue because no capture
> > source enum is exposed, so PA can't do anything wrong.
> 
> If PA detects the "Front Mic Jack" kcontrol to be plugged in, and I 
> implement the priority order as I suggested in the other comment, we 
> have now disabled the rear line in because the user plugged in a 
> headphone in the front mic jack.

Yes, the policy conflicts.

> > But if we
> > expose the capture source, it may conflict.  One way to avoid it is to
> > make the capture source inactive on the fly in auto mic mode.
> > The question is how robust PA is, whether it's screwed up by such a
> > change...
> 
> I don't know either...I mean, there is no dynamic reconfiguration, but 
> whether it will crash or just simply ignore that it can't set the 
> capture source I don't know. Try and see :-)
> 
> Btw, I was trying to figure out what PulseAudio version you're actually 
> using for your enablement. I guess it's 0.9.23? [1]

Yeah, the primary requirement is that one, but I've been checking also
with 2.0 and 2.1.

> >> Now; if you have a very strong reason why this machine would need this
> >> special retask mechanism and all other machines don't, I'm willing to
> >> listen...
> >
> > A strong reason for adding the feature to this machine is that this
> > has a print on the top of the front mic jack indicating it's a shared
> > front-mic / headphone jack.  Thus it must behave as advertised.  This
> > is user's expectation.
> >
> > If other machines have such a print, the similar method should be
> > implemented, too.
> 
> Yeah, that's a reasonable point.
> 
> But still I think the method of creating more and more Jack Mode 
> controls will lead to more long term maintenance problems (as the kernel 
> code complexity increases), compared to implementing a more lightweight 
> reconfiguration mechanism.

I don't think jack mode control itself would be too messy.  From the
top view, it provides either bias level and possibly I/O switch that
makes this jack hooking to the existing output route.  Thus, this
doesn't disturb others.

Of course, your concern is about the combination of auto-mic and jack
mode enums.  That can be more different.

Instead of my previous patches, we can start of implementing jack mode
enums at first.  This allows the implementation of a lightweight jack
retasking in user-space.  Again, these enum controls won't provide the
all possible retasking.  They provide only cases where no drastic
topology change is needed.  This will serve most of user's demands, I
guess.  If not, user needs to create a better initial configuration
for own demands.

Once when it gets done, the rest is the automatic capture source
selection.  This would need more discussion, I suppose.


Takashi