Linux USB multiseat audio support

Here’s how to add audio support on top of the previous instructions for getting USB multiseat running on Linux, with a Plugable UD-160-A type device.

Add the following line to the bottom of the /lib/udev/rules.d/50-usbseat.rules file created per the previous instructions.

KERNEL=="control*", SUBSYSTEM=="sound", SUBSYSTEMS=="usb", PROGRAM="/bin/cat /sys/%p/../../../../../devnum", SYMLINK+="usbseat/%c/sound"

Then create a new /etc/X11/Xsession.d/50usbseat file which will be run at Xsession create time, with the following contents

set $2
LN=`ls -al /dev/usbseat/$SEAT_ID/sound`
set $LN
export ALSA_CARD=$2
export ALSA_PCM_CARD=$2

Each of the users who might need access to the USB devices needs to be added to the ‘audio’ group. On Ubuntu 9.04, this can be done with these commands to backup and then modify the groups (replace MY_USERNAME, of course) …

sudo cp /etc/group /etc/group_backup
sudo chmod a-wx /etc/group_backup
sudo adduser MY_USERNAME audio

See Ubuntu Sound TroubleShooting for details on that step.

Now, as you connect UD-160-A terminals, a new X instance and GDM login will pop up as before, but also each of them will have /dev/usbseat/%SEAT_ID%/sound linking to their sound device, and the ALSA_CARD environment variable for all processes off of that X session, set to the matching sound card ID. For apps which support ALSA/Pulse (like most browsers, flash, etc.), audio will now come out the correct terminal — all in a completely plug-and-play fashion.

If you’re wondering what the strange IFS stuff is in the above script, it’s bash’s built-in Internal Field Separator variable, which is an easy way to split strings without having to launch a separate sed or awk process.

Note, as before, these instructions are specific to and tested on an older version of Ubuntu: 9.04, and may need to be ported to other distros until the distros themselves integrate these scripts.

Thanks to Alexander Todorov’s earlier work on multiseat sound support, which demonstrated how to match the USB audio devices in udev, and which ALSA_ environment variables to set. Alexander reported some problems reliably matching the audio devices, but with these scripts (with limited testing so far), things are working as expected.

6 comments on “Linux USB multiseat audio support”

  1. Alexander Todorov

    It’s worth mentioning that for good audio experience there are some more things to try:

    1) On some distros like RHEL and derived it is necessary to add the users to the audio auxiliary group

    2) All sound aware applications need to be configured to use “ALSA Default” device so that they can pick up the device specified by ALSA_CARD. This is usually true for most applications but may not be true if you’re converting a previously used desktop machine to a multi-seat terminal.

    3) Extra care must be taken when manipulating sound settings with application like system-config-soundcard, gnome-volume-control or alsamixer for example. Those applications are not multi-user aware, no access control is in place and if the user doesn’t know which is his SEAT_ID they may for example mute the sound for another seat by mistake.

  2. Bernie Thompson

    Thanks for these notes, and the original work on this, Alexander! On the differences in udev rules – I assume (hope?) these will normalize with future versions of the distros.

  3. dagg

    hello, I’m in the process of researching to build a powerful multiseat.
    as I don’t use gnome, I’ve wanted to know how portable is your code in regarding to the sound to other DEs? does it use alsa-usb-audio? am I right in assuming that the code splits the sound by users?
    how does the code launches the multiple xserver sessions? does it uses nested xservers?
    the reason I’m asking is because I’m not planning to use the plugable dock station because it’s price and the fact that I’m not going to use the dvi output.

    • Bernie Thompson

      Hi Dagg,

      The sound portion should be portable to many USB audio devices that have Linux support, with a few modifications of the scripts. For the rest, the scripts here show everything — it’s currently designed around gnome and X, but definitely can do anything (that ultimately can sit on a kernel framebuffer).

      What we’ve done with the UD-160-A that’s valuable is 1) Make sure all the components have underlying open source drivers 2) Have scripts that support its exact hardware configuration.

      Because this is the terminal market, we’re always looking at ways to hit lower price points. What’s your “magic pricepoint” where a purchase here is an easy decision? We’re going to be launching a “basic” dock/terminal in the coming months to shave a little cost off …

      Best wishes,

      [WORDPRESS HASHCASH] The poster sent us ‘0 which is not a hashcash value.

    • Bernie Thompson

      Oh – another question. In terms of not using the DVI/VGA output of the UD-160-A – is that because you’re thinking about using PCIe graphics cards?

      You may want to get a unit and check out the performance of USB graphics on Linux first (with the udlfb driver). It still has the fundamental limitations of the 480Mbs USB 2.0 bus, but it’s surprisingly snappy — even more so than Windows.

      And the plug-and-play advantages of USB for configuring/mantaining a multiseat configuration are pretty huge.

      That said, it will only become really a big deal once this support is in the distros, and adding a terminal involves *no* configuration — and we’re not there yet.

      Best wishes,

  4. Pingback: linux scripts -

Comments are closed.