On Wed, 13.02.08 13:20, Andrew Farris (lordmorgul@xxxxxxxxx) wrote: >>> the track time continues, and it then gains access to play to the audio >>> device again when returning from VT. The crash is not expected; the >>> track time stopped, and rhythmbox does not respond to input. >> PA provides the necessary information. It's just that Gst doesn't and >> thus simply blocks waiting until it can write to the audio device the >> next time, freezing the UI. >>> So I guess this is an area for improvement to get the applications to >>> correctly handle this situation since it is designed behavior on >>> pulseaudio's end (to deny access while not being the active session). >> I am not sure why this should be an issue at all. So Rhythmbox's UI >> freezes while the session is inactive. So what? The session is >> *inactive*! The UI doesn't need to be responsive. >> Lennart > > Correction. Rhythmbox froze during AND after the session was inactive, > making it permanently frozen (dead, defunct, useless). This is definitely > wrong. So its an issue with how gst (and by extension rhythmbox) handle > things, inappropriately in that case. But it was a problem. This sounds as if some other process blocked the audio device when switching back the session so that PA was unable to reopen the device and thus playback stays suspended. Could you please check this, by running "pactl" in a terminal when this happens again, and then type "list-sinks"? If your sound card sink remains in SUSPENDED state, than this is most likely the issue. Or, you might have hit the well-known issue HAL where it fails to restore ACLs sometimes and thus PA is not able to reopen the device properly. Check getfacl /dev/snd/* Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
