[alsa-devel] [PATCH v3 1/2] ALSA: jack: create jack kcontrols for every jack input device

[Takashi Iwai]

At Mon, 23 Mar 2015 12:08:17 +0200,
Tanu Kaskinen wrote:
> 
> On Sat, 2015-03-21 at 02:22 +0000, Jie, Yang wrote:
> > > As you'll find through the whole output, many calls are combined with
> > > SND_JACK_BTN_* bits.  And think again how this will result with your patch.
> > > A call like
> > > 
> > > 	snd_soc_card_jack_new(card, "Headphone",
> > > 		SND_JACK_HEADPHONE | SND_JACK_BTN_0 |
> > > SND_JACK_BTN_1, ...)
> > > 
> > > would give three kctls, all "Headphone Jack" with indices 0, 1 and 2.
> > > How user-space knows what is for what?
> > [Keyon] yes, this is an issue I was thinking about, we need discussing and conclusion
> > about that, including comments from user-space, here adding Tanu.
> > Here I am thinking about
> > 1. do we really need kctls for buttons(SND_JACK_BTN_n)? if no, that is simplest, 
> > we can filter out them at this kctl creating stage.
> > 2. if yes, then we need an name regenerator here, to generate understandable
> > (for user-space) kctl names for buttons.
> 
> >From PulseAudio point of view, you must make sure that "Headphone Jack"
> with index 0 doesn't refer to a button, because the assumption is that
> "Headphone Jack" at index 0 refers to a jack and not a button (indexes
> other than 0 are currently ignored). Other than that, PulseAudio doesn't
> currently care, because there's no support for buttons.
> 
> When thinking about how to implement button support in PulseAudio, the
> first question is that are kcontrols a realiable interface for getting
> button events? What happens when the button is pressed? Does one press
> cause only one on->off or off->on state transition, or is the state "on"
> only for the duration of the press? If the former, then kcontrols should
> be fine, but if the latter, is it guaranteed that the application sees
> the event? If the button press is a short one, causing a quick
> off->on->off transition, is it possible that the application gets a
> notification of a mixer change, but when the application then inspects
> the mixer state, the button state is already "off", so the application
> doesn't get enough information about what happened?

It's a good point.  The notification via kctl can't follow the
complete state changes since it's nothing but a notification telling
"something changed".  So, events like buttons that need the complete
state change history, the current implementation isn't appropriate.
For things like jacks, we usually care only about the final state, and
the state change is much less frequent, so kctl notification works
well.


Takashi