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.