[pulseaudio-discuss] Server-side corking

[David Henningsson]

On 04/30/2013 04:22 PM, Kovacs, Janos wrote:
>> I'm not familiar with the use case that has inspired the patch
>> (Jaska or Janos, it would be nice if you could explain the use case)
>
> Without server side corking sound leaks might occur when enforcing policies.
>
> For instance the policy module in PA might cork streams at creation time;
> ask for audio playback rights from policy server and after the playback right were granted the policy module uncorks the stream. However, some players start corked by setting the PA_SINK_INPUT_START_CORKED flag and at some point uncork the stream and start to play.
> The two corking collides and the policies cannot be enforced.
> I experienced this with Rhythmbox if I recall it correctly.
>
> An independent server side corking mechanism prevents the problem.
>
>> I propose that we add a hashmap/list/whatever for cork requests,
>> so that there can be any number of simultaneous requests for one stream,
>> and the stream will stay corked as long as there is at least one request.
>> When a client requests corking, a cork request object will be created and
>> associated with the client, and the cork request object will be removed
>> when the client request uncorking. Similarly, modules would be able to
>> create and manage their own cork request objects.
>
> That sounds just fine.

Ok. Since we don't have "suspend causes" for sink inputs like we do for 
sinks, this approach sounds okay to me too.

However; we have to think about how we should deal with this w r t the 
client - how would you expect e g Rhythmbox to behave when server-side 
corks are in effect? Would we try to hide this from the client, who will 
not understand why its stream is not running, or would we inform the 
client, which then might try to uncork the stream and not succeed?

Or should we perhaps introduce another sink input state, say 
PA_SINK_INPUT_BLOCKED, when server side cork requests are active?



>
> br
> -janos-
>
>
>
>
> -----Original Message-----
> From: Kaskinen, Tanu
> Sent: Tuesday, April 30, 2013 2:06 PM
> To: General PulseAudio Discussion
> Cc: Kovacs, Janos; Uimonen, Jaska
> Subject: Server-side corking
>
> Hi all,
>
> Tizen has a patch[1] that makes it possible to cork streams from the server side. So far only applications have been allowed to cork streams (it has been possible to cork streams also from the server side, but that would cause conflicts if both applications and the server want to cork and uncork the same streams).
>
> I'm not familiar with the use case that has inspired the patch (Jaska or Janos, it would be nice if you could explain the use case), but in general server-side corking sounds sensible to me. The particular implementation of the patch doesn't look so good to me, though: it just adds one boolean to pa_sink_input for any server-side corking (the feature doesn't seem to have been added to source outputs at all). There may be multiple modules doing corking, so having just one boolean will still be prone to conflicts.
>
> I propose that we add a hashmap/list/whatever for cork requests, so that there can be any number of simultaneous requests for one stream, and the stream will stay corked as long as there is at least one request. When a client requests corking, a cork request object will be created and associated with the client, and the cork request object will be removed when the client request uncorking. Similarly, modules would be able to create and manage their own cork request objects.
>
> Comments would be very welcome. If there is no opposition, this feature will probably implemented sooner or later (I doubt that Tizen wants to carry that patch forever).
>
> [1] https://github.com/otcshare/pulseaudio/commit/f60d68bb1fc8e3b746d467d0638f522c4795229a
>
> --
> Tanu
>
> ---------------------------------------------------------------------
> Intel Finland Oy
> Registered Address: PL 281, 00181 Helsinki
> Business Identity Code: 0357606 - 4
> Domiciled in Helsinki
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
>



-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic