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

[David Henningsson <david.henningsson@canonical.com>]

On 12/03/2012 03:07 PM, Takashi Iwai wrote:
> 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?

The integration work for PA in hda-jack-retask is such that 
hda-jack-retask kills PA before making a change (to avoid EBUSY and to 
make PA adjust to the new config).

But anyway. I agree that if we get a good mixer/kcontrol interface, the 
second solution has the advantage of an existing infrastructure for 
saving and restoring volumes between sessions, and support for different 
mixer application will already be in place.

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

I believe that when I see it - surprise me :-)

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

Ok, that makes sense.

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

Right, but you begin this thread by saying you didn't like the patch, 
but there was "demand for such feature". Doesn't the 
person/boss/customer/etc who demanded that feature care about it being 
accessible to the "normal users"?

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

Yes, this time around. But what about the next time there is a "demand 
for such feature" on a codec which has a different graph? Then you might 
not be so lucky that you can handle the same retasking without changing 
topology. That's the scenario I was wondering about.


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