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

[Takashi Iwai]

At Mon, 03 Dec 2012 14:43:37 +0100,
David Henningsson wrote:
> 
> On 11/30/2012 10:39 AM, Takashi Iwai wrote:
> > 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:
> >>>> 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.
> 
> Trying to summarise this long thread, we seem to advocate these two 
> options as I see it:
> 
> 1) Use the hwdep interface:
> 
> Pro: Simplest kernel code
> 
> Pro: Can support more options, higher degree of freedom for user
> 
> Con: Any reconfiguration is a bit disturbing and can e g break currently 
> running audio streams.
> 
> Con: (Currently) requires root privileges to change, since it works 
> through the hwdep interface.

Con: how can you ensure the exclusive setup and the exclusive access?
Imagine multiple sessions are using different configurations.

Con: how would you manage the mixer elements from hwdep at all?
There are independent mixer applications.

> 2) Base reconfiguration on jack-mode controls
> 
> Pro: Simpler for user to reconfigure jacks
> 
> Con: More complex kernel code than first option
> 
> Con: It might be difficult to get the volume/switch control names right 
> in all scenarios.
> 
> Con: Needs work in PulseAudios and GUIs to support jack retasking 
> better, or it will be either unsupported (for the average user) or 
> confusing.

Hmm...  I don't get it.  How can hda-jack-retask or whatever be a
better option than PA?  The integration work for PA is more or less
necessary.  Launching another application may be more confusion for
user, no?

> Also; since the parsing code is still separate between codecs, we have 
> to implement all of this complexity over and over again...

It's "still".  They will be merged sooner or later, anyway.

> Probably we can sort out most stuff with option 2) too, I mean, with the 
> capture source, automute and autoswitch, rerouting paths, repurposing 
> DACs, and all that, but the question is really, should we? Are we 
> willing to take the cost of the added complexity that comes with it? Are 
> we be able to get it right, or do we get several broken kernel versions 
> before we get something that works really well?

I don't think it'll be too complex in the end.  We'll be reducing the
code while merging such a new feature, especially by unifying the
codes from multiple drivers.  Once after this gets done, the driver
will cover all needed demands for IDT, Conexant, Cirrus and VIA, and
most of AD and C-Media codecs.  Let's see.


> >>> 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 :)
> 
> Ok, so what do you mean with "automatic"?

Sorry, it wasn't automatic "retasking" but muting.


> >>> 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.)
> 
> Btw, how "disturbing" is it when you retask jacks on Windows? What 
> happens e g if you try to retask a jack you're currently outputting 
> audio to?

I don't know exactly, too.


> >>> 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.
> 
> How important is it for you to actually get support for this stuff in 
> PulseAudio? I mean, you're certainly more than capable of adding 
> kcontrols, but I've never seen you - or anyone else from your team - 
> submitting patches against PulseAudio to have support for these things 
> all the way through to the user.

Honestly, I don't care at this moment at all.  A part of the reason is
that I don't use PulseAudio on my machines.

But for normal users, PA support would be a really "good to have".


> >> 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.
> 
> As an example. Say that we have three DACs with amp-outs. In standard 
> configuration the first DAC's volume control is called "Speaker Volume" 
> and the second DAC's volume is called "Headphone Volume". Suddenly you 
> get a Jack Mode switch or multi-I/O switch, so that the three DACs now 
> go to "Front", "C/LFE" and "Rear". The headphone must then be rerouted 
> to the first DAC. But what happens to the volume controls now?

No.  This doesn't happen.

The additional output via jack mode enum is just a hook to the
existing I/O topology.  It can hook to "Headphone" volume as a
secondary headphone, but nothing else.  If it can't to hook the
headphone volume, no option will be provided.

If more drastic change is needed, user has to reconfigure the whole
topology by setting the initial pin configs.


> > 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.
> 
> What if there suddenly is "demand for such feature" for something that 
> *does* change the topology a lot?

Again, it doesn't change the topology.  If it needs to change the
topology, it's not what we support in the mixer API.
This needs reconfiguration, thus it essentially needs to restart the
whole driver functionality.


Takashi