[alsa-devel] Jack event API - decision needed

[Takashi Iwai]

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


thanks,

Takashi