Only one user gets sound with privilege "Use audio devices"

Please un-assign and comment if you can't address this.

I have this bug too, now. In Karmic, this was working (being able to switch users and have it mute sound. But now I see the symptoms as above.

Let me know what info you need provided.

Please check /var/log/user.log for "x11" messages from pulseaudio.

On Oct 13, 2009 10:00 AM, "Tony Lewis" <email address hidden> wrote:

I have this bug too, now. In Karmic, this was working (being able to
switch users and have it mute sound. But now I see the symptoms as
above.

Let me know what info you need provided.

-- [Karmic] Only one user has sound; no hw shows in Sound Preferences
https://bugs.launchpad.net/b...

Status in “alsa-driver” package in Ubuntu: New Bug description: Steps to
reproduce the bugs: 1. Cre...
(Note: this is not a multi-seat setup, but a single seat computer with
multiple user accounts.
See attached screenshots for details).

Other example: a first user has a session open, playing sound with Amarok
(paused) on a Gnome desktop.

The second user chose "Switch user" in FUSA, then login. The new session
doesn't have any sound, and...

I can't reproduce this problem. If I create a new account and then switch to it, it gets control of the sound device; if I leave sound playing in this user's session, the sound terminates as soon as 'Switch User' is selected again.

Please provide the information requested by Daniel in the previous comment.

Here's the whole content of /var/log/user.log on a Karmic Beta LiveCD, when creating a new user called user1, then playing an audio file with Totem as Live Session user, then switching to user1 - sound from Live Session user stops at gdm login - then playing an audio file with Totem as user1m switching back to LS user, audio from user1 still plays, and file previously playing in LS user is blocked with Totem unresponding, then when file from user1 finishes playing Totem in LS user restarts playing when it had stopped.

Note that I've been able to reproduce the bug on Intel ICH10 EP45 DS4 motherboard, on a Pentium 4 laptop and on an Athlon64 motherboard, all using onboard audio, With either Live CD sessions or from scratch clean installs updated to this day, and since I started testing Karmic at Alpha4 release day.

/var/log/user.log :
Oct 19 01:44:34 ubuntu pulseaudio[2978]: reserve-wrap.c: Failed to create watch on device 'Audio0': Input/output error
Oct 19 01:44:34 ubuntu pulseaudio[2978]: reserve-wrap.c: Failed to create watch on device 'Audio0': Input/output error
Oct 19 01:44:34 ubuntu pulseaudio[2978]: main.c: Failed to acquire org.pulseaudio.Server: org.freedesktop.DBus.Error.Disconnected: Connection is closed
Oct 18 23:52:12 ubuntu pulseaudio[3066]: ratelimit.c: 261 events suppressed
Oct 18 23:53:35 ubuntu pulseaudio[3066]: alsa-sink.c: Error opening PCM device front:0: Device or resource busy
Oct 18 23:53:35 ubuntu pulseaudio[3066]: alsa-sink.c: Error opening PCM device front:0: Device or resource busy
Oct 18 23:53:41 ubuntu pulseaudio[3066]: alsa-sink.c: Error opening PCM device front:0: Device or resource busy
Oct 18 23:53:41 ubuntu pulseaudio[3066]: alsa-sink.c: Error opening PCM device front:0: Device or resource busy
Oct 18 23:53:43 ubuntu pulseaudio[3066]: alsa-sink.c: Error opening PCM device front:0: Device or resource busy
Oct 18 23:53:44 ubuntu pulseaudio[3066]: alsa-sink.c: Error opening PCM device front:0: Device or resource busy
Oct 18 23:53:54 ubuntu pulseaudio[3066]: alsa-sink.c: Error opening PCM device front:0: Device or resource busy
Oct 18 23:54:06 ubuntu pulseaudio[3066]: alsa-sink.c: Error opening PCM device front:0: Device or resource busy
Oct 18 23:54:45 ubuntu pulseaudio[3789]: ratelimit.c: 127 events suppressed
Oct 18 23:54:51 ubuntu pulseaudio[3066]: alsa-sink.c: Error opening PCM device front:0: Device or resource busy
Oct 18 23:58:09 ubuntu pulseaudio[3066]: alsa-sink.c: Error opening PCM device front:0: Device or resource busy
Oct 19 00:00:45 ubuntu pulseaudio[3066]: ratelimit.c: 102 events suppressed

And here's the log on an up-to-date Karmic install, same HW, but French locale, but the meaning is the same as above:
Oct 18 12:43:33 desktop bonobo-activation-server (t3g-32235): could not associate with desktop session: Failed to connect to socket /tmp/dbus-bvz4h7STED: Connexion refusée
Oct 18 12:43:38 desktop pulseaudio[32370]: pid.c: Stale PID file, overwriting.
Oct 18 22:51:19 desktop pulseaudio[3463]: alsa-sink.c: Error opening PCM device front:0: Périphérique ou ressource occupé
Oct 18 22:51:19 desktop pulseaudio[3463]: alsa-sink.c: Error opening PCM device front:0: Périphérique ou ressource occupé
Oct 18 22:51:19 desktop pulseaudio[3463]: alsa-sink.c: Error opening PCM device front:0: Périphérique ou ressource occupé
Oct 18 22:52:14 desktop pulseaudio[3463]: alsa-sink.c: Error opening PCM device front:0: Périphérique ou ressource occupé
Oct 18 22:52:14 desktop pulseaudio[3463]: alsa-sink.c: Error opening PCM device front:0: Périphérique ou ressource occupé
Oct 18 22:52:40 desktop pulseaudio[3463]: alsa-sink.c: Error opening PCM device front:0: Périphérique ou ressource occupé
Oct 18 22:52:40 desktop pulseaudio[3463]: alsa-sink.c: Error opening PCM device front:0: Périphérique ou ressource occupé
Oct 18 22:53:01 desktop pulseaudio[3463]: alsa-sink.c: Error opening PCM device front:0: Périphérique ou ressource occupé
Oct 18 22:53:01 desktop pulseaudio[3463]: alsa-sink.c: Error opening PCM device front:0: Périphérique ou ressource occupé
Oct 18 22:53:07 desktop pulseaudio[3463]: alsa-sink.c: Error opening PCM device front:0: Périphérique ou ressource occupé
Oct 18 22:53:16 desktop pulseaudio[3463]: alsa-sink.c: Error opening PCM device front:0: Périphérique ou ressource occupé
Oct 18 22:53:55 desktop pulseaudio[3463]: alsa-sink.c: Error opening PCM device front:0: Périphérique ou ressource occupé
Oct 18 22:53:55 desktop pulseaudio[3463]: alsa-sink.c: Error opening PCM device front:0: Périphérique ou ressource occupé
Oct 18 22:53:59 desktop pulseaudio[3463]: alsa-sink.c: Error opening PCM device front:0: Périphérique ou ressource occupé
Oct 18 22:53:59 desktop pulseaudio[3463]: alsa-sink.c: Error opening PCM device front:0: Périphérique ou ressource occupé
Oct 18 22:54:10 desktop pulseaudio[3463]: alsa-sink.c: Error opening PCM device front:0: Périphérique ou ressource occupé
Oct 18 22:54:10 desktop pulseaudio[3463]: alsa-sink.c: Error opening PCM device front:0: Périphérique ou ressource occupé
Oct 18 22:58:29 desktop pulseaudio[16510]: alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write!
Oct 18 22:58:29 desktop pulseaudio[16510]: alsa-sink.c: Most likely this is a bug in the ALSA driver 'snd_hda_intel'. Please report this issue to the ALSA developers.
Oct 18 22:58:29 desktop pulseaudio[16510]: alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.
Oct 18 23:09:46 desktop pulseaudio[3463]: ratelimit.c: 1329 events suppressed
Oct 18 23:09:52 desktop pulseaudio[3463]: ratelimit.c: 1 events suppressed
Oct 18 23:36:45 desktop pulseaudio[3463]: ratelimit.c: 31 events suppressed
Oct 18 23:37:06 desktop pulseaudio[3463]: ra...

I can confirm this, the only hardware shown is a virtual "dummy output". /var/log/user.log shows only "Oct 24 23:13:00 ubuntu pulseaudio[4470]: pid.c: Daemon already running." because I tried to run pulse-session manually.

If I configure gstreamer to use ALSA, I can select a hardware device with analog output (as opposed to digital) and the test works. Also, sound worked while running the live CD but about 99 packages have been updated since.

I have the same problem in Toshiba Satellite laptop.

It affects me too. When I installed Karmic sound worked as expected. Today I realized it stopped working... after a few upgrades...

If/when reproducible, please see https://wiki.ubuntu.com/PulseAudio/Log

Just adding that this is functionality that I would like to happen. I don't normally get this behaviour on Karmic, only rarely. However, I want music to continue playing when switching users. I shall attempt a Pulseaudio log if it happens to me again.

I'm adding verbose log files:

pulseverbose-no-xsmp.log - I just run pulseaudio by hand as described in https://wiki.ubuntu.com/PulseAudio/Log
pulseverbose.log - I run pulseaudio as before, but I loaded up module-x11-xsmp by issuing: pactl load-module module-x11-xsmp

While plaing music (rhythmbox) I switched to another user. The music continues and the user swiched to was unable to play any sounds.

On Wed, Nov 18, 2009 at 2:16 PM, Igor Wojnicki <email address hidden> wrote:
> While plaing music (rhythmbox) I switched to another user. The music
> continues and the user swiched to was unable to play any sounds.
>
> ** Attachment added: "pulseverbose-no-xsmp.log"
>   http://launchpadlibrarian.net/35831642/pulseverbose-no-xsmp.log

Note that http://bazaar.launchpad.net/~crimsun/pulseaudio/trunk/annotate/head%3A/src/daemon/start-pulseaudio-x11.in
shows that the module is loaded if $SESSION_MANAGER is not an empty
string.

In Lucid, the only change to this file is to load x11-bell; see
http://bazaar.launchpad.net/%7Eubuntu-core-dev/pulseaudio/ubuntu/revision/213/debian/patches/0057-load-module-x11-bell.patch

Daniel. I'm not sure if this is about xsmp module or not. My point is that pulseaudio does not work as it suppose to. I just provided the log file as requested, figuring out that it could be beneficial to run pulseaudio with and without the xsmp module loaded.

By the way does it work properly in Lucid?

Isn't this bug related to https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/213149

I guess It might be a 'desired' behavior now (I mean not muting audio while switching users).

I was browsing consolekit and policykit documentation and I was unable to find what to change to configure this behavior to my liking :(

I've just found out that the sound muting upon switching users wah actually provided by HAL.

ConsoleKit generates event (user/console switch) it goes through the PolicyKit and then reaches HAL which does sth. to the pulseaudio/audio_device/i_dont_know_what_else which stops the audio.

Since ubuntu 9.10 switched to udev (dumping HAL) this functionality is not longer available.... perhaps it is possible to do the same thig with udev but i'm not sure yet.

I'm having the same problem. /var/log/user.log output looks the same as already posted.

   I am having this same problem. Unfortunately for me, this exact feature (being able to have multiple users logged in on different consoles, with independent sound) is one of the primary reasons I switched from OpenSuse to Ubuntu last year. OpenSuse handled this usage of the system very badly. And now, even more unfortunately, I've upgraded several machines to karmic koala, and this super important feature is no longer working on those machines. I could have stuck with OpenSuse and been just as displeased, rather than putting in extra effort to switch to Ubuntu, only to have the most attractive feature I was using removed in the new release.
   I use the multiple console feature to log into different opensim and second life servers. The separate users need their separate sound support working, or this simply cannot be done properly. Only the first user gets sound with the current bug, and that sound support even stops working after a few switches back and forth to different users. This is the kind of bad implementation I'd expect from Microsoft, not Ubuntu.
   Why switch to udev if HAL provided more features? Was that considered before the switch? It also makes this bug sound like we're all hosed for the long term, since a change to a much lower level component (udev) could take months and months, if it's even considered a priority by the udev people. I predict the new year will come without a fix for this being available. I am sad, but I bet the prediction is sound.
   Until this is fixed, I can't upgrade any more machines to karmic koala. Can i "upgrade" to the prior version and get my working OS, intrepid ibex, back? I have not seen any kind of capability to do that. So, now I'm definitely displeased that I upgraded. Every other ubuntu upgrade (I switched last year, but have had a couple ubuntu machines for a few years) I've done was a breeze, but not this one.

ahem, sorry for my emotional outburst, but especially for appearing like an idiot by identifying ibex as the previous release rather than jackalope.

This is probably my biggest gripe with Ubuntu at this point. I switched all my home machines to Ubuntu, and my wife has been mostly okay with it, but she's had a few gripes...the fact that sound wasn't working for her was a big one. My workaround has been to make sure that her account is logged in first so that it can grab the sound device, then I can log myself in...but it's a true pita that I can't get any sound for my user as well. I really don't care so much about the "sound keeps playing even when user not active" vs "sound only plays for currently active user" (although I think it should be configurable), but "sound only works for one user period" is a non-starter.

@eyrieowl
That's almost certainly a localised configuration issue. Do you have
a verbose PA log (https://wiki.ubuntu.com/PulseAudio/Log) so we can
inspect the consolekit module loading?

Daniel T Chen, I've been seeing this problem for almost 3 months on all machines I've installed Karmic under a French locale, including both Intel and Amd hardware. I thought I had provided everything, but in some of your posts it's hard to figure out who they're addressed to. If there's anything missing in the logs I provided at the time I filled out the report, could you please point it out to me?

Alternatively, you could just reproduce it yourself by booting the Karmic Live CD under a French locale, then installing under that locale, since I can't really imagine how it is hardware related when the issue is there all the time for me.

What about Igor Wojnicki's comment on post #22 - is it completely off-base?

Daniel T Chen, I've got en_US.UTF-8 install - which I guess is quite default and the problem still exists there. I provided PulseAudio verbose output as requested (see #17, #18) but if there is anything else I can upload to have this bug resolved I would gladly do that. I can also investigate, or run tests or whatever, just If you could point me in a right direction, or be more specific on what to do (or where to look) in order to resolve the problem, please?

I agree that this feature/functionality is controversial. There are some cases it is desired while there are others that it is not. In 9.04 there was a choice, it could be configured either way. But 9.10 doesn't give that opportunity. So my question is: does the sound work this way on purpose or is it a bug? I'm quite confused right now. Could one of the maintainers elaborate on it please?

@Daniel, perhaps it is...I'll get the log for you (can't reboot at the moment, trying to get some work done). However, it's the EXACT same issue that has been described by others here who have provided verbose logs and for whom, so far as I can tell, there has been no explanation other than the one provided by Igor that it is HAL which may be defective by design. To wit, the first user to log in sees the audio device under Hardware in Sound Preferences; any other user who subsequently logs in while the first user is still logged in sees no hardware device for audio, and thus there is no sound for those users. If the first user logs out, the audio device is freed up and can be grabbed by another user when "switched" to. One of two things *should* be taking place and isn't: either the audio device should be freed up when a user switch occurs, or the audio device should be always available to all users. The current behaviour where it seems the first user gets an exclusive lock on the device is not correct.

I'm seeing (hearing?) this problem as well on a 64 bit karmic on 2,1 MacBook.

The "Sound Preferences -> Output" shows "Internal Audio Analog Surround 4.0" on user 2, as it is supposed to.
But user 2 does not have sound.

This is massively FRUSTRATING! Every time my wife uses our PC she finds that she can't play any sound. She has to reboot the PC which is a pain and means that I loose anything I had open. I've told her to do this because quite rightly, she shouldn't have to run scripts etc just to play some music! Apple Mac, none of these problems, Windows XP/Vista/7 non of these problems. Why can't Ubuntu get these things right before it changes the login screen and various other nice changes. There's an update every 6 months and updates constantly but still this sound problems persist or re-emerge. i'm on Karmic btw.

Please, Canonical, sort this one out, it's embarrassing for your ambassadors when their King wets it's self like a new born.

Jack

Mr. Ubu: I'm also frustrated by this bug, but I'm using a workaround instead of rebooting: I change the the profile to 'Off' on the first user (mine), and then the second user (my wife) can play sounds. No need to reboot.

Haggai

While trying to find a solution for this issue I stumbled upon this, quote:

"A bit of functionality is (temporarily) lost however: in the udev
world there is no replacement for HAL's session switching/ACL
management yet. The new code in PA however is written in a way that
should just work when we add this to udev later on. However the
lacking ACL handling makes things very racy right now and you might
need to add yourself to "audio" group, as a temporary workaround. We
mostly figured out how session switching/ACL management should be
working, it's just a matter that Jon and Kay need to implement that."

I found it at: https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-June/004103.html

It's a bit old (June 2009), and I'm not sure if this still applies to the udev release in Karmic. But if it does than not much can be done now. It would just point out that dropping HAL was premature then.

I would kindly urge the package maintainer to comment on this issue, please. And state whether there is anything that can be done to solve this annoyance

A comment to the "add yourself to audio group, as temporary workaround". Both users of this computer are members of the "audio" group, but only one has a sound output device listed in the sound preferences dialog.

/var/log/user.log also has several error messages from pulseaudio, for example "pulseaudio[6227]: module-x11-xsmp.c: X11 session manager not running."

Martin, what happens after you use pactl to load module-x11-xsmp?

FWIW, I determined that, at least in my case, this was manifesting in conjunction with usage of VirtualBox or VMWare. When I have a VM open in one user, sound becomes inaccessible to the other user(s). However (generally) if I log both users in without opening a VM, sound remains available to both users. It seems that some programs are using PulseAudio in such a way that it is blocking the other user from having sound.

Some notes on usage: if both users are logged in and have sound, and one starts a VM, the other user will lose sound. However, once the VM is closed, the sound will be restored. If, however, one user logs in and opens a VM, and then the other user logs in, they won't show any sound device, and even if the other user closes the VM they will still not have sound unless they log out and back in.

I tried the different audio options in VirtualBox (alsa, pulseaudio, etc), and it didn't seem to matter, they all exhibited this behavior. So...hopefully that helps. I could see someone looking at this and saying it's not an audio problem, it's a VirtualBox/VMWare issue, but I disagree. The audio should not be so susceptible to 3rd party applications borking it.

eyrieowl, I don't use VMWare and still experience the bug. It happens when one user actually uses audio, then the other is not permitted to do so. It doesn't matter if it is a VMWare, which locks the audio output, or rhythmbox, or whatever else. If there is a process talking to the audio output, then upon user switch, the other user is prevented from accessing the output. So this is the pulseaudio issue - or actually pulseaudio/udev/policykit one.

Hi Igor. To clarify, I wasn't suggesting it was only a problem with VMWare/VirtualBox, but that that is how I have most consistently recreated the problem. The bug assignee still hasn't marked this as confirmed, so I was just trying to help provide them a pretty sure-fire (in my experience) way to recreate the issue. I don't believe it's a client program issue, but hopefully they can start to recreate the issue themselves and be able to diagnose it directly on their machines.

This still happens on Lucid installs from the daily images (the lastest I testing this was in the 2-24-10 image), with the Us English locale. I can reproduce it every time.

This is very frustrating when you have flash games that can make sound, and someone leaves a game open on their locked user. You pretty much have to be root to get past this, killing all the flash running on your computer.

It's a major audio regression since 9.04! If there is a developer or packager out there please help us with that! It's not only annoying but prevents Ubuntu to be used as multiuser/singleworkstation environment.

Erik B. Andersen statement about flash games is VERY VALID!!! -especially for regular users. eyrieowl also presented an important case (for business orientet guys)! Help! help!

If you don't have enough resources to investigate, say so please, and/or describe a possible direction which may lead to finding a solution - I'm sure there would be some volunteers to pursue this (including me). Please!

Please attach a verbose log (https://wiki.ubuntu.com/PulseAudio/Log) while running the latest version in Lucid. Please note that you need the latest daily-live. The version shipped in Alpha 3 is insufficient.

Ok, I followed the instructions on the wiki. I disabled autospawning for both users and then started pulseaudio as specified on both users. Then on user 1 I started playing a .ogg. Opened sound preferences and and verfied that the music player showed up. Switched to user 2. (Could still hear user 1 sound. Login was silent) Opened sound preferences and switched to the same out put device as user 1 (I have to sound output devices: headphones and internal sound card). Tried to play another song with totem. Totem opened, but wouldn't play. I could still hear user a sound. After awhile user 1 's song finished and user 2 's song started, and then eventually finished. Stopped both pulseaudio instances.

Ok, I think I figured out the difference between getting a dummy output or having the output there but not working for the second user.
If user 1 starts playing something before user 2 logs in an starts their client, then user 2 can't see (or select) the output in Sound Preferences (which usually would give them a dummy output if they have no other sound devices, right?). If both users have their pulseaudio going before one starts to play something, then user 2 can see the output device, but their sound applications can't play anthing.

I'll attach the logs.

Guys I found it!!! Here is the solution!

1st the lucid daily build (28.02.10) doesn't perform better than karmic, but it gave me some clues.
When it logged in (the daily build) as ubuntu I started rythmbox to play.
I added another user aa.
I switched to aa, and... the music stopped playing :)
then I started rhtythmox as aa, it plays nice.
Swithed back to ubuntu and.... bummer, aa music keeps playing....
So I added another user bb and repeated the procedure but swichinch between aa and bb. In either case whichever user starts the music first it gets access to the audio device and it's not willing to give it beack upon switching.
Why than ubuntu user behaves differently, giving back access to the audio device?
I checked permissions: System->User Settings->Advanced->User Priviledges.
It turns out that by default ubuntu DOES NOT have 'Use audio devices checked' hmmm interesting.
So I unchecked this option for both aa and bb users. Guess what It started working!

So I went back to karmic to investigate the user privileges there. ANd guess what, by default a desktop user has 'Use audio device' checked. So I unchecked it and... sound upon user switching started to work :)

Bottom line. If you want to have a user, which currently uses the display, to have access to the sound device with all the benefits from sound muting upon user switch, you need to uncheck 'Use audio devices' privileges for this user. As a matter of fact I unchecked it for all my users.

These privileges are very confusing then.
I guess their proper interpretation is that if:
- checked: the user locks the audio device as long as he wants, no sound switching upon user switching,
- unchecked: the user which currently uses the display has access to the audio device, sound switching takes place upon user switching.

Ant the last word. I think it is very sad what happens here. None of the developers/packagers could help the community with this problem. But the solution was there! It seems that this is a kind of undocumented feature nobody knows about. Isn't there something wrong with software/package care at ubuntu then?

Anyway, have fun with your audio now!

PS. I would like to make a motion to:

1. rename the property 'Use audio device' to 'Use audio device exclusively',
2. make it unchecked by default,
3. document it.

It would apply to users-admin application in gnome-system-tools.

PS2. Disabling 'Use audio device' removes the user from audio group. And since /dev/dsp is acl controlled, access to it is granted to the user which currently uses the display. I guess that the ACL magic is done by policykit/udev - but i'm not sure though.

So, to enable sound switching with user switching, just remove your users from audio group.

As per latest comments, this is not a pulseaudio bug.

I couldn't seem to get the fix mentioned to work with existing users on both karmic and lucid. It seems to work after a restart though. So I can confirm that the fix works, after a restart.

I second Igor Wojnicki 's suggestion, with one additional thing:either upgrade the setting to unchecked if it is checked, or ask the user about it.
I had trouble with this bug for a long time before I tried to file a bug about this and found this bug. So, I imagine lots of people who don't usually file bugs wouldn't know about the fix, and the bug would still affect them after the default was updated, because their settings, which didn't change from the default, wouldn't be changed to the new default, right?

Actually the problem is more general and it regards permissions to access certain devices (and files in /dev directory). Historically if a user needs access to particular device he is assigned to a group which group-owns the device file. It has worked for ages in the unix world i.e. access to an audio device, cdrom, cd burner etc.

This group based approach has several well known limitations. Now it seems that such an access is controlled by consolekit/policykit/udev, which makes some sense, at least because of the dynamic nature of /dev directory. The gnome-system-tools and especially users-admin seem not to know anything about acl. I'm not sure whether it's good or bad - it depends, espoecially that gnome is cross platform - on other systems /dev might be static or there might be no acl at all. So I guess it should be up to the ubuntu team to keep the group assignments and acl sane and well documented, and the entire mechanism clear. Unfortunatelly I haven't found any explanation of it :( in the documentation. Perhaps a good idea it is to start a thread about it in the ubuntu formums. However, in my opinion, such a big thing as device access policy should be officially documented - not reverse engineered!

Regarding the property 'Use audio device' and my motion (comment #48).

Giving it a second thought the rename might be unfortunate. Especially if one does not have consolekit installed.

If consolekit IS NOT installed than assigning a user to audio group makes an audio device accessible to him, which translates into 'Use audio device' property which does that (by the way it seems that all these properties translate into assigning the user to particular groups).

If console kit IS installed, than upon log in/user switching, it applies, through udev, acl to make /dev/{snd,audio,mixer) accessible by the user which logs in/is switched to. Than, assiginig a user to audio group doesn't make any sense and the name is misleading.

Bottomline. Since consolekit depends on ubuntu-dektop, which makes it default and necessary package for ubuntu, the best solution would be not to include a default desktop user in the audio group. It can be performed by altering the gnome user profiles in /etc/gnome-system-tools/users/profiles, see included attachment.

What about the user that is made when installing? Isn't that an administrator? I think we should make it so that the user that is created when you install works properly too. (I'm just not sure if it is based off the administrator profile. If it is, is it the right thing to make the administrator not part of the sound group by default?)

I (somewhat) know how to package, so I could(would like to) try to make a patch and debdiff for this, but before I do that, I want to make sure that we agree on what is the correct changes to make. (It would also be nice to have advice from someone who knows what implications this might have, like the package maintainer.)

Good point Erik. I'm not sure about that 'Administrator Profile' either - that's why I didn't propose to change it. But It seems to be reasonable to remove audio group from all three profiles.

I guess packaging is not a problem, committing the changes and making them to Lucid might be though. I already posted a question to gnome-system-tools maintainers: https://answers.launchpad.net/ubuntu/+source/gnome-system-tools/+question/103004
We'll see what they think about it.

Besides I posted the solution to the forum: http://ubuntuforums.org/showthread.php?t=1420051

The user created during install is not created via the GNOME tools, but via the low level command-line components to create users, so the first user should not be in the audio group.

Luke you're right. Fortunately ubiquity (which is the ubuntu installer) seems to work just fine - at least according to its changelog:

user-setup (1.27ubuntu1) karmic; urgency=low

  * Resynchronise with Debian. Remaining changes:
    - Add the initial user to the adm, dip, lpadmin, and sambashare groups
      too, and to the admin group if no root password is set. Do not add
      them to the audio, video, floppy, dip, netdev, powerdev, or scanner
      groups.
...
 -- Colin Watson <email address hidden> Wed, 24 Jun 2009 13:59:33 +0100

There are user default groups defined in d-i/source/user-setup/debian/user-setup-udeb.templates (see ubiquity sources) which match the changelog.

Hi Igor,

Thanks so much for this!

U-DA-MAN!

Igor Wojnicki wrote:
> Guys I found it!!! Here is the solution!
>
> 1st the lucid daily build (28.02.10) doesn't perform better than karmic, but it gave me some clues.
> When it logged in (the daily build) as ubuntu I started rythmbox to play.
> I added another user aa.
> I switched to aa, and... the music stopped playing :)
> then I started rhtythmox as aa, it plays nice.
> Swithed back to ubuntu and.... bummer, aa music keeps playing....
> So I added another user bb and repeated the procedure but swichinch between aa and bb. In either case whichever user starts the music first it gets access to the audio device and it's not willing to give it beack upon switching.
> Why than ubuntu user behaves differently, giving back access to the audio device?
> I checked permissions: System->User Settings->Advanced->User Priviledges.
> It turns out that by default ubuntu DOES NOT have 'Use audio devices checked' hmmm interesting.
> So I unchecked this option for both aa and bb users. Guess what It started working!
>
> So I went back to karmic to investigate the user privileges there. ANd
> guess what, by default a desktop user has 'Use audio device' checked. So
> I unchecked it and... sound upon user switching started to work :)
>
> Bottom line. If you want to have a user, which currently uses the
> display, to have access to the sound device with all the benefits from
> sound muting upon user switch, you need to uncheck 'Use audio devices'
> privileges for this user. As a matter of fact I unchecked it for all my
> users.
>
> These privileges are very confusing then.
> I guess their proper interpretation is that if:
> - checked: the user locks the audio device as long as he wants, no sound switching upon user switching,
> - unchecked: the user which currently uses the display has access to the audio device, sound switching takes place upon user switching.
>
> Ant the last word. I think it is very sad what happens here. None of the
> developers/packagers could help the community with this problem. But the
> solution was there! It seems that this is a kind of undocumented feature
> nobody knows about. Isn't there something wrong with software/package
> care at ubuntu then?
>
> Anyway, have fun with your audio now!
>

This bug was fixed in the package gnome-system-tools - 2.29.91-0ubuntu2

---------------
gnome-system-tools (2.29.91-0ubuntu2) lucid; urgency=low

  * debian/patches/26_user_profiles_conf.patch:
    - Don't add users to the audio group. This is consistent with
      user-setup and fixes an issue with sound device permissions when
      switching between users. Thanks to Igor Wojnicki for spotting
      this (LP: #433654)
 -- Chris Coulson <email address hidden> Sun, 07 Mar 2010 11:56:59 +0000

Chris: what about removing the 'audio' from from the system altogether? ATM we still show it as a privilege in the Advanced dialog, which can be misleading. Groups that aren't used shouldn't be created in the first place, and users-admin will then hide them.

Milan, that would be a very unwise thing to do for an LTS. Of particular import is the fact that not every Ubuntu derivative uses PulseAudio.

Milan, I think that removing audio group is not a good idea. There are at least 2 reasons.

1. It might affect a lot of system components at least udev, libmtp, alsa which might cause regressions.
2. It would prevent group based access control to the audio device - mind that /dev is dynamic, so configuring back /dev/dsp group owned by audio will not be that easy - i.e. this kind of access control is crucial if your box is used remotely as a juke box.

Mind you that I'd consider any device-kit privilege escalation implementation that isn't configured to support/use (be itself easily configurable by) standard unix user group memberships as a regression.

Instead pulling users from the audio group etc. to make user switching work, device-kit configuration needs to take user groups into account.

Well, the fact remains that this needs to be fixed! I messed up user switching because I innocently gave myself permission to merely "use" the sound card.....

Chauncellor: at least, if you were able to play with permissions, you should be able to find this bug report. With the new users-admin, it's harder to tweak fine-grained permissions, so hopefully nobody will do this anymore.

On the contrary, it's ridiculously easy to do. I admitted myself access to a friend's computer for shared access (both admins). Upon setting it up my profile, I glanced through the permissions and found that it would be worthwhile for me to have access to Video, Audio, etc. Thus, I checked them all, thinking it was neat that I can deny such things to users.

Well, I really appreciate the workaround proposed by Igor, great job, many thanks! At least it has made sound to work more predictable.
However, I believe the issue is broader than just playing with the "audio" group. Since it affects not 100% of users and some of them are used to hear sound without any problems regardless of logged in users. It should be a clear root cause stated by developers re: why this has happened.

I created a separate bug on the issue:

https://bugs.launchpad.net/ubuntu/+source/system-tools-backends/+bug/593110

No, that's really the same bug. users-admin shouldn't show that group at all since it's plainly broken. This behavior doesn't make sense. That's why I said we should remove the audio group, which would fix the bug for all people that were added to it without noticing.

If that doesn't seem right, let's remove the line from users-admin.

Apologies; I had thought that this bug was going in a different direction.

FYI, I just wrote a small wiki article about the audio group: https://wiki.ubuntu.com/Audio/TheAudioGroup

Good job David!!!

On Tue, Aug 24, 2010 at 10:16 AM, David Henningsson
<email address hidden> wrote:
> FYI, I just wrote a small wiki article about the audio group:
> https://wiki.ubuntu.com/Audio/TheAudioGroup

Perhaps the group description string should just be changed... easy fix. How about "Lock audio devices" or "Exclusively use audio devices"? Doesn't completely clear up the problem, but it sounds scarier than "Use audio devices".

@David.

Regarding renaming the group description take a look at my comment: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/433654/comments/53

Yeah, there's no point in renaming a broken group - just get rid of it. We've not found a valid case where people would like to be actually members of this group.

Here's a branch with a fix. Actually, I may sound silly, but I realized one interest of keeping the group visible, at least for Maverick: people that have checked the box will need it to get out of the group. Else, they would need to use the command line.

I've finally chosen "Lock audio devices for exclusive use", which sounds scary and accurate enough to me. We don't actually have to consider the case where ConsoleKit is not present, since the gnome-system-tools depend on
it via system-tools-backends and PolicyKit1. So it will always be installed when the GUI is available.

"Access audio hardware directly" might be a more accurate description, but I don't have a strong preference.

My vote would be for "Use audio devices while logged out". I think that's the most accurate description and it also conveys the fact that it's an obscure group that you don't need to be in.

Milan: it's absolutely not broken. Look at the exceptions under <https://wiki.ubuntu.com/Audio/TheAudioGroup>.

A rename is a good compromise. I think a good name could mitigate your concerns in comment 53, Igor.

About "Use audio devices while logged out", that's not really accurate because you still have to be logged in to use it, just not on the current console.

I was just about to upload this change before I realised that the string also needs to be translated, so we need a freeze exception for this whilst we're in UIF anyway (and I don't think that is likely in the same week we go in to final freeze)

See here for details: https://wiki.ubuntu.com/UserInterfaceFreeze

I updated to maveric, and despite both users not being in the audio group, I see that problem.

Then you have a different, unrelated bug. Please don't hijack well-understood bugs like that

@Chris Coulson, Sorry. I suspected that its polycikit now behaves the same bad way as it does if user is in audio group, if user is in the admin group, therefore I reported this here.
I now triaged this, and indeed its very different bug. Sorry!

Sorry for my english)
I take this bug after apti
timidity

Sorry for my english)
I take this bug after aptitude dist-upgrade around 2010-12.
my solution:

sudo aptitude purge timidity
sudo userdel timidity
sudo groupdel timidity
sudo reboot