pulseaudio causing crashing of applications

[Andrew Farris]

Lennart Poettering wrote:
> On Wed, 13.02.08 13:06, Andrew Farris (lordmorgul at gmail.com) 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 at gmail.com> 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
----                                                                       ----