Hello Luiz,
Le 16/12/2011 11:35, Luiz Augusto von Dentz a écrit :
Hi Frederic,
On Fri, Dec 16, 2011 at 10:41 AM, Frederic Danis
<frederic.danis@xxxxxxxxxxxxxxx> wrote:
I wrote flowcharts for SCO connections and some AT commands (AT+NREC,
AT+VGS, ...) for the 2 approaches (side by side). This is available on
http://pastebin.com/sLBj7kpW
Good work putting this together, probably we should add this to the
documentation, btw this already shows us the latency won't be that
great with this solution.
Thanks
Which solution is not great ? both ?
As you can see, when passing Media Transport path in NewConnection method,
the complexity is located during volume management.
I do not think that we can have synchronization problems if property changed
signal is sent in all cases.
What do you mean by all cases, it has to be emitted in all cases and
that is the problem, you don't know if the signal is a notification
caused by calling SetProperty or someone else has changed the value.
This became clear in the case of AT+VGS,AT+VGM, if you handle the
signal its going to cause a ping-pong effect, obviously there are ways
to ignore like checking if the value has really changed, but we have
to be careful here since we had this type of problem in harmattan when
the values changed too quickly it creates a loop.
Currently, if I take volume speaker as sample, BlueZ sends
SpeakerGainChanged signal on reception of SetSpeakerGain method call
(user action on the phone) or AT+VGS command (user action on headset).
This signal should only be sent by the Media Transport object, i.e. :
- for "Transport path" proposal, this signal should be moved
from headset.c to transport.c.
- for "Media Endpoint" proposal, this signal should be moved
to the Media Transport of the telephony agent.
I do not understand why a ping-pong effect should start (no application
should react to SpeakerGainChanged signal by a SetSpeakerGain method call).
Btw, Im not so sure this currently works because you should only be
able to set something if you have acquired the fd, have you changed
that so the agent can also do it?
Not yet, but your are right this test should be removed.
We must make it possible to set Noise Reduction, Echo Cancellation,
speaker or microphone gain values before the audio is connected.
Those values should be stored in the Media Transport object.
When moving MediaTransport to telephony agent (i.e. oFono), complexity moves
to SCO connections, passing SCO fd through oFono to PulseAudio.
This will also imply to remove code from Media Transport, which will
complicate this set of patches.
It will also break similarity between A2DP and HSP/HFP (currently both media
transport code are in BlueZ, breaking that will set one transport in BlueZ,
the other not).
True, but are you sure the agent wont have to deal directly with the
SCO connection? Afaik there were some AT commands to do the audio
transfer, although for HFP it seems to be directly by
connecting/disconnecting SCO.
My understanding is that BlueZ/oFono are not involved in decision to
set-up or not the SCO connection, this decision should be taken by
PulseAudio or a policy manager component, and SCO connection will be
performed on Acquire method called by PulseAudio.
Regards
Fred
--
Frederic Danis Open Source Technology Centre
frederic.danis@xxxxxxxxx Intel Corporation
--
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
