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
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
