1. In /etc/X11/XWrapper.config:

Add or change the allowed_users option to be “allowed_users=anybody”

2. Use a shell script like the following. This one is specifically for launching a game called Enemy Territory: Quake Wars. The good thing about this script is that it preserves command line arguments, so it can be a drop-in replacement for the original executable by placing it in a directory whose path comes before the directory that contains the executable (most likely ~/bin will be an excellent choice).

#!/bin/sh -u

#path to enemy-territory install
ET_PATH="/usr/local/games/etqw"

#give the authorization to launch a window from the current X server (:0)
# to future new X server (:1)
MIT=`xauth list | grep  'unix:0' | head -n 1 | grep -o 'MIT-MAGIC-COOKIE.*'`
xauth add :1 $MIT

#Various shell variables for ETQW

SDL_VIDEO_X11_DGAMOUSE=0
SDL_MOUSE_RELATIVE=0
SDL_AUDIODRIVER="pulse"

cd "$ET_PATH"
#launch et in :1
xinit "$ET_PATH/etqw" "$@" -- :1 -br &

3. Add your user to the group audio.

sudo usermod -aG audio <username>

This allows extra X sessions created by <username> to output audio in the first place.

And it’s that simple. That script could use some improvements, of course, (like launching in a third X session if the second is currently in use) but I am a lazy person. Now back to my problem: getting sound to work in two X sessions at once. I could not for the life of me figure out what had changed between my Ubuntu Intrepid and Jaunty/Mint7. An hour of Google searches turned up nothing, mainly just developers on bug reports and other people stating that sound playing in more than one X session at a time is blocked on purpose for a reason, which was usually for fast user switching to not play sounds from both users at once. But they failed to mention any way to override that behavior if a user wants to. I don’t use that feature rarely, if at all even, and I found it more important to be able to play music and also play a game at the same time.

But I was in luck. After even more Google searching, I discovered a mailing list where a solution was proposed. Apparently, policy kit will (indirectly) disable an inactive X session’s access to the audio hardware by default now.

A simple command will fix this by allowing inactive X sessions access to the sound device:

sudo polkit-action --set-defaults-inactive org.freedesktop.hal.device-access.sound yes

And if we ever want to reset to the default (e.g. disallowing inactive access), we can do this:

sudo polkit-action --reset-defaults org.freedesktop.hal.device-access.sound

Just remember this may break the standard user switching capabilities, though.

EDIT: Ubuntu 9.10 Karmic Koala apparently switched to a different version of policykit, which does not support the above commands. After grumbling about how the devs decided to switch to a new implementation that does not support the previous implementation’s features, I discovered a hackish way to accomplish the same thing. The problem arises from that fact that the new PolicyKit does not manage the sound card’s access anymore, and delegates that task to udev. Unfortunately, I could not figure out how to modify udev’s access control list (not even sure if it’s possible or not). So instead I disabled the sound card being controlled by an ACL and just used basic udev permissions. Here’s how to do it:

In the file /lib/udev/rules.d/70-acl.rules, disable this line by commenting it out (just add a # character to the very front to it):

SUBSYSTEM=="sound", ENV{ACL_MANAGE}="1"

Now, access to the sound card is limited to only users that are part of the audio group (which is the default setting without that above line enabled). So we need to do one more thing: add the user that the login screen runs under to the audio group, so you can hear that Ubuntu drum sound on the login screen. =] )

sudo usermod -aG audio gdm

Remember that you must be root to edit that rules file. (Use “gksu gedit <filename>” in a terminal.) After editing the file and fixing the gdm user’s access to the sound card, reboot. That should do it!