Following on from another thread (in which gdm seemed to be stealing sound-ability from users), I've updated to the latest pulseuadio RPMs from updates-testing, and by situation seems to have gotten worse.
(NB: this is fedora 12; it was all working swimmingly in fedora 10, from which I upgraded a few weeks back).
After a reboot, I log in. I have sound, no problems AFAICT. If I then switch users for my wife to log in (while I remain logged in), she gets no sound at all.
A quick investigation shows that her PA config. has dropped back to a 'dummy' output device. I can switch back to my login and hear my sound again, but nothing i can do can get hers working again.
I am utterly at a loss as to how to debug/diagnose pulseaudio, it's gone well beyond my ken; can anyone help point me in the right direction?
Here's the output of 'pulseaudio -vvv' :
https://www.fnxweb.co.uk/fnx/data/pa.out
And the two log files generated by system-config-sound (or whatever it's called) run (as root) whilst logged in as my wife:
https://www.fnxweb.co.uk/fnx/data/scsconfig.log https://www.fnxweb.co.uk/fnx/data/scsrun.log
I did notice some failed device access in the pa.out file, namely "/dev/snd/pcmC7D0p", but that device isn't on my system. I have:
drwxr-xr-x 2 root root 80 2010-03-07 16:41 by-id/ drwxr-xr-x 2 root root 100 2010-03-07 16:41 by-path/ crw-rw----+ 1 root audio 116, 10 2010-03-07 16:41 controlC0 crw-rw----+ 1 root audio 116, 14 2010-03-07 16:41 controlC1 crw-rw----+ 1 root audio 116, 12 2010-03-07 16:41 controlC7 crw-rw----+ 1 root audio 116, 9 2010-03-07 16:43 pcmC0D0c crw-rw----+ 1 root audio 116, 8 2010-03-07 16:45 pcmC0D0p crw-rw----+ 1 root audio 116, 7 2010-03-07 16:41 pcmC0D1c crw-rw----+ 1 root audio 116, 6 2010-03-07 16:41 pcmC0D2c crw-rw----+ 1 root audio 116, 5 2010-03-07 16:41 pcmC0D3c crw-rw----+ 1 root audio 116, 4 2010-03-07 16:43 pcmC0D4p crw-rw----+ 1 root audio 116, 13 2010-03-07 16:53 pcmC1D0c crw-rw----+ 1 root audio 116, 11 2010-03-07 16:53 pcmC7D0c crw-rw----+ 1 root audio 116, 3 2010-03-07 16:41 seq crw-rw----+ 1 root audio 116, 2 2010-03-07 16:41 timer
On 03/08/2010 06:48 AM, Neil Bird wrote:
Following on from another thread (in which gdm seemed to be stealing sound-ability from users), I've updated to the latest pulseuadio RPMs from updates-testing, and by situation seems to have gotten worse.
(NB: this is fedora 12; it was all working swimmingly in fedora 10, from which I upgraded a few weeks back).
After a reboot, I log in. I have sound, no problems AFAICT. If I then switch users for my wife to log in (while I remain logged in), she gets no sound at all.
A quick investigation shows that her PA config. has dropped back to a 'dummy' output device. I can switch back to my login and hear my sound again, but nothing i can do can get hers working again.
I am utterly at a loss as to how to debug/diagnose pulseaudio, it's gone well beyond my ken; can anyone help point me in the right direction?
Before you do a lot of debugging, your system is working properly with the default setup. When a user log on in the GUI mode, a PA daemon is started for them. As soon as you play something through PA, it grabs the ALSA device it is configured to use. If I remember correctly, after so long with no output, it releases it again. The problem when you change logins, the new one also starts its own PA daemon. If there isn't a sound card available, it is stuck using the dummy one.
One way to get around this is to run a system wide PA daemon. But make sure you understand the security risk of doing so. (They are pointed out in the docs.)
If my memory about PA releasing the sound card, you may be able to work around it by tweeking the timeout setting, and making sure you do not get any system sounds when changing users.
Mikkel
Around about 08/03/10 17:24, Mikkel typed ...
Before you do a lot of debugging, your system is working properly with the default setup. <snip one PA at a time>
I don't fully understand this; with F10, I never had any problems with PAS and multiple users, to the degree that if my wife was playing music I could switch back to my login, have sounds myself and then switch back and her music would start back up.
Maybe I was just always lucky with timings and logged her in after my PA had timed out, but that doesn't feel right.
One way to get around this is to run a system wide PA daemon. But make sure you understand the security risk of doing so. (They are pointed out in the docs.)
OK, thanks, I'll read up on that. Although I'm suspicious that I've just disabled gdm sound because *it* was hogging the sound and locking up users logins when they tried to sound out, and that sounds a bit like having a system-wide PA set up.
If my memory about PA releasing the sound card, you may be able to work around it by tweeking the timeout setting, and making sure you do not get any system sounds when changing users.
I'll look at timing settings as well, thanks.