[pulseaudio-discuss] [PATCH 4/4] stream_intercaction: interact if a stream starts corked

[Georg Chini]

On 21.03.2016 19:18, Tanu Kaskinen wrote:
> On Mon, 2016-03-21 at 16:06 +0100, Georg Chini wrote:
>> On 21.03.2016 15:56, Tanu Kaskinen wrote:
>>> On Mon, 2016-03-21 at 15:41 +0100, Georg Chini wrote:
>>>> On 21.03.2016 15:11, Tanu Kaskinen wrote:
>>>>> On Mon, 2016-03-21 at 15:53 +0200, Tanu Kaskinen wrote:
>>>>>> That aside, it seems to me that we shouldn't care about the current
>>>>>> cork state anyway. If the stream is corked when we send the cork
>>>>>> request, the application has two reasons to have the stream corked: the
>>>>>> first reason is whatever reason made the application cork the stream in
>>>>>> the first place, and the second reason is our cork request. When we
>>>>>> send the uncork request, only one of those reasons goes away. It's up
>>>>>> to the application to keep track of its corking reasons, and keep the
>>>>>> stream corked as long as there is any reason to do so.
>>>>> The cork state checking was added here:
>>>>> https://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=dda564f50b55340ff4bfbaa8d6d6fc6427f764f4
>>>>>
>>>>> Colin mentions paused Rhythmbox as an example use case where it would
>>>>> make sense to avoid sending the cork/uncork requests. In my opinion
>>>>> Rhythmbox shouldn't blindly unpause when it receives an uncork request
>>>>> from PulseAudio, but if it does, then it might not be a good idea to
>>>>> change the logic. This should be tested, but Rhythmbox is somehow
>>>>> totally broken on this machine (won't play anything), so I can't do
>>>>> that.
>>>>     
>>>> I don't touch the cork/uncork/mute/unmute logic for existing streams
>>>> with that patch, only new streams are affected in so far that they are
>>>> muted.
>>> Yes, I know. Your patch ignores the cork state for new streams, which
>>> is good, but I tried to suggest that maybe it would be even if we
>>> ignored the cork state also for existing streams.
>> OK, got you. But that would mean, that the application has to keep track
>> of multiple cork requests. I am thinking about some stream that is corked
>> manually. If we send an uncork request to that stream, there are three
>> possible results:
>>
>> 1) Nothing happens, because the client ignores cork/uncork requests from
>> the server
>> 2) The client removes one "corking reason" but still keeps the stream corked
>> 3) The stream is uncorked (which is unwanted because it was corked manually)
>>
>> There is probably no application out there that keeps track of the cork
>> requests, and to avoid 3) I think we should keep the current logic.
> You're right. I was expecting there to be more problems, because the
> current logic prevents application from having information that it
> might in theory need to manage the cork state correctly, but when
> manual corking is the only other "competing" source, I couldn't think
> of any use case where the current logic would fail.
>
> If the application does any kind of automatic corking, then incorrect
> uncorking may happen. I don't know any real-world use cases, but I can
> imagine some application that produces sound while some condition holds
> and other times stays silent (corked). For example, maybe I want to
> play music every morning from 9 to 10, and I make a program that is
> always running, but keeps the stream corked most of the time. Let's say
> that at 8:50 a phone call comes in, and it lasts more than 10 minutes.
> Since my application didn't get a cork request, because it was corked
> when the phone call started, it doesn't know that it should keep the
> stream corked, so music starts to play at 9 o'clock.
>
> I'll apply the patch as is.
>
> -- 
> Tanu
Thanks for your review!