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

[Georg Chini]

On 21.03.2016 14:53, Tanu Kaskinen wrote:
> On Thu, 2016-03-17 at 22:35 +0100, Georg Chini wrote:
>> This patch deals with the case that applications start new streams corked.
>> It was not included in the original series but sent at a later time.
>> In case of module-role-cork it will only mute the stream because corking is
>> removed later by the application.
>>
>> ---
>>   src/modules/stream-interaction.c | 32 +++++++++++++++++++-------------
>>   1 file changed, 19 insertions(+), 13 deletions(-)
>>
>> @@ -164,7 +164,13 @@ static inline void apply_interaction_to_sink(struct userdata *u, pa_sink *s, con
>>           if (!trigger)
>>               continue;
>>   
>> +        /* Some applications start their streams corked, so the stream is uncorked by */
>> +        /* the application only after sink_input_put() was called. If a new stream turns */
>> +        /* up, act as if it was not corked. In the case of module-role-cork this will */
>> +        /* only mute the stream because corking is reverted later by the application */
>>           corked = (pa_sink_input_get_state(j) == PA_SINK_INPUT_CORKED);
>> +        if (new_stream && corked)
>> +            corked = false;
> I don't understand the last sentence of the comment (and the commit
> message) - I thought this patch solves the problem that applications
> will uncork the stream when they shouldn't, but the comment makes it
> sound like this is still a problem.
>
> 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.
>
> -- 
> Tanu

The original bug report was the following: You have audacious running
and playing a stream when a trigger stream turns up. At this point the
running stream will be muted (not corked because audacious does not
honor the cork request). At the point when audacious advances to the
next stream in the play list, it will start a new stream. At the time of
creation this stream is corked, so the module ignores it. Then audacious
will uncork the stream and it plays and is not muted. So the idea was to
at least mute a new stream when it is started corked. I can't do anything
about the cork state because it is controlled by the application but I can
at least mute a new stream even if it starts corked.
See here for the original thread:
http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/23934