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

[David Henningsson]

On 2014-11-24 12:04, Tanu Kaskinen wrote:
> On Mon, 2014-11-24 at 11:12 +0100, David Henningsson wrote:
>>
>> 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
>
> This implies that we implement server-side corking, because currently
> the cork status is controlled by the client, and this "stalled" corking
> would be controlled by the server.
>
> Even though I have mentioned the "server-side corking" feature before
> (as something that we need and use in Tizen), I might not have explained
> how I think it should be implemented (Tizen's current implementation is
> less flexible than what I'd like). We should have a hashmap of "cork
> requests" in sink inputs and source outputs. The stream would be corked
> as long as the hashmap isn't empty, i.e. as long as someone thinks that
> the stream should be corked. The hashmap keys would be strings
> identifying the "corking reasons", so policy modules could easily add
> new reasons. The normal client-initiated corking would be one corking
> reason, and this stall detection would be another reason. Tizen's policy
> module would implement a third reason.

+1 in general for this idea, to consolidate the "stall" concept with the 
"server side cork" concept; the fewer concepts on the more use cases, 
the better :-)

I wonder what we should do with the "cork requests" though. I feel under 
this scheme, we should deprecate them and replace them with a "you have 
been (un)corked" message, possibly including the different reasons as 
strings, so the client can determine whether the cork happened because 
the client requested so, or if it was for some other reason.

In the case of stalling though, sending anything at all might be contra 
productive, if we want the playback to immediately continue when the 
client is no longer SIGSTOPped, the client should just ignore the stall 
(since the client is stalled, it will not receive the notification until 
it runs again...).

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