Re: [RFC v5 1/8] audio: Move tel drivers to DBus interface

[Frederic Danis <frederic.danis@linux.intel.com>]

Hello Luiz,

Le 17/12/2011 11:15, Luiz Augusto von Dentz a écrit :
>>> 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 ?
>
> Both have problems, endpoint add extra round trips per connection
> which can be a problem for audio transfer/SCO reconnections.

OK, So I will continue with "Transport path" proposal.

>> 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).
>
> Yep, IMO the gains/volume need to be moved to transport, btw both
> agent and endpoint need to react to events such as volume change, the
> agent need to send AT+VG commands and the endpoint notify the
> application when the volume change completes.

In case of Telephony agent implementing the Audio Gateway part of 
HSP/HFP, it will send a +VG unsolicited result, which will not get reply 
from the Headset.
So, endpoint will not be able to notify the application when the volume 
change completes.

> Now, I don't think it is impossible to handle this it is just tricky
> and we cannot detect errors easily, but volume changes is already
> tricky (see PulseAudio), so I think it might be fine to try this first
> and see the results.

OK

>> 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.
>
> Whenever you give the transport object you have to give permission to
> the agent, but don't simplify let any process changes those values.

OK, I will add Telephony agent to the test.

>>> 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.
>
> Audio transfer is both ways, but apparently there is no AT command for
> triggering it, iirc it was part of HSP spec, but I don't think we have
> to worry too much about HSP nowadays.

OK

Regards

Fred

-- 
Frederic Danis                            Open Source Technology Center
frederic.danis@intel.com                              Intel Corporation