Hi Luiz, > 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 The issue above could be briefly discussed next week as well. Cheers, Mikel -- 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
