[alsa-devel] Jack event API - decision needed

Takashi Iwai tiwai at suse.de
Mon Jun 20 19:38:51 CEST 2011

At Mon, 20 Jun 2011 18:17:45 +0100,
Mark Brown wrote:
> 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.

Yes, we can implement both concurrently.  They don't conflict.

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



More information about the Alsa-devel mailing list