On Thu, 2013-05-02 at 08:15 +0200, David Henningsson wrote: > 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? I think it would be dangerous to change pa_stream_is_corked() so that it would return true also for server side corking, because I'd imagine that the return value is quite likely used to decide whether the application should uncork, and uncorking by the application in presence of server side corking is useless, as you pointed out. So I'd make pa_stream_is_corked() follow the application's own corking only. The cork state returned through the introspection API, however, could probably take server side corking into account too. That way e.g. "pactl list" would show accurate information. Or would that be too confusing, different cork state being visible through different APIs? > Or should we perhaps introduce another sink input state, say > PA_SINK_INPUT_BLOCKED, when server side cork requests are active? Do you mean in the public or internal API? I'm not sure it's possible to introduce new states at all in the public API. Old code won't understand any new states and might misbehave due to unknown stream states. And I don't see the benefit of adding a new state in the internal API. -- 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.
