[pulseaudio-discuss] Releasing stream resources when the client receives SIGSTOP

[David Henningsson]

On 2014-11-20 04:44, Ricardo Salveti wrote:
> Hey,
>
> When investigating the issue we had on Ubuntu Touch, described by bug
> https://bugs.launchpad.net/ubuntu-rtm/+source/pulseaudio/+bug/1391230,
> I noticed that PulseAudio never releases the resources used by an
> active stream if the app gets a SIGSTOP, keeping pulse busy and
> consuming cpu until the app resumes or is closed by the user.
>
> On Ubuntu Touch that happens when the application is active playing
> audio/video, and the user moves back to the home scopes (Ubuntu Touch
> lifecycle will automatically send a SIGSTOP after 5 seconds). When
> checking that on my desktop, I also noticed that the same happens (by
> forcing a SIGSTOP against mplayer, for example). Pulse only releases
> the stream when the app pauses the stream, not necessarily when the
> app stops after receiving the signal.
>
> I raised this first with David to understand if it was indeed a valid
> use case, and he said that it was indeed something that it was
> probably never really considered
> (https://bugs.launchpad.net/ubuntu-rtm/+source/pulseaudio/+bug/1391230/comments/8).
>
> So before going and trying to deep dive and find a fix for the issue,
> I first wanted to understand from you guys if this is indeed a valid
> issue and what would be the best way to get this fixed. I know we're
> still using Pulse 4.0 on Ubuntu, but wanted to make sure to get
> something that would also be compatible with upstream.

So when I discussed this with Ricardo, my suggestion was that we either

  1) (ab)use the cork mechanism to stop/resume the client when we 
discover that the client is SIGSTOPped, or

  2) introduce a new state for sink inputs and source outputs, like 
SINK_INPUT_STALLED or something.

My gut feeling is that the second option is cleaner.

 From PA's perspective, I think this is the same situation as if the 
client has hung, we keep on hoping that the client will come back the 
next millisecond, so we keep the sink/source open. In case of recording, 
we'll keep on buffering data until...I don't know what happens tbh. 
Probably the memblockq will start to complain after 64MB or so.

Anyhow, this needs work on several levels to do properly. Some place, 
probably in the core, needs to detect that the client has hung by some 
timeout definition, and set sink state accordingly. But I'm not sure 
*where* in the core would be the place to detect this - probably the I/O 
thread should detect it, and notify the main thread? That would make it 
work across other protocols than the native protocol too.

What do others think?

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic