Re: media transport -- when is acquire ok to call?

Hi Luiz,

On Mon, Mar 26, 2012 at 9:41 AM, Luiz Augusto von Dentz
[off-list ref] wrote:

Hi Mike,

On Fri, Mar 23, 2012 at 2:51 PM, Mike [off-list ref] wrote:

quoted

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