[pulseaudio-discuss] system-wide daemon
gmane at colin.guthr.ie
Wed Feb 10 15:22:18 PST 2010
'Twas brillig, and Lennart Poettering at 10/02/10 22:36 did gyre and gimble:
> On Tue, 09.02.10 09:43, Markus Rechberger (mrechberger at gmail.com) wrote:
>>> Indeed. PA is principally meant to be run per-user. Each user logged in
>>> will have their own PA process running and each will monitor a system
>>> service called "ConsoleKit" which tracks which user is active. We adhere
>>> to whatever ConsoleKit tells us with regards to which user is currently
>>> "active" (see ck-list-sessions) and only the active user has access to
>>> the sound hardware.
>>> Think about how switching users works (on Linux and on Windows/OSX).
>>> Only the user whose desktop is currently presented will be allowed to
>>> use sound, the other user's sound is "corked" until they become active
>> Bad example as usual, on OSX everyone (who's permitted to use the
>> audio unit) can just log in and use the audio unit.
> Do we need to have this pointless discussion every second months?
> Last time I checked OSX audio of the sessions that are not in the
> foreground is paused, and only one session has access to the sound
> cards at a time. Exactly like on PA, or on Windows.
This is correct. There is one difference tho' on OSX (which is IMO
horrible) and that is the fact that an inactive user can ssh in and play
sound (via e.g. afplay command line app). I annoyed the hell out of
someone in my office today by doing just this.
But from a user-facing perspective - e.g. logged in user they using fast
user switching - it behaves exactly as you described.
What I didn't try was issuing a "sleep 10s; afplay foo.mp3" and
initiating the switch. I'll try that tomorrow.
Tribalogic Limited [http://www.tribalogic.net/]
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
More information about the pulseaudio-discuss