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

Sun Nov 25 09:35:21 PST 2012

On 11/23/12 21:48, Tanu Kaskinen wrote:
> On Fri, 2012-11-23 at 00:00 +0100, Henrik /KaarPoSoft wrote:
>
>> 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.
It seems there are two different (probably unrelated) issues:

1) FIREFOX USING ALSA

Those two cases:

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.

Seems to be caused by my own stupid misconfiguration.

Firefox seems to access alsa directly; not through pulseaudio.
I created a suitable /etc/asound.conf, and compiled the pulse alsa-plugin,
and now this issue seems to be fixed.

2) DESKTOP FREEZING ON CLOSING LAST WINDOW.

I wrote:

I can *not* reproduce the hang with:
open gnome-terminal (as only app on desktop), press backspace, close
terminal.

But it seems that i *can* reproduce it with 2.99.2.
It still happens, but just not every time.

So, back to square one.

> When you press backspace, do you hear the "pling" sound, or does it
> freeze silently?
I *do* hear the sound.
>   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...
I made the above changes, and now get the "Received opcode..."  from the 
daemon in the log. Thanks.

But I cannot figure out how to get log output from gnome-shell either.

If I put this in my /etc/profile:
--------------------------------------------------
export PULSE_LOG=4
export PULSE_LOG_LEVEL=4
export PULSE_LOG_SYSLOG=1
--------------------------------------------------
clients in general show the expected traces in syslog.
So I can run firefox or pacat, and see the "Received opcode..." from 
both client and daemon in syslog, and match them as you suggested.
However, with this /etc/profile, gnome-shell starts allright, but plays 
no sound whatsoever, and logs nothing to syslog.
No clue why.

Anyway, here is a log from 2.99.2:
https://sourceforge.net/p/kaarpux/tickets/_discuss/thread/a1e6c549/cfd3/attachment/log_2_99_2.txt

I created a gnome-terminal, pressed <backspace> for a beep, then closed.
The first three times it worked OK, the last time it hung the desktop.

A bit later I was doing some desktop work, and closed all windows at the 
end.
All there is in the log when closing the last window is:
Nov 25 17:54:40 kx8400-5 pulseaudio[2091]: 
[pulseaudio][pulsecore/pdispatch.c:318 pa_pdispatch_run()] [0x8eb53e8] 
Received opcode <PLAY_SAMPLE>, tag 37
Nov 25 17:54:49 kx8400-5 pulseaudio[2091]: 
[pulseaudio][modules/module-udev-detect.c:287 verify_access()] 
/dev/snd/controlC0 is accessible: yes
Nov 25 17:54:49 kx8400-5 pulseaudio[2091]: 
[pulseaudio][pulsecore/ratelimit.c:55 pa_ratelimit_test()] 6 events 
suppressed
Nov 25 17:54:49 kx8400-5 pulseaudio[2091]: 
[pulseaudio][pulsecore/flist.c:156 pa_flist_push()] pulsecore/hashmap.c: 
entries flist is full (don't worry)

So, except from getting the direct alsa access issue out of the way, and 
confirming that the close-last-window issue is still there, I guess I am 
back to square one...

/Henrik

PS: I do not know if this is relevant, but:
The only sound I have heard from gnome-shell is when I insert a USB device.
There is no sound when logging in, logging out, or anything else that 
have got my attention.