On Wed, 13.02.08 13:06, Andrew Farris (lordmorgul@xxxxxxxxx) wrote: > Well I would expect the writes to the device to be denied, but not that > rhythmbox would freeze rather than just continuing to try and play. If in > fact the applications all received a 'pause' message that would be ok I > suppose, but that is not quite what happened in that situation. Rhythmbox > actually thought it was playing the entire time once or twice, 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 -- 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
