Multiple users and ACL on USB sound devices

[olek]

I have: pulseaudio 0.9.21.1
On gentoo, compiled with: USE= X, alsa, asyncns, -avahi, -bluetooth, caps, dbus, -doc, glib, -gnome, hal, ipv6, -jack, -libsamplerate, -lirc, -oss, -system-wide, -tcpd, udev, -test
Under KDE Version 4.3.5.

olek@trol ~ $ cat .asoundrc
pcm.pulse {
        type pulse
}

ctl.pulse {
        type pulse
}
pcm.!default {
        type pulse
}
ctl.!default {
        type pulse
}

my soundcard in lspci: 00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia (Intel HDA)

So. The problem is when I am locking the screen under kde with playing radio in the mplayer and another user will create new session in KDE. It runs separate X server under vt8, and my sound(from my mplayer) is going down, but mplayer still works. When this user will logged off, and I will unlock my screen, I need to kill pulseaudio (with -9), run it again, and after that kill mplayer and run it again.

P.S. I am sorry for my english, and thank you for help

[frodeseverin]

I have related problem.

I am running Debian Squeeze/Sid with KDE 4.4. If I start a new session from KDM, only one of the sessions has sound. It seems that pulseaudio is suspended for the first user, until the second logs out.

I use Xine as backend for Phonon. The behaviour is sililar for applicatons using pulseaudio directly, e.g. Skype.

I tried to set up my system according to the instructions in "The perfect setup" on pulseaudio.org.

How can this be fixed, i.e. how am I supposed to set up pulse and related software to enable multiple X sessons with sound output at the same seat at one time?

Regards ;)Frode

[coling]

This is actually the expected behaviour.

It is not technically PulseAudio who imposes this, but lower parts of the system, namely Console Kit and udev. Ultimately if your session is not active (ck-list-sessions), then CK+udev ensures that your user does not have write permission on the device nodes in /dev/snd/* by virtue of editing and removing user-specific ACLs on those nodes.

PulseAudio simply checks to see that your user is permitted to access those device nodes and if you do not, it ensures that all current (and any future) streams are "corked" (a term meaning 'forcibly paused').

So really all we are doing is behaving like a good citizen based on what the underlying systems impose upon us.

If you are one of the few users who actually want to allow a user with a locked screen to play their Brittany Spears disog on loop at max volume, then you have a couple of options, although they are not officially supported.

You can either

a) Add your users to the 'audio' group. This requires that your hardware supports hardware mixing, so is generally not a useful option as most h/w does not support this. or b) Setup pulseaudio in system-wide mode. This is pretty evil from a security stand point (other users can eavesdrop on your voip conversations and other such like nasties) plus lots of efficiency savings are lost (no SHM for app->PA data transfers means the requirement for memcpy). Also there is the overhead of running PA as a system service and adding all the users you want to allow access to it to the pulse-access group. While we don't intentionally break it, system-wide mode is not really officially supported.

So all in all, this is not really the designed use-case, but the underlying principles are really lower down in the system and not something we can work around without fundamental rethink of both PA design and many of the underlying systems and permission models of Linux userspace itself.

Just FYI, PulseAudio client applications can use a 'cork notification' to pause themselves and thus present their GUI more gracefully when the users session is reactivated. (FWIW this is very similar to what happens on OSX too. i.e. compare what happens when using OSX and you do a "fast user switch" while iTunes is playing, it will pause itself - however, if you run VLC on OSX and switch away, VLC will be corked but will carry on where it left off when you return without any manual unpausing as is needed in iTunes - i.e. it does not support nice feedback and is forcibly corked).

[frodeseverin]

Thakn you for your prompt response.

Now I thihk I had H/W mixing with Linux kernels 2.4 and corresponding alsa, but those are days gone by, never to return.

I do not mind the sound from the first X session being muted/suspended when the other is active on the console. I'd rather like it that way. There is a bigger problem in that I use "fast user switch" to switch back to the fist X session, and the sound does not seem to follow the active X session.

Use case: I log in using KDM to lauch KDE. I lock the screen with KScreensaver My wife starts a new X session; KDM happily serves her a KDE display. She locks the screen, also using KScreensaver. I then reactivate my KDE session, and find that my sound system is not working.

There is then no sound until my wife logs out. This is not very satisfying.

I suppose this might be fixed with the proper setup, but I do not know how to do this. As I said, there is little use for simultaneous I/O from the different X sessions of the two (or more) users. My concern is to get sound working for the X session currently active on the console display.

I hope you can help me with this. I suppose pasuspender couldbi a way to go, but how do I set my sytem up for this to work seamlessly? I have not configured Konsole Kit or Udev in any particular way, but I believe I am up to the task if I get some instructions on the needed modifications neccessary.

Thank you in avance. ;)Frode Frode Severin Hatlevik

PS: If you can gife me som starting points for looking into the setup of ALSA to cater for H/W mixing I will be happy to persue this as a solution. I guess setting up Jackd as a system backend for pulse could be an option too? DS.

[coling]

I would look at the output from the ck-list-sessions command. It could be that KDE is not properly indicating who is active.

Also check the output of getfacl /dev/snd/* as this will show you which users have specific ACLs added for them. This user who is in the ACL should correspond to the 'active' user in the ck-list-sessions output.

If your card does not support h/w mixing then you should also ensure that none of your users are in the "audio" group (just type groups username to see. If they are in the audio group then this bypasses the ACL restrictions. Various scenarios can exist where a user switch even when users *are* in the audio group can work fine (i.e. when no user is currently playing sound and has released the sound device due to a five second timeout), but there will certainly be cases where this can mess things up.

See the notes on the wiki:KDE page which outlines how things should look for you under KDE and also mentions the gotcha of the audio group.

I see that I originally misread the bug report and the problem is not the general setup, but rather one of resuming playback after returning from a userswitch.

When this problem occurs, good debug output can be optained from pacmd list-sinks. This output will include the current "suspend status" and the "suspend reason" which can aid debugging.

[frodeseverin]

Thanks again for a prompt and informative response.

Simply removing the users from the audio group seems to have fixed the problem for me. To the best of my knowledge, this is not documented in the Debian wiki in any way. On the contrary, y the page for sound configuration on Debian (at http://wiki.debian.org/SoundConfiguration ) explicitly states that it is recommended to add all users to the "audio" group, and does not mention PulseAudio at all. I will see to it that this is corrected.

Moreover, I could not find any reference on the wiki:KDE page to the gotcha of the audio group. Did this fall out from the wiki in a recent update?

Thank you so much ;)Frode

[coling]

Replying to frodeseverin:

Thanks again for a prompt and informative response. Simply removing the users from the audio group seems to have fixed the problem for me.

Excellent. Thanks for spreading this information to the appropriate channels for your distro.

Moreover, I could not find any reference on the wiki:KDE page to the gotcha of the audio group. Did this fall out from the wiki in a recent update?

It's quite new yes. I wrote it up earlier this year while on the KDE Multimedia Sprint in Randa, Switzerland. I had it in my head that I had blogged about it (and thus syndicated to Planet KDE) at the time, but I don't see any links in the write ups I did. I'll probably do a little post to correct that and generally explain this kind of problem just for a little bit of wider publicity.

Cheers!

Col

[frodeseverin]

Well, fixing one problem sometimes creates another. This is the case here.

After removing all users from the "audio" group, the sound is following the active console session beautifully. But I am now unable to use my Logitech usb headset and the microphone on my Logitech usb webcam. This is sad, because the built-in microphone on my laptop is not very good...

Here is a listing of the /dev/snd directory:

ls -l /dev/snd totalt 0 drwxr-xr-x 2 root root 80 aug. 3 21:26 by-id drwxr-xr-x 2 root root 100 aug. 3 21:26 by-path crw-rw----+ 1 root audio 116, 12 aug. 3 20:07 controlC0 crw-rw---- 1 root audio 116, 5 aug. 3 21:26 controlC1 crw-rw---- 1 root audio 116, 15 aug. 3 21:26 controlC2 crw-rw----+ 1 root audio 116, 11 aug. 3 20:07 hwC0D0 crw-rw----+ 1 root audio 116, 10 aug. 3 20:07 hwC0D1 crw-rw----+ 1 root audio 116, 9 aug. 3 20:10 pcmC0D0c crw-rw----+ 1 root audio 116, 8 aug. 3 20:12 pcmC0D0p crw-rw----+ 1 root audio 116, 7 aug. 3 20:10 pcmC0D1p crw-rw----+ 1 root audio 116, 6 aug. 3 20:07 pcmC0D2c crw-rw---- 1 root audio 116, 4 aug. 3 21:26 pcmC1D0c crw-rw---- 1 root audio 116, 14 aug. 3 21:26 pcmC2D0c crw-rw---- 1 root audio 116, 13 aug. 3 21:26 pcmC2D0p crw-rw----+ 1 root audio 116, 3 aug. 3 20:07 seq crw-rw----+ 1 root audio 116, 2 aug. 3 20:07 timer

As I understand, the problem is the lack of a + sign after the octals for the file permissions. Theese device nodes are only present when I plug in my headset and webcam, and are thus the nodes in use for this hardware, right?

Now, how do I turn on ACL for devices using usb-snd-audio? I tried to search the Inernet, but I did not quite know which end to start in ...

My modules related to sound:

lsmod |grep snd snd_hda_codec_realtek 163214 1 snd_hda_intel 16703 2 snd_hda_codec 46002 2 snd_hda_codec_realtek,snd_hda_intel snd_usb_audio 50658 0 snd_pcm_oss 28671 0 snd_mixer_oss 10461 1 snd_pcm_oss snd_usb_lib 11156 1 snd_usb_audio snd_hwdep 4054 2 snd_hda_codec,snd_usb_audio snd_pcm 47214 4 snd_hda_intel,snd_hda_codec,snd_usb_audio,snd_pcm_oss snd_seq_midi 3576 0 snd_rawmidi 12505 2 snd_usb_lib,snd_seq_midi snd_seq_midi_event 3684 1 snd_seq_midi snd_seq 35463 2 snd_seq_midi,snd_seq_midi_event snd_timer 12258 2 snd_pcm,snd_seq snd_seq_device 3673 3 snd_seq_midi,snd_rawmidi,snd_seq snd 34363 16 snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_usb_audio,snd_pcm_oss,snd_mixer_oss,snd_hwdep,snd_pcm,snd_rawmidi,snd_seq,snd_timer,snd_seq_device snd_page_alloc 5045 2 snd_hda_intel,snd_pcm soundcore 3450 1 snd usbcore 98402 7 btusb,snd_usb_audio,snd_usb_lib,uvcvideo,uhci_hcd,ehci_hcd

I tried reading some of the filesl in /etc/udev/rules.d. I suppose this is where the solution lies, but udev rules seems to have a steep learning curve.

Best regards ;)Frode Frode Severin Hatlevik

PS: I hope you don't mind me reopening the bug all the time. DS.

[frodeseverin]

oops. I should have known to list things in literal mode by now. (Bushing)

Here we go again:

ls -l /dev/snd
totalt 0
drwxr-xr-x  2 root root       80 aug.   3 21:26 by-id
drwxr-xr-x  2 root root      100 aug.   3 21:26 by-path
crw-rw----+ 1 root audio 116, 12 aug.   3 20:07 controlC0
crw-rw----  1 root audio 116,  5 aug.   3 21:26 controlC1
crw-rw----  1 root audio 116, 15 aug.   3 21:26 controlC2
crw-rw----+ 1 root audio 116, 11 aug.   3 20:07 hwC0D0
crw-rw----+ 1 root audio 116, 10 aug.   3 20:07 hwC0D1
crw-rw----+ 1 root audio 116,  9 aug.   3 20:10 pcmC0D0c
crw-rw----+ 1 root audio 116,  8 aug.   3 20:12 pcmC0D0p
crw-rw----+ 1 root audio 116,  7 aug.   3 20:10 pcmC0D1p
crw-rw----+ 1 root audio 116,  6 aug.   3 20:07 pcmC0D2c
crw-rw----  1 root audio 116,  4 aug.   3 21:26 pcmC1D0c
crw-rw----  1 root audio 116, 14 aug.   3 21:26 pcmC2D0c
crw-rw----  1 root audio 116, 13 aug.   3 21:26 pcmC2D0p
crw-rw----+ 1 root audio 116,  3 aug.   3 20:07 seq
crw-rw----+ 1 root audio 116,  2 aug.   3 20:07 timer

and

lsmod |grep snd
snd_hda_codec_realtek   163214  1 
snd_hda_intel          16703  2 
snd_hda_codec          46002  2 snd_hda_codec_realtek,snd_hda_intel
snd_usb_audio          50658  0 
snd_pcm_oss            28671  0 
snd_mixer_oss          10461  1 snd_pcm_oss
snd_usb_lib            11156  1 snd_usb_audio
snd_hwdep               4054  2 snd_hda_codec,snd_usb_audio
snd_pcm                47214  4 snd_hda_intel,snd_hda_codec,snd_usb_audio,snd_pcm_oss
snd_seq_midi            3576  0 
snd_rawmidi            12505  2 snd_usb_lib,snd_seq_midi
snd_seq_midi_event      3684  1 snd_seq_midi
snd_seq                35463  2 snd_seq_midi,snd_seq_midi_event
snd_timer              12258  2 snd_pcm,snd_seq
snd_seq_device          3673  3 snd_seq_midi,snd_rawmidi,snd_seq
snd                    34363  16 snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_usb_audio,snd_pcm_oss,snd_mixer_oss,snd_hwdep,snd_pcm,snd_rawmidi,snd_seq,snd_timer,snd_seq_device
snd_page_alloc          5045  2 snd_hda_intel,snd_pcm
soundcore               3450  1 snd
usbcore                98402  7 btusb,snd_usb_audio,snd_usb_lib,uvcvideo,uhci_hcd,ehci_hcd

I will hopefully learn to use the "Preview" button more in the future.

Regards ;)Frode

[coling]

Damn, I wrote a reply to this last night but must have closed the tab before hitting reply :(

Re: reopening the ticket, I'd rather it was left closed, mainly due to the fact that it's not a PA bug but a configuration or system setup issue that is ultimately exposed and visible in PA. So from the perspective of tracking real issues that we need to fix, it's better if it stays closed.

But in the spirit of helping people with this issue, (both yourself and anyone else who stumbles upon this ticket in the future) I'm happy to continue trying to advise as best I can (tho' will admit that my knowledge on exactly how the lower levels are glued together is now reaching it's limits!)

Essentially, the ACLs are written by Udev via the program udev-acl. But I'm not sure how exactly this is triggered. In theory when you plug the device in, it should be triggered via some kind of event in udev (after consulting CK to see who is active). If, however, active session changes (e.g. changing to tty1 and back again), the ACLs are written by some kind of callout from consolekit (I think it's /usr/lib/ConsoleKit/run-seat.d/udev-acl.ck). I think the udev part of it is configured via /lib/udev/rules.d/60-persistent-alsa.rules.

Like I say, I'm not totally sure how this is all glued together, but it's certainly a problem below PA. All I can say for certain is that when I plug in USB stuff on my system it all works nicely :s

[coling]

I should also have said above (but forgot!) that our mailing list is probably much better for helping to debug this issue. There are more people who read the list than who look at bug reports so it's much more likely to result in a prompt resolution.

[frodeseverin]

There is now a bug report in the Debian BTS on this issue. It turns out the package maintainer had made a small mistakte when replacing some rules in the /lib/udev/rules.d/70-acl.rules file. These sill hopefully be updated before Squeeze releases.

The bug report can be read here: /lib/udev/rules.d/70-acl.rules

To make a long story short, I needed to make a rule file containing theese rules

# Turn on access control lists for all sound devices
SUBSYSTEM=="sound", ENV{ACL_MANAGE}="1"
SUBSYSTEM=="input", SUBSYSTEMS=="sound", ENV{ACL_MANAGE}="1"

I put them in /etc/rules.d/60-sound.rules

This solution will only fix ACLs for the sound devices, to fix ACLs for the whole system, you should edit the file /lib/udev/rules.d/70-acl.rules as described in the Debian bug report.

;)Frode

[frodeseverin]

Silly me.

I forgot to include a reference to the Debian bug report. Here it is:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593881

;)Frode