[pulseaudio-discuss] module-role-cork and mp3s

Tanu Kaskinen tanuk at iki.fi
Tue Aug 18 06:03:46 PDT 2015


[added pulseaudio-discuss back to cc]

On Mon, 2015-08-17 at 20:46 +0200, Georg Chini wrote:
> > > @Tanu: Is there something like a "cork counter" in PA which keeps track of
> > > multiple corks for the same stream and only releases the cork if the counter
> > > goes to zero? If not should something like that be added?
> > If you mean that is there a counter at the server side, the answer is
> > no. The current situation is that the server never initiates uncorking,
> > so there's no need for counting. Clients, however, are expected to
> > count cork and uncork requests (see pacat.c for an example).
> 
> In this case the problem seems to be that corking is requested before
> sink_input_put() returns, so the client does not notice the request.
> > 
> > If server-initiated corking is to be implemented (and somebody should
> > implement that), then we need to track client-initiated and server
> > -initiated cork actions separately, and only uncork when there are no
> > cork requests left from either side.
> > 
> I do not really understand what you mean here. Some modules like 
> module-loopback
> for example use pa_sink_input_cork() and pa_source_output_cork(). Is 
> that server
> side corking or is module-loopback considered more a client than part of 
> the server?

Right, my distinction between client and server-initiated corking isn't
quite perfect. In case of module-loopback, the module is similar to a
client in the sense that it creates and owns streams, so it's free to
cork its own streams.

> And what would happen to a client like VLC if the audio stream is corked 
> on the server
> side? Would it notice and then also pause the video stream?

There should be some mechanism for getting notifications, but existing
applications can't notice server-initiated corking without code
changes. That means that existing applications will break to some
extent on systems that have a policy that corks streams forcibly. I
don't see any way around that. Even if we allow such policies, we don't
have to enable those by default, if the application breakage is
considered too severe.

-- 
Tanu


More information about the pulseaudio-discuss mailing list