[pulseaudio-discuss] system-wide daemon

[Lennart Poettering]

On Wed, 10.02.10 18:49, Jeremy Nickurak (pulseaudio-discuss at trk.nickurak.ca) wrote:

> 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 are root you can do anything you want, including doing the
baddest things to your audio devices you want.

And as mentioned a gazillion of times in recetn distros even non-root
users can do this, regardless whether they are logged in or not, if
they are a member of the "audio" group.

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

Nope, there should not be a system-level process generating the speech
audio. It should be a user/session process. Now, unfortunately the
current solutions are mostly based on system daemons, but that doesn't
mean that that would be the "correct" way to handle these
things. Because it is not.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4