© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
Good question; I'm not sure we have considered SIGSTOP at all.
If SIGSTOP just stops the process without doing any type of cleanup, and keeps all connections alive, that would be the same as the application being unresponsive.
PulseAudio will treat that as if the application does not supply data in time, and underrun, hoping that the application will come back within a few milliseconds or so.
For recording streams, PulseAudio will buffer up, hoping that the application will come back and read all buffered data. (It might be worth checking if this can cause an OOM situation after half an hour or so!)
I think it would make sense to introduce a timeout in both cases - 5-10 seconds or so until the application is considered "broken" by PulseAudio and do...at least something. :-)