[alsa-devel] [PATCH 2/2] ALSA: Integrate control based jack reporting with core jack reporting

David Henningsson david.henningsson at canonical.com
Thu Feb 23 08:25:06 CET 2012


On 02/22/2012 05:52 PM, Takashi Iwai wrote:
> At Tue, 14 Feb 2012 08:20:50 +0100,
> David Henningsson wrote:
>> I would vote for "C2", although I would probably prefer "[location] base
>> [channel]" over "[location] base [direction] [channel]", as direction is
>> superfluous given "base". This is also what the current implementation
>> offers, and what I've based my PulseAudio patches on.
>
> Actually, C>  B, thus we may take an approach of C optionally.
> In both cases, we'd need an id string or such (e.g. "Jack" suffix) to
> indicate that it's a jack kctl.  If this is satisfied, the rest prefix
> and suffix can be fully optional.
>
> That is, for those who don't need the additional information (yet),
> just pass the base name.  For multiple items, use the multiple
> indices.  This is equivalent with B.
>
> For those who care about the multiple items (e.g. HD-audio), they can
> pass the more verbose name.  It's C.
>
> The rest is the job of the user-space side parser.  It'll gather all
> items with "Jack" suffix, then trim location, direction or channel
> prefix/suffix.  It shouldn't be too hard.
>
> Yes, it's redundant.  One can represent it in both ways via TLV or
> name string.  But it works even now (before the TLV definitions),
> that's the point.

I agree with this reasoning.

>> A and B requires additional work as we would need an API in alsa-lib
>> from where you can read and interpret the TLVs, and stuff like amixer
>> needs to understand it too make it reasonable easy to work with and
>> test. And C gives the option to add TLVs later whenever we feel the need
>> for it, so it seems to be an all-win.
>
> Honestly speaking, I think the plan A isn't that bad.  The suffix
> look-up and filtering as mentioned above looks slightly messy.
> It'd be much simpler in both kernel and user-space implementations.
> The biggest drawback is that David would need to rewrite his patch to
> match with this scheme :)  And, of course, it's not visible with the
> current alsa-utils stuff.  The verbose name string would be visible by
> alsactl or whatever even in the current version, yes.

And it requires some specification on how this TLV will look like, my 
head isn't completely clear on that. But maybe you got that all figured out?

But let me stress that the matching is actually what's most important to 
PulseAudio at this point: assume we have one 'Front Mic Jack' and one 
'Rear Mic Jack' - when the rear mic is plugged in, and the user wants to 
change the mic gain, PulseAudio should make sure that 'Input Source' is 
set to 'Rear Mic' and that it changes 'Rear Mic Boost', 'Capture' and 
nothing else. (And, for HDMI, we also need to match against the correct 
PCM device.)

That's why I like C best so far, because I can match on the names. (And 
yes, that I don't have to rewrite my patch a second time is an added 
bonus :-) )

>> Also; as this graph exposing thing is unlikely to be implemented in all
>> layers of the audio stack any time soon, maybe C2 is also the one that
>> gives the most obvious matching between mixer kcontrols and jack
>> kcontrols? I'd like to move in this direction; not only because we
>> currently do not have the graph, but also because that even if we have
>> it, userspace apps choosing not to implement it will have a good option.
>
> IMO, this graph things should be considered separately at this
> moment.  The name string itself won't be always enough to identify the
> connected kctls.  If any, we can add a new TLV to represent the
> associated kctls, as the driver already knows which widget NID is
> assigned to which control.  This would be simpler and more robust, I
> guess.

Hmm, but for that to actually work out reliably, we're going to need
1) all inputs and outputs, not only those with jacks. So we can know if 
there is a 'speaker' or not, and
2) deal with multiple DACs and ADCs somehow. Or are you assuming we 
always use the first DAC/ADC here?
3) a reliable way to tell that we can use this method for mixer probing 
or if we should fall back to the current method.

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


More information about the Alsa-devel mailing list