Re: Jack event API - decision needed

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

On Mon, Jun 20, 2011 at 08:24:14PM +0200, David Henningsson wrote:

> Exposing what mixers affect this port is highly desirable as well to
> get more accurate than the current name-based algorithm Pulseaudio
> currently uses.

Of course given the potential for internal routing within the card you
can only really say that about the very edge controls that are fully
committed to a given path - hence my comment about exposing the all the
routing being much better.

> Should we design something new, I think we should start with a
> pin/port concept rather than a jack concept. "Internal speaker"
> would then be a port that does not have a jack, whereas "Headphone"
> would be a port that has a jack.

I think that's too edge node focused, if we're going to define new
interfaces we may as well cover everything rather than doing half the
job.

> (Btw, I don't know much about DAPM and how well that scales to cope
> with these requirements, it looks very ASoC to me, but perhaps it's
> just the SND_SOC_DAPM_* naming that fools me. But can DAPM e g send
> events to userspace?)

No, there is no userspace visiblity of the routing map.  It's pretty
much exactly equivalent to the data HDA CODECs expose but shipped in
source rather than parsed out of the device at runtime.