Hi Frederic, On Fri, Dec 16, 2011 at 5:00 PM, Frederic Danis <frederic.danis@xxxxxxxxxxxxxxx> wrote: >> 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. > 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. 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. > 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. >> 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. -- Luiz Augusto von Dentz -- 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
