'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. > Incidentally, this seems to be the same use case that vision-impaired > users were dealing with recently: How can system-level processes inject > their inputs to the speakers without a system-level pulseaudio daemon > sharing that hardware? They can't and they shouldn't. The problem is that the models are broken. All the models for this have been decided upon and it's just waiting for people to do the implementation in the various bits of the stack. See the archives for more info. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
