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

[Takashi Iwai]

At Mon, 13 Feb 2012 11:23:10 -0800,
Mark Brown wrote:
> 
> On Mon, Feb 13, 2012 at 06:40:23PM +0100, Takashi Iwai wrote:
> > Mark Brown wrote:
> 
> > > With these patches I'm mainly looking for a quick and simple refactoring
> > > to get rid of the duplication - once we've got rid of the duplicate
> > > driver APIs then we can refactor the internals of the implementation
> > > however we like but there's a pretty pressing need to fix the driver
> > > API and get all the drivers doing the same thing to userspace even if
> > > it's not ideal.
> 
> > Hm, then I'd say let's hold on.  Merging this half-baked stuff is
> > rather confusing at this point since the use of kctl jack isn't
> > targeted yet for ASoC.
> 
> > I believe what we need _now_ is to decide the policy (i.e. element
> > naming rule and TLV definitions) for kctl jacks quickly.
> 
> Now that the kctl jacks are there I'm getting people asking me about it
> often enough so I'd like to see it merged.

Yeah, if things were easy, I'd be happy to merge.
But, judging from the situation, I see no big reason to hurry too
much.

> > > > In other words, if 1:1 mapping isn't needed, we don't have to create a
> > > > different name string at all.  Just create "Jack Detect" controls with
> > > > different indices and with corresponding TLVs.  This would be enough
> > > > (could be even easier) for a machine parser.
> 
> > > That'd work I think, though I would create a new control for each
> > > physical jack at least just for clarity.
> 
> > They are indeed individual ctl elements.  They just share the same
> > name and are distinguished by the index numbers.  For the parser
> > program, it would be even easier because it needs to look only for
> > elements containing the single string.  The rest is the parse of TLVs
> > of gathered elements, which would be needed no matter whether we have
> > multiple name strings or not.
> 
> I think we're mostly agreeing here - what I'd like is to be able to give
> each jack a descriptive name which shows up in the control name
> ("Headset", "Docking Station") along with "Jack" or some other keyword.
> The descriptive name could be optional, but it seems nice to put it in
> the control name.

Yes.  My concern is then how to map the existing jack API to the new
name.  Thus I proposed some examples.

> > So, at this point, I can list the following policies for kctl jacks:
> 
> > A. all kctls have one name string with different indices.  Each jack
> >    is distinguished by the TLV provided to each kctl.
> 
> > B. kctls are built with only a base name ("Headphone", "Mic") with
> >    different indices and TLVs.
> 
> > C. kctls contain unique names ([location] base [direction] [channel])
> >    optionally with TLVs
> 
> I think I prefer B here with the base name being a descriptive name
> (which could often be like the above) that should be unique within the
> card, even if the driver just adds numbers.

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


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


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


thanks,

Takashi