After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 564311 - "Connection failed" when PA drops off
"Connection failed" when PA drops off
Status: RESOLVED FIXED
Product: gnome-media
Classification: Deprecated
Component: gnome-volume-control
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome media maintainers
gnome media maintainers
: 587231 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-12-12 21:06 UTC by Bastien Nocera
Modified: 2010-01-05 16:27 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Bug 564311 – "Connection failed" when PA drops off (11.83 KB, patch)
2009-06-14 22:12 UTC, Marc-Andre Lureau
committed Details | Review

Description Bastien Nocera 2008-12-12 21:06:10 UTC
If PA crashes (as it did on my machine), then the applet is unusable. It should retry connecting, and at least show through its interface that the connection has been broken.
Comment 1 Michael Monreal 2009-01-16 10:11:29 UTC
A probably related case: my pulse audio is started by gnome-session and it looks like pulse is not entirely "up" when gnome-volume-control-applet is started, so it does not see any sound hardware. In this case, I do not see any tray icon. I have to kill the applet process and start it again to get the tray icon to show up. So it would be nice if the running applet would detect new sound hardware that becomes available in pulse.
Comment 2 Chris Coulson 2009-01-26 08:36:48 UTC
What Michael describes seems to be happening to Ubuntu users too. The applet and Pulseaudio are both started in the same phase but Pulseaudio is not fully up by the time the applet loads.
Comment 3 Basil Mohamed Gohar 2009-05-07 06:32:17 UTC
I've experienced this issue using Fedora rawhide, as well.  If I restart pulseaudio, the volume control applet no longer does anything.  Any changes made to it are not kept, and it does not affect the volume at all.
Comment 4 Marc-Andre Lureau 2009-05-07 08:21:34 UTC
There is a new flag NOFAIL that will wait in connecting state until PulseAudio comes up on one of the buses.

However, the dialog would be insensitive during that time: is it really what we want?
Comment 5 Bastien Nocera 2009-05-07 16:12:15 UTC
(In reply to comment #4)
> There is a new flag NOFAIL that will wait in connecting state until PulseAudio
> comes up on one of the buses.
> 
> However, the dialog would be insensitive during that time: is it really what we
> want?

That's not the problem. The volume applet had start ordering problems, and should work just fine waiting for PA to show up the first time. That should already have been fixed.

The problem is when PA goes away once we've connected once.

The other problems mentioned have nothing to do with this particular problem, and should be filed separately if they still occur.
Comment 6 Bastien Nocera 2009-05-20 19:47:45 UTC
I misunderstood what the NOFAIL flag was all about. Here's what Lennart told me:
<mezcalero> hadess: the idea is to create a pa_contex with NOFAIL set
<mezcalero> that way you get a pa_context that won't return "connection refused" when pa is not running
 instead it will just sit there and waituntil pa is started up
 and then when it is started it will connect and proceed normally
 and when pa dies
 you should free the context
 and create a new context with NOFAIL
 and again it will just sit there
 and when pa becomes available again it will do the connection
 and so on
<mezcalero> hadess: i guess i  don't have to mention that freeing the pa_context makes all pa_stream and other objects created from that invalid...

Quite a bit of work...
Comment 7 Marc-Andre Lureau 2009-06-14 22:12:59 UTC
Created attachment 136585 [details] [review]
Bug 564311 – "Connection failed" when PA drops off
Comment 8 Marc-Andre Lureau 2009-06-14 22:17:21 UTC
If you stress-test PulseAudio start/kill, you can notice that client side can get stuck in connect(): Resource temporarily unavailable (11). Lennart said it is supposed to be handled correctly by pulse (client side).

PULSE_LOG=5 src/gnome-volume-control-applet

also, this code doing NOFAIL is sub-optimal apparently, I wonder who did it... hum!
Comment 9 Bastien Nocera 2009-06-22 14:13:23 UTC
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
Comment 10 Tobias Mueller 2010-01-05 16:27:58 UTC
*** Bug 587231 has been marked as a duplicate of this bug. ***