Hi Luiz, On Mon, Mar 26, 2012 at 9:41 AM, Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: > Hi Mike, > > On Fri, Mar 23, 2012 at 2:51 PM, Mike <puffy.taco@xxxxxxxxx> wrote: >> >> Going back to this idea, it seems like MediaTransport should be >> redesigned to push the file descriptor to the endpoint, rather than >> the endpoint having to request it from the transport. this would >> solve this issue. The main problem is that acquiring the endpoint >> forces a call to resume. In the case of HFP, this is bad. I'm >> currently needing to implement HFP "Audio Connection Transfer Towards >> the AG". Since I am the HS, all I need to do is drop the SCO >> connection -- however, there is no interface to do this well. I tried >> implementing an SCO endpoint, since at least then the acquire and >> release calls would bring up an SCO connection and then allow me to >> drop it. The issue here is that a phone that is connected via HFP >> will have a MediaTransport even though the SCO connection will not yet >> exist. So, I get the SetConfiguration call which means I should be >> good to go on calling acquire. But, if I call acquire now, it will >> create a useless SCO connection to my phone that then is dropped. >> There's no reason at this point to open the SCO connection. I would >> rather be notified when the SCO connection exists, and have two >> additional methods called suspend and resume. In the case of HFP, >> calling resume would eventually result in a new FD being pushed to me. > > Pushing maybe a good idea in case of not being the initiator the > connection as you mentioned, in the other hand the endpoint may not be > ready, or willing to use the fd, at that point so I would only signal > that it is now available, otherwise the concept of using it on-demand > in broken. Isn't that the point of registering an endpoint? If you have registered, you are declaring you will accept data. > Btw, this already is possible if you listen to > Headset.State, also the interface was designed to have the connection > on-demand, so you should only call Acquire when you gonna use the fd, > anyway even in the case of audio transfer you maybe the initiator and > should be able to directly control the connection via Acquire/Release > to be able to do that so Resume/Suspend would not be that great even > for IVI/carkit systems. 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. My perception is that the interface is written from the point of view of the audio source (A2DP Audio Source or HFP AG), but this does not translate as well to the audio sinks (A2DP Audio Sink or HFP HF). -- 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
