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.