Re: Jack event API - decision needed

Takashi Iwai
2011-06-20T17:38:51Z

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.

Agreed.

Takashi