Re: Jack event API - decision needed

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

On Wed, Jun 29, 2011 at 08:13:42AM +0100, David Henningsson wrote:

> However, if we manage to expose all the routing between PCMs, volume
> controls and ports, we can make an even better PulseAudio, because
> we can solve other problems as well, such as the volume control
> naming problem. But figuring out how to do that in the best way
> API-wise and so on, I guess that will take some time.

This is really a totally separate question, there's so much routing
within the devices that the jacks are just not a particularly
interesting part of it.

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

> Yes, but it is not clear to me that this is the decision, and what
> we actually want to do. So far I have only seen Kay and Lennart
> advocating for it and Mark against it. I started off this thread
> because I needed a decision, but so far no clear decision has been
> made.

I'm not against having the information in ALSA, or really against using
separate APIs.  My main concern is being able to group the objects back
together again for use both in kernel (when the hardware overlaps) and
in userspace in an understandable fashion and I've not seen anything
that I'm as comfortable with as a directly visible object exported from
the kernel.  If ALSA chooses to export some subset of the information
that's kind of orthogonal to that issue.

I do have to say I like not having to use alsa-lib to get the
information but that's even less of a big deal.