Bug 489048

That doesn't make a lot of sense.

Do you see the device being found in the gnome-volume-control logs? Does pulseaudio show that the new device was added when you plug it in?

Hard for me to see a pattern as well... my impression was that sometimes the detection of newly connected hardware takes a bit longer and if you open the preferences before the detection is done, the device will not show up. But maybe it's just that sometimes PulseAudio (or something else) just doesn't detect the device correctly? Also, if the device does not show up, disconnecting/reconnecting does not help, it will only show up if the volume applet is restarted it seems.

Could you please get actual debug output from pulseaudio and gnome-volume-control when reproducing the problem?

If the device fails to show up, also check your kernel logs (in dmesg), and lshal whether the device showed up lower down the levels.

For pulseaudio:
pulseaudio -k ; pulseaudio --log-level=3
For gnome-volume-control:
gnome-volume-control --debug

Thanks.

Ok this is weird. I was so sure this was related to the volume applet/mixer somehow but looks like you're right and it's further down the stack.

I'm not sure if this is a DBus/HAL/Pulse/other bug though. I'm going to attach two logs. Once where it worked totally fine after boot, and one where the headset was only detected after unpluggung and replugging. Feel free to re-assign or tell me where to file a new bug for this... thanks.

Created attachment 335097 [details]
Log1: working

Created attachment 335098 [details]
Log2: fail, then work on 2nd try

Looks like pulseaudio is suspending the device.

Nah, this is unrelated to suspending.

The interesting part is the "E: module-alsa-card.c: Card '1' doesn't exist: Permission denied"

Apparently HAL tells us that there is a new device before actually adjusting the ACLs on the device file. This is a race in HAL and needs to be fixed there.

I'm not sure HAL has any guarantee that ACL's are set before announcing the device add. David?

I'm not sure HAL has any guarantee that ACL's are set before announcing the device add. David?

It's actually not about the DeviceAdded signal. When that fails PA is fine with that. However the ACLAdded signal matters. When that signal is triggered PA will try again and expects ACLs to be set up properly. And obviously it would be a bug in HAL if it would send this out without having adjusted the ACLs?

Maybe the bug here is actually that HAL does not send out the ACLAdded signal at all?

Let me rephrase this: PA looks for both the ACLAdded and the DeviceAdded signal. On either one it will try to reopen the device. If one of them fails due to permission problems then hopefully the other one works.

*** Bug 491706 has been marked as a duplicate of this bug. ***

As it seems when a new device is plugged in HAL will (at least sometimes) send out DeviceAdded and only then fix up the ACLs. And it won't send ACLAdded for that device afterwards. So clients have no clue when the device is actually usable.

HAL should not send DeviceAdded before ACLs are properly set up.

/me is tempted to raise this to a blocker bug.

*** Bug 493775 has been marked as a duplicate of this bug. ***

Is there a work-around for this bug, so I can get sound in F11?  Should I restart pulseaudio whenever a new device is inserted?

It seems like the other dups of this bug were USB devices, but I see this with
my built-in snd_hda_intel on a Dell Precision M4400:

I: main.c: Running in system mode: yes
I: main.c: Fresh high-resolution timers available! Bon appetit!
D: rtclock.c: Timer slack is set to 50 us.
D: memblock.c: Using private memory pool with 1024 slots of size 64.0 KiB each, total size is 64.0 MiB, maximum usable slot size is 65472
D: cli-command.c: Checking for existance of '/usr/lib64/pulse-0.9.15/modules/module-hal-detect.so': success
D: dbus-util.c: Successfully connected to D-Bus system bus 02ab72393ece651a05ef16244a1f31ca as :1.94
D: module-hal-detect.c: Not loaded device /org/freedesktop/Hal/devices/computer_alsa_timer
D: module-hal-detect.c: Not loaded device /org/freedesktop/Hal/devices/pci_8086_293e_sound_card_0_alsa_playback_0
D: module-hal-detect.c: Not loaded device /org/freedesktop/Hal/devices/pci_8086_293e_sound_card_0_alsa_capture_0
D: module-hal-detect.c: Not loaded device /org/freedesktop/Hal/devices/pci_8086_293e_sound_card_0_alsa_hw_specific_0
D: module-hal-detect.c: Loading module-alsa-card with arguments 'device_id=0 name=pci_8086_293e_sound_card_0 card_name=alsa_card.pci_8086_293e_sound_card_0 tsched=1'
E: module-alsa-card.c: Card '0' doesn't exist: Permission denied
E: module.c: Failed to load  module "module-alsa-card" (argument: "device_id=0 name=pci_8086_293e_sound_card_0 card_name=alsa_card.pci_8086_293e_sound_card_0 tsched=1"): initialization failed.

This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

(In reply to comment #17)
> It seems like the other dups of this bug were USB devices, but I see this with
> my built-in snd_hda_intel on a Dell Precision M4400:

> E: module-alsa-card.c: Card '0' doesn't exist: Permission denied
> E: module.c: Failed to load  module "module-alsa-card" (argument: "device_id=0
> name=pci_8086_293e_sound_card_0 card_name=alsa_card.pci_8086_293e_sound_card_0
> tsched=1"): initialization failed.  

I got on my built-in snd_hda_intel:
lsmod | grep intel
snd_intel8x0           27412  3
snd_intel8x0m          12892  5
snd_ac97_codec         91488  2 snd_intel8x0,snd_intel8x0m
snd_pcm                62476  5 snd_intel8x0,snd_intel8x0m,snd_ac97_codec
snd                    48764  19 snd_intel8x0,snd_intel8x0m,snd_ac97_codec,snd_pcm,snd_timer
snd_page_alloc          7592  3 snd_intel8x0,snd_intel8x0m,snd_pcm

Jul  4 09:37:00 segulix pulseaudio[2433]: module-alsa-card.c: Failed to find a working profile.
Jul  4 09:37:00 segulix pulseaudio[2433]: module.c: Failed to load  module "module-alsa-card" (argument: "device_id=1 name=pci_8086_266d_sound_card_0 card_name=alsa_card.pci_8086_266d_sound_card_0 tsched=1"): initialization failed.

I had to

 # chmod 666 /dev/snd/*

to get sound to work. I still get the

  E: polkit.c: Cannot set UID on session object.

error.

I am attaching two files:

  1. Output of 'strace -fFo /tmp/pulseaudio.log pulseaudio -v' followed by 'pulseaudio -k' before changing the permissions of /dev/snd/*.
  2. Output of the same two commands after changing the permissions of /dev/snd/*.

Created attachment 351343 [details]
strace of 'pulseaudio -v' before changing persmissions of /dev/snd/*

Created attachment 351344 [details]
strace of 'pulseaudio -v' after changing persmissions of /dev/snd/*

(In reply to comment #20)
> I had to
> 
>  # chmod 666 /dev/snd/*
> 
> to get sound to work. I still get the
> 
>   E: polkit.c: Cannot set UID on session object.
> 
> error.
> 
> I am attaching two files:
> 
>   1. Output of 'strace -fFo /tmp/pulseaudio.log pulseaudio -v' followed by
> 'pulseaudio -k' before changing the permissions of /dev/snd/*.
>   2. Output of the same two commands after changing the permissions of
> /dev/snd/*.  

I forgot to mention that I had added myself (unprivileged) to audio, pulse-rt and pulse-access before running these commands. As expected, removing myself from these groups did not prevent sound from working after I changed the permissions on /dev/snd*.

(In reply to comment #19)
I forgot tell that I always have SELinux disable.

SELinux:  Disabled at runtime.
SELinux:  Unregistering netfilter hooks

(In reply to comment #14)
> As it seems when a new device is plugged in HAL will (at least sometimes) send
> out DeviceAdded and only then fix up the ACLs. And it won't send ACLAdded for
> that device afterwards. So clients have no clue when the device is actually
> usable.
> 
> HAL should not send DeviceAdded before ACLs are properly set up.
> 
> /me is tempted to raise this to a blocker bug.  

I attempted to chase this for a little while before I realized I was in too deep, but, if I understand what I saw, it looks like ACL's are set with a call to hal-acl-tool as a 'callout' by hald.  What I wasn't able to figure out was if the callout runner waits for the callout process completion.  If not, that could potentially cause your race.

Should this be raised upstream?

This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.