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
