Re: Jack event API - decision needed

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

On Mon, Jun 20, 2011 at 06:59:46PM +0200, Takashi Iwai wrote:

> If udev is being used by real users of such input devices, it'd be a
> good justification.  In the previous thread, I also gave some
> examples that the input-jack device was used for HD-audio media-PC
> devices, but it's not clear whether udev is used there.  And I'm not
> sure whether there are real users of embedded devices with the
> input-jack layer that requires udev's ACL handling.

I don't think the embedded space cares desparately about the udev stuff
since most of the time the system management daemon which owns this
stuff is running as root anyway, PulseAudio or otherwise.

> OTOH, if this is mainly targeted for the future extension of
> PulseAudio, the primary question would become different.  Possibly the
> path via ALSA control API might give more information than the current
> implementation with the input-jack layer.

I think they can both either give equivalent information or work in
concert, I don't see a need to pick between the two.  Like I say the
jacks aren't exclusively for audio use so if we have to rely on the ALSA
APIs to get information about them it seems like we're messing up.  For
things like working out where the jack fits into the audio routing map
we'd certainly want to have ALSA API integration but that doesn't mean
everything about the jack has to go that way.