[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.


More information about the pulseaudio-discuss mailing list