On 9 February 2015 at 16:12, Georg Chini <georg at chini.tk> wrote: > On 09.02.2015 11:19, Arun Raghavan wrote: >> >> On 9 February 2015 at 15:44, Georg Chini <georg at chini.tk> wrote: >>> >>> On 09.02.2015 10:55, Arun Raghavan wrote: >>>> >>>> On 9 February 2015 at 14:54, Georg Chini <georg at chini.tk> wrote: >>>>> >>>>> On 09.02.2015 10:16, Arun Raghavan wrote: >>>>>> >>>>>> On 9 February 2015 at 14:29, Georg Chini <georg at chini.tk> wrote: >>>>>>> >>>>>>> On 09.02.2015 09:28, Arun Raghavan wrote: >>>> >>>> [...] >>>>>> >>>>>> If you mean that we need to do AT command handling, we now already do >>>>>> a bit of that in PA (we couldn't really agree upon any other place for >>>>>> that once BlueZ dropped it). Is there much we need to support other >>>>>> than volume commands? >>>>>> >>>>>> Assuming it's not too much more complex than the HSP support, we >>>>>> should be able to manage that just fine by extending the native >>>>>> backend. >>>>> >>>>> >>>>> For audio you probably won't need much more. But if you do not >>>>> support the telephony functions, you are in the same situation as >>>>> ofono is with the AG role. Here ofono supports the AT commands, >>>>> but no audio, and what use is a headset without audio? >>>>> And if you support audio for a phone but not the telephony functions, >>>>> what is phone audio good for where you can't make or receive a call? >>>> >>>> You can receive a call (you don't need the headset functions to accept >>>> one), so we've had users using their computer, their Raspberry Pi, or >>>> other devices for such use cases. >>>> >>> Really? Without using ofono? I wonder how this worked. I did already >>> use ofono with bluez4 and it would not have worked without. Who >>> sends the AT command to accept the call to the phone? Or do I have >>> to pick up manually then? >> >> Since we didn't have a mechanism to answer the phone call, probably >> was manual. Do note that this mode would be useful for more than >> telephony calls (i.e. voip calls too). >> >> > Sorry that I can't stop ... > First, I can't think of a case were you need a bluetooth HF profile for > voip. > How should that work? Maybe I'm mixing profile names. This would be the equivalent of PulseAudio providing the role of the headset, and your phone / other computer making a VoIP call. > The main difference between the implementation in Bluez4 and Bluez5 > is, that the connection management is no longer done by the Bluez > stack but either by ofono or pulseaudio. > With Bluez 4 you could "share" the connection, meaning let Bluez > manage the connection and then use audio from pulse and AT commands > from ofono. > Now the situation is different: Either ofono or pulse has to implement > connection management and then pass on the unused part to the > other application. If you don't do that you will break the other > application. > (See AG implementation in ofono) > > The best would be to implement the AG role in pulse (because a headset > is mostly audio) and pass on AT handling to ofono while implementing > the HF role in ofono (because it's mostly telephony) and pass on the > audio to pulse. But that would imply that the developers talk to each > other and resolve the overlap which apparently has not been the case > until now. That discussion has happened, and was hashed over multiple times. I've explained the rationale for the way things are right now in my previous mail (with regards to dependencies). The solution that seems to make sense is for PA to provide basic headset support (both talking to headsets which we have now, as well as acting as a headset, which I hope we will have in 7.0). This would get us to the point where our non-oFono users were with BlueZ 4. Now anything that was possible with oFono + BlueZ 4 will need to be enabled via our oFono backend for BlueZ 5 (this would be the handsfree feature-set). I hope this makes the situation clearer. -- Arun
