[alsa-devel] Jack event API - decision needed

Takashi Iwai tiwai at suse.de
Tue Jun 28 18:35:33 CEST 2011

At Tue, 28 Jun 2011 17:27:15 +0100,
David Henningsson wrote:
> On 2011-06-27 13:07, Mark Brown wrote:
> > On Mon, Jun 20, 2011 at 03:37:25PM +0200, David Henningsson wrote:
> >
> >> 1) We're continuing the path with /dev/input devices
> >
> >> 2a) We'll rewrite these devices to be read-only ALSA mixer controls
> >
> >> 2b) We'll rewrite these devices to be something within ALSA, but not
> >> exactly mixer controls.
> >
> >> For options 2a) and 2b) I guess the existing /dev/input thing should be
> >> deprecated and/or removed. So part of decision should maybe be based on
> >> information about how widespread the usage of these devices are
> >> currently...?
> >
> > So, this discussion seems to have ground to a halt.
> Yes, unfortunately, and without a clear consensus. That puts me in a 
> difficult position, because I'm trying to get the job done. And very 
> preferrable, in the next release of Ubuntu (which is to be released on 
> October this year). I've been talking to a few of my colleagues here at 
> Canonical, and here's how we reason currently:
> We have the input layer. We also have a set of patches for supporting 
> this in PulseAudio (although currently unmerged and I'm not sure about 
> their current quality/state).

So, the targets are already defined, i.e. what information is actually
required?  This wasn't very clear to me until now.

> We don't have the alternative Alsa Control API discussed in this thread. 
> Without taking a stance of whether that would be a better solution or 
> not, designing it will take some time - somewhat depending on the set of 
> problems we're aiming to solve. Regardless, it will definitely not reach 
> the 3.0 kernel (which is what we will ship in the next release of Ubuntu).

If only the same functionality is required as currently done in the
input-jack layer, re-implementing the jack-detection elements in ALSA
control API is pretty easy.  It means that the control element would
have some jack name with a location prefix or such, reports the
current jack status, and notifies the jack change.  That's all.
Optionally, it can have a TLV data giving the HD-audio jack
attribute, too.

As already mentioned, the difficulties of implementation mainly
depends on the requirements.  If just a flat array without structural
connection is enough, it's easy, of course.

But, it definitely won't reach to 3.0 kernel.  So, maybe this won't
help in your case, anyway...



More information about the Alsa-devel mailing list