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