Lennart Poettering wrote:
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
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.
--
Andrew Farris <lordmorgul@xxxxxxxxx> www.lordmorgul.net
gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
---- ----
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
