[alsa-devel] [PATCH 4/5] ALSA: hda - Implement shared front mic/hp jack for HP Z220
david.henningsson at canonical.com
Mon Dec 3 14:43:37 CET 2012
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.
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
Also; since the parsing code is still separate between codecs, we have
to implement all of this complexity over and over again...
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?
>>> 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"?
>>> 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
>>> 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
>> 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? 
> 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.
>> 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?
> 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?
David Henningsson, Canonical Ltd.
More information about the Alsa-devel