Lennart Poettering wrote: > On Tue, 04.03.08 09:45, Colin Guthrie (gmane at colin.guthr.ie) wrote: > >> I initially put this down to g-p-m doing something silly, but looking at >> the sound code there is very little in the way of loops and it just >> off-loads to gstreamer. >> >> Last night, I noticed that a similar thing had happened but this time I >> had lots of pidgin streams "saved up". I started killing them and the >> same thing happened, pidgin started going nuts and eating ram. >> >> So the common factor is gstreamer. Does anyone have any info on this? >> >> I'm using gstreamer0.10-pulse-0.9.7 + pulseaudio 0.9.8 > > To my knowledge this is indeed an ALSA issue: after resume the PCM > device is not properly restarted by the kernel drivers. PA doesn't > notice that, ALSA never asks for new audio data, all current and new > audio streams appear stuck. > > In theory ALSA defines a proper state machine for dealing with system > suspends. The issue is just that it doesn't work on some drivers on > some hardware. > > Please report this issue to ALSA upstream if it persists with the > newest ALSA driver. Thanks for the info Lennart. I've not really had issues of late so I think a kernel update has indeed fixed the issue for me. The problem of GStreamer causing a deadlock (#188, #251) I think still exists, but as it is not triggered very often for me it's less of an issue. Cheers Col
