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.