[pulseaudio-discuss] gnome-shell hangs, waiting for pulse-audio

[Tanu Kaskinen]

On Fri, 2012-11-23 at 00:00 +0100, Henrik /KaarPoSoft wrote:
> On 11/22/12 13:39, Tanu Kaskinen wrote:
> > Henrik, is it possible for you to try 2.99.2 too? For what it's worth, 
> > last time when I said "I can't reproduce this" I did have other 
> > windows open, but I retested with the gnome-terminal window being the 
> > only window, and I still couldn't reproduce the bug. 
> 
> Well, I am getting more and more confused.
> 
> First of all to recap:
> With 2.1 I can reproduce the hang every time I close the last window on 
> the desktop, if this desktop is or where just producing sound.
> Eg: open gnome-terminal, press backspace, close terminal;
> or: open firefox, play html5 video on youtube, close firefox.
> 
> Also, a few times during normal "office work", the desktop hangs if a 
> terminal produces a beep, even if it is not the last/only window on the 
> desktop.
> 
> Further, I have seen the hang when starting thunderbird as the first 
> application after logging in.
> It shows the loading icon in the top bar of gnome-shell, but thunderbird 
> never shows up on the desktop, which is unresponsive.
> Presumably this would be because thunderbird is playing a sound upon 
> receiving new mail.
> I have not investigated or tried to reproduce for fear of loosing my mail...
> 
> I have now build and installed 2.99.2.
> 
> Note however, that it is just installed "on top" of 2.1; I did not try 
> to remove any 2.1 stuff first.

And apparently you specified "prefix=/usr". I wouldn't recommend that.
If something breaks, it's a bit of a hassle to try to get the distro
version back. By default pulseaudio installs to /usr/local - that works
fine, and is easier to clean up. Well, luckily things don't seem to be
completely broken for you (any more than what they already were).

> Also, I did not recompile any other packages dependent on PulseAudio.

That shouldn't be needed anyway.

> 
> The new version seems to be installed and symlinked correctly:
> ls -l /lib/libpulse.so*
> lrwxrwxrwx 1 root root     18 Nov 22 23:03 /lib/libpulse.so -> 
> libpulse.so.0.15.1
> lrwxrwxrwx 1 root root     18 Nov 22 23:03 /lib/libpulse.so.0 -> 
> libpulse.so.0.15.1
> -rwxr-xr-x 1 root root 981874 Oct 13 13:09 /lib/libpulse.so.0.14.3
> -rwxr-xr-x 1 root root 981534 Nov 22 23:03 /lib/libpulse.so.0.15.1
> 
> I am not sure if every app/lib dependent on PulseAudio is picking up the 
> new version correctly;
> for reasons I do not understand gnome-shell seems to link to both the 
> old and new version:
> 
> ldd /bin/gnome-shell | grep pulse
>      libpulse-mainloop-glib.so.0 => //lib/libpulse-mainloop-glib.so.0 
> (0xb5771000)
>      libpulse.so.0 => //lib/libpulse.so.0 (0xb5723000)
>      libpulsecommon-2.1.so => //lib/pulseaudio/libpulsecommon-2.1.so 
> (0xb56b7000)
>      libpulsecommon-2.99.so => //lib/pulseaudio/libpulsecommon-2.99.so 
> (0xb4da6000)

No idea about that.

> In any case, for whatever it is worth, here is what I am now seing with 
> 2.99.2:
> 
> I can *not* reproduce the hang with:
> open gnome-terminal (as only app on desktop), press backspace, close 
> terminal.
> 
> I *can* reproduce the hang with:
> open firefox (as only app on desktop), play html5 video on youtube, 
> close firefox.
> 
> I *can* reliably produce the hang with:
> open firefox (as first app on desktop), play html5 video on youtube.
> open gnome-terminal (as second app on desktop), press backspace (ie. 
> *not* even closing terminal).
> Now sound from youtube keeps playing, but the desktop is unresponsive.

I tried that last case myself, still can't reproduce.

When you press backspace, do you hear the "pling" sound, or does it
freeze silently? I took a fresh look at the backtrace that you pasted to
your original mail, and at least in that case the freeze seemed to
happen when giving the command to play the sample to pulseaudio. Either
pulseaudio didn't react to that command, or else pulseaudio did play
that sample, but never sent an acknowledgement back to the application.
Contrary to what Colin said, libcanberra is not waiting for the sound to
finish playing, it's waiting for an ack for the command to start the
sample playback. That command should always return quickly (it doesn't
wait for the sample to finish).

How to debug this? Maybe add extra log output to pulseaudio (and
libpulse) until you find the exact place where something goes wrong. Or
maybe this would be a good starting point: in the beginning of
src/pulsecore/pdispatch.c, theres "#define DEBUG_OPCODES" commented out.
Remove the commenting, that is, enable the debug option. Also, improve
the debug output a bit. The file contains this line in
pa_dispatch_run():

pa_log("[%p] Received opcode <%s>", pd, p);

Change that to

pa_log("[%p] Received opcode <%s>, tag %" PRIu32, pd, p, tag);

The tag will allow you to match commands and replies. Replies have the
same tag as the original command.

Then build pulseaudio again. That debug option will make pulseaudio
print every command that is sent via the native protocol (both at the
server and the client end). When sample playback is requested, this
should be printed in the server log:

E: [pulseaudio] pdispatch.c: [0x1113390] Received opcode <PLAY_SAMPLE>, tag 2

Correspondingly, the client log should contain this:

[0x248caf0] Received opcode <REPLY>, tag 2

What would be interesting is that does pulseaudio receive the
PLAY_SAMPLE command, and if it does, does gnome-shell receive the REPLY
to that command.

Unfortunately, I don't know how to get log output from gnome-shell...

One thing that I noticed is that for me gnome-shell doesn't play its
sounds from pulseaudio's sample cache. Instead, it plays the sounds
using normal streams via the alsa interface. I checked now, and I don't
have the pulseaudio backend for libcanberra installed... I have now
installed the pulseaudio backend, but still can't reproduce the problem.

One problem now with the pulseaudio libcanberra backend is that if I
restart pulseaudio, I won't get any sounds from gnome-shell anymore.
That can apparently be fixed by killing gnome-shell (it will then
restart, and any open windows will be retained).

-- 
Tanu