On Thu, 11.02.10 02:01, Colin Guthrie (gm...@colin.guthr.ie) wrote: > > 'Twas brillig, and Jeremy Nickurak at 11/02/10 01:48 did gyre and gimble: > > A question about the console-kit approach, where the user physically > > near the sound hardware is the person that gets to use it... > > > > A favorite trick of mine is to ssh into a machine, and use the sound > > hardware there to announce some kind of event. It might be an alarm to > > wake up a family member, or a remotely-generated event alert. It might > > not be SSH, it might be a cron job, or a CGI... > > > > Assuming I'm the administrator of the machine, how can I pull off this > > trick in the context of console-kit? If it's even possible, it sounds > > like I'd have to suspend the existing pulseaudio connection by assigning > > rights to a "virtual console" of some kind, which would then have the > > opportunity to use the audio device until it released it. > > If you're an admin you'd simply "su" to the active user and use their > access credentials to access their PA system.
Also, one could make your admin user member of the "audio" group, and access the audio device regardless of who's logged in -- but potentially you'll clash with a running PA/audio app which already has the device open. Or, at a higher level you could configure /etc/pulse/default.pa's module-native-protocol-unix to use an "auth-group" even when running in per-session-mode. All user session should then pick that up and members of that group will always be allowed access. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss