multiseat and PulseAudio?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



'Twas brillig, and Tomasz Chmielewski at 16/05/11 09:49 did gyre and gimble:
> On 16.05.2011 08:49, David Henningsson wrote:
>> On 2011-05-14 17:46, Tomasz Chmielewski wrote:
>>> Traditionally, UNIX systems were supporting multiseat desktop sessions
>>> (i.e. multiple keyboards, video cards, monitors attached to one PC).
>>>
>>> According to:
>>>
>>> http://pulseaudio.org/wiki/WhatIsWrongWithSystemMode
>>>
>>> What is wrong with system mode?
>>>
>>> Or with other words: if you run it that way on your desktop,
>>> then you are doing it the wrong way.
>>>
>>>
>>> What is the correct way to use PulseAudio with multiseat systems?
>>
>> Assuming there is also one sound card per seat, you should run one
>> PulseAudio per seat, and as the user currently logged in to that seat.
>> Exactly how to do that, i e set up access to the right sound card for
>> the logged in user (with ConsoleKit etc) is beyond my knowledge though.
> 
> I only have one sound card in the PC.
> 
> It works fine when I start PulseAudio in the system mode, but according
> to documentation, this is unsupported, strongly discouraged and should
> only be used in some embedded setups.
> So I'd like to do it "the right way" - unfortunately, PulseAudio
> documentation does not explain how to setup PulseAudio with multiseat.

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 option.

It's not nice generally because:
 1. We cannot use SHM for memory transfer leading to more memcpy overhead.
 2. One user can spy on the other user monitor their VOIP streams etc.
 3. Module loading is disabled (for security) by default on system wide
which IIRC affects hotplug etc.
 4. There are some issues with Bluetooth permissions for BT devices (it
can be configured of course but finding it is tricky - I've got mails
flagged in my inbox to add this documentation at some point).

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).

> 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 :)

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]




[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux