[pulseaudio-discuss] multiseat and PulseAudio?
gmane at colin.guthr.ie
Mon May 16 03:05:57 PDT 2011
'Twas brillig, and Tomasz Chmielewski at 16/05/11 10:49 did gyre and gimble:
> On 16.05.2011 11:37, Colin Guthrie wrote:
>> Well in this evironment, I'd say that if you only have one card to be
>> shared between the seats, then system wide mode is likely the right
>> It's not nice generally because:
>> 2. One user can spy on the other user monitor their VOIP streams etc.
> Since all users hear the same audio from loudspeakers, it's not a
> concern :)
Indeed. One man's "problem" is another man's "feature". :p
>> And we don't test it particularly heavily, but all in all it should work
>> fine (assuming you write your own init script and/or your distro does
>> that for you).
> Unfortunately, it does not work fine, and was a reason why I'm
> investigating running PulseAudio per-user.
> When I run it in system mode, it crashes (or exits? not sure). It's not
> something what happens very often - once every 3 days perhaps. But
> annoying (no music anymore, normal user can't start PA in system mode
> Since the documentation said I'm not likely to get any help when asking
> for system mode issues, I though I'm really doing something wrong and I
> should use it per-user.
Ahh, we're probably a little too forceful there I guess. It's generally
to discourage people from the wrong path as there are not that many
cases where it makes sense. In your case it does make sense.
With regards to bugs, we'll obviously take a look at any problem,
especially as one that is triggered in the system-wide case may be
triggered in the per-user case too but under less obvious circumstances
(or masked by the fact that a typical per-user setup with autospawn
again automatically if it crashes). All bugs will be looked at.
When we switch over the website stuff, I'll take a look at rephrasing
that section a little.
>>> If I start PulseAudio in the user mode, only one user gets a sound card;
>>> the second one gets "Dummy Output".
>> Yeah, that's either because the second user does not have permission to
>> access the device (due to ConsoleKit ACLs only the "active"
>> (ck-list-sessions) user should get the ACL, but this could actually
>> cover both users in your setup) or due to the fact that the card can
>> only be opened once.
>> Normally what you'd due is define some kind of udev magic that defines
>> "seats" and thus contextually assigns certain USB ports and/or h/w to a
>> given seat. Then when a user (any user - it's not tied to the seat) logs
>> in, console-kit and udev both apply the right ACLs and PA can start and
>> only show the relevant sound cards to the relevant seats. This is how it
>> should work in an ideal world - everyone getting their own stuff. But in
>> a situation where you accept all the problems listed above (things like
>> security likely don't apply when people know each other :)) then system
>> wide is fine.
>> Hope that helps :)
> Well, the theory is nice :) but from user's perspective, sound with
> multiseat became unreliable when distributions migrated to PulseAudio
> (not that the life of a multiseat user was ever easy, but still, it's
> yet one thing which discourages multiseat).
> Perhaps I'll try to see why PA crashes/exits when used by multiple users
> in the system mode, report it to the mailing list, and hope won't get
> too many "system mode is unsupported, go away" replies ;)
Yeah, please do that :)
If you can somehow manage to get a backtrace out of it that would be
great. I find running gdb separate and connecting to PA with the
appropriate "handle..." line before continueing is the best way to get a
good backtrace. I guess leaving it running in a screen and waiting for a
crash is the best approach here?
Some info (including the handle line mentioned above):
Tribalogic Limited [http://www.tribalogic.net/]
Mageia Contributor [http://www.mageia.org/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
More information about the pulseaudio-discuss