Hi Mikel, On Tue, Mar 27, 2012 at 1:31 AM, Mikel Astiz <Mikel.Astiz@xxxxxxxxxxxx> wrote: > Hi Mike, > >> So that has me confused. If the MediaTransport interface is somewhat >> generic, why would I want to listen to another interface to know if I >> should call Acquire? In my case, I would need to listen to >> HeadsetGateway. As it is, the audio from my SCO connection is sent >> over a PCM bus, so I currently do not even register an SCO endpoint, >> because it was not needed. I agree that if you are the initiator, >> Acquire/Release is sufficient. In my case, as the non-initiator, it is >> not sufficient because I do not want to open an audio link by calling >> acquire unless it already exists. > > I'm not sure if this solves your specific problem(s) but I would propose that the MediaTransport API is extended with a method such as TryAcquire (or alternatively Acquire can be extended with either one more parameter, or some specific flag in accesstype). In that case the transport would not be acquired unless the audio link already exists. > > The current approach of listening to a state property and then calling Acquire is racy, no matter if the property is in the same interface or not. I think your proposal would fix this race in a way that doesn't fundamentally change the current design, so I'm in favor of it. > Regarding your comment on the need to listen to a different interface, I don't think this should be a big problem. Having said that, the Playing state in HeadsetGateway (and equivalents) could be replaced by a state in MediaTransport. That actually seems more appropriate to me. Agreed. The reason I don't like the current approach is that there is no explicit connection between the MediaTransport object and the other object that has the state property. Mike -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
