How do I configure sound with PulseAudio and Multiseat?
In the spirit of full disclosure, i just posted this question to the ubuntu forums, but i figure more heads working on it couldn't hurt.
I have a multi-seat setup working quite well. Hot plugging input devices works as expected and such. The only issue I am still not able to resolve is getting the audio for each seat.
Here is a summary of my attempts at getting audio to work:
-
Make ~/.pulse/default.pa dynamically configured based on which $DISPLAY the user logs in at.
- See this pastebin for the details.
-
Load pulseaudio as a system-wide instance.
- Couldn't get this to work. None of the audio hardware was accessible to the users.
-
Use udev rules to mark seats in ConsoleKit. Following udev guidelines found here: http://www.freedesktop.org/wiki/Software/systemd/multiseat
- I didn't think this would work, although it was "guaranteed" to work by someone in irc.freenode #pulseaudio
None of those attempts yielded success, which is why I now turn to the community for help. It is quite possible that the suggested methods work and I just messed some aspect of it up, idk. This is the last piece of the puzzle which is needed before I can go and update the MultiseatX page to include instructions for Ubuntu 12.04.
My understandings on the situation:
Access to pulseaudio is restricted to the active session as marked by ConsoleKit (something about an ACL). CK can only mark one session as active at a time. This simple little fact of life leads me to believe that the solution should involve pulseaudio being run as a system-wide instance. Each user should connect to the pulse server and be limited to a subset of all the hardware. Maybe each user connects to the pulse server via localhost, idk. I do know that regardless of my attempts and their failed results, I was always able to use sudo aplay -D plughw:0,0 /usr/share/sounds/alsa/Front_Center.wav
to play something to any of the hardware.
I'm grasping at straws and am now down to the last few hairs i can pull out of my head. Please, help me figure this out so we can share the wealth. Any additional information needed will be provided at your request.
Solution 1:
I've spent many hours researching online, testing various setups and talking to Pulseaudio devs. The bottom line of it all is that running pulseaudio in normal user mode will allow only the active session as marked by ConsoleKit to access the audio hardware. Since current ConsoleKit is only able to mark one session as active at a time, this means that we must run a system-wide instance of pulseaudio. The upside: Each seat can have individual audio. The downside: ALL audio hardware is available to any user and can be manipulated AT WILL. This is not an ideal situation for an internet cafe or other public setting where security is a real concern. Keep this in mind when creating your site security policy. It might be prudent to restrict pavucontrol execution to admins only.
As always, make a backup of all of your default config files. If you have tinkered with your configs without backing up, you may retrieve the pulseaudio package with apt-get -d install pulseaudio. This will download the package (to /var/cache/archives/apt) only and you can extract the contents to retrieve the default configs. Be aware that client.conf is not included in there.
To run pulseaudio as a system-wide daemon, we need to edit a few files.
1.) /etc/default/pulseaudio
PULSEAUDIO_SYSTEM_START=1
2.) /etc/pulse/daemon.conf - See man pulse-daemon.conf for more information.
daemonize = yes
local-server-type = system
3.) /etc/pulse/client.conf
autospawn = no
We also need to add users to the pulse-access group.
sudo usermod -a -G pulse-access <username>
Now that all users are able to access the audio hardware, we need to select the hardware each user will use. This can be done using pavucontrol. Please be aware that the settings are stored PER USER and will not follow the seat. If users switch seats, you will need to re-select the desired audio hardware.
Additional Comments on Pulseaudio
I had hoped that there would be a more elegant solution for getting per seat audio working. Using a systemwide Pulseaudio in multiseat has many drawbacks and is not entirely stable between reboots. I had attempted to start a systemwide instance and have user instances connect to it as a server via localhost. That doesn't seem to work since when pulseaudio --start is run it sources daemon.conf.
Regarding ConsolKit
The issue we see when running a normal per-user pulseaudio is that one seat has access to the hardware and all others have Dummy Output. This is due to ConsoleKit not being entirely seat aware. CK considers all of our seats as sessions of seat1 and can only mark one session as active. This fact can be seen by running getfacl /dev/snd/*. The thought occurred to me that we might be able to edit the acl of the appropriate /dev/snd/ files based on which $DISPLAY a particular user is using. This is an option that I have not explored. Please consider contributing to the multiseat cause by exploring this hypothesis and editing the document with your findings.
Multiseat branches for ConsoleKit, GDM-2.3 and GDM-3.x do exist which should provide for automatic multiseat functionality.
Additional Notes
1.) It would be wise to also disallow users from loading modules DISALLOW_MODULE_LOADING=1.
2.) autospawn = no is not entirely necessary as seen in my example file. It causes no issues.
Solution 2:
My understandings on the situation: Access to pulseaudio is restricted to the active session as marked by ConsoleKit (something about an ACL). CK can only mark one session as active at a time.
There is a patch to ConsoleKit to add multiseat support; this will allow it to report all active seats as active. Perhaps this will fix your problem. It needs cooperation with the display manager, and there is a patch to old versions of GDM that adds this support.
I got multiseat working in Natty (11.04) using modified ConsoleKit and GDM packages from a PPA. I haven't upgraded from Natty yet -- it took me a long time to figure out how to get it to work, and I'm worried that LightDM won't work with the patched ConsoleKit.
EDIT: I should note that Fedora 17 has some impressive multiseat features, some of which will be in Quantal. They have a wiki page describing their approach. Ubuntu can't simply copy Fedora's approach because it would require significant changes; Fedora uses systemd and GDM while Ubuntu uses upstart and LightDM.