[pulseaudio-discuss] Using PULSE_SINK and PULSE_SOURCE

Colin Guthrie gmane at colin.guthr.ie
Wed Sep 15 08:14:49 PDT 2010

'Twas brillig, and Alexander Todorov at 15/09/10 14:17 did gyre and gimble:
> Hi guys,
> I'm having a bit of trouble with the usage of PULSE_SINK and PULSE_SOURCE
> environment variables.
> I have 2 sound cards (or more - multi-seat setup) on the PC and everything works
> with Linux (verified by manually selecting the output device in sound
> preferences dialog).
> I want to assign each user that logs into GNOME a default sound card. For ALSA
> that's a matter of setting ALSA_CARD to the index of the sound card in
> /proc/asound/cards
> For Pulse Audio I've read those two pages:
> http://developer.novell.com/wiki/index.php/Feisty/HOWTO:_PulseAudio#Running_Skype
> http://www.pulseaudio.org/wiki/FAQ#WhatenvironmentvariablesdoesPulseAudiocareabout
> Using  `pactl list` to find out the correct sink/source names I then assign them
> to the PULSE_SINK and PULSE_SOURCE variables (this is automated when user logs in).
> Inside the gnome session variables have the correct values however I have no
> sound. I'm testing with rhythmbox and trying to plan online radio. Nothing comes
> out of the speakers.
> So my question is:
> 1) How can I configure different sound cards to be used by different users? The
> envs above look like the correct answer.

No, I think you're on the wrong track here.

You should really be looking at udev permissions and ACLs. These are
much lower level than PulseAudio but PA will honour the details given to it.

Ultimately, in order for a user to be allowed to use a sound card, they
must have r/w permission on the relevant device nodes in /dev/snd/. This
is generally acheived by a bit of software called Console Kit that
"registers" user logins and such like. Only one user at a time can be
"Active" on any given seat. With two seats two users can be active.

The trick here is to make sure that the underlying systems (console-kit
and udev) know which card is related to which seat. That way ACLs can be
written on the device appropriate to the seat when a user logs in.

When pulseaudio starts it will ignore the device that the user does not
have permission to access and by virtue of there only being one card
available, that will be the default one.

Things to note:

You appear to be running a single PA daemon which is why you need to set
PULSE_SINK env var. This is generally bad. Users would technically be
able to record the other's mic and Voip calls and spy on what they are
listening too etc. In other words the security model is all wrong. It is
better to run one PA daemon per-user. This is how we recommend you use
PA - "system wide" mode is not officially supported. There are lots of
other reasons not to use system wide (doesn't handle SHM memory
transfers is a big one, plus not allowing module loading which breaks
certain nice things, including KDE support and per-user preferences).

You have to make sure that the seat configuration is correct and the
right sound card is assigned to that seat. I'm not 100% sure how to do
this, but it's certainly the job of console-kit and udev to work
together on getting it right. You can probably assign certain USB ports
to each seat too, meaning memory sticks and usb sound devices etc. are
only available to the appropriate users too.

Hope this points you in the right direction.

> 2) What happens if some application doesn't support PA? Do I need to configure a
> fall back setting or something?

Generally speaking no. The default and recommended setup is to redirect
ALSA applications (using the "default" alsa device) to PA. OSS
applications (which are few and far between these days) can be supported
via padsp or osspd+cuse+fuse.

This is generally something that should be setup already.

> 3) Any other hints/ideas are also welcome?

Hopefully I've done just that. Let me know if you need to discuss further.



Colin Guthrie

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

More information about the pulseaudio-discuss mailing list