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

_______________________________________________
pulseaudio-discuss mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Reply via email to