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.
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
