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

[Tanu Kaskinen]

On Mon, 2016-03-21 at 19:39 +0100, Georg Chini wrote:

> 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.
> 
> I think we could work around the problem if the stream had two flags,
> "corked_by_server" and "corked_by_client".
> When a client corks a stream we set "corked_by_client" and when the
> server sends a cork request, we set "corked_by_server".
> When an uncorking request arrives from client or server, the corresponding
> flag is reset but the stream is only uncorked if both flags are unset.
> This would however be another patch series.

So would we send a cork request if a phone call starts while the stream
is corked? If yes, then manual uncorking in Rhythmbox during the phone
call wouldn't work any more. If not, then there's no difference to the
current behaviour.

-- 
Tanu