On 09.02.2015 12:21, Luiz Augusto von Dentz wrote:
Hi Georg,
On Mon, Feb 9, 2015 at 12:42 PM, Georg Chini <[email protected]> wrote:
On 09.02.2015 11:19, Arun Raghavan wrote:
On 9 February 2015 at 15:44, Georg Chini <[email protected]> wrote:
On 09.02.2015 10:55, Arun Raghavan wrote:
On 9 February 2015 at 14:54, Georg Chini <[email protected]> wrote:
On 09.02.2015 10:16, Arun Raghavan wrote:
On 9 February 2015 at 14:29, Georg Chini <[email protected]> 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?
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.
The connection management as per socket handling is still done by
bluetoothd, the AT command parsing is the one no longer done by BlueZ
itself.
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.
BlueZ 4 acted as a middle man only for HF role.
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)
If you are talking about SCO, yes that is left for oFono to deal with
thus it has some interfaces to hand over the connection to pulseaudio
via ofono backend.
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.
It does not make sense to talk about roles here, what PulseAudio
should implement is HSP for both roles which does not require any
telephony stack since all AT commands are audio related, HFP should be
implemented by a telephony stack which optionally can hand over the
audio to pulseaudio. Depending on the platform you may or may not have
a telephony stack, Id say if you do have then HFP should be enable
otherwise use HSP.
And that means you can have both stacks active at the same time.
It does not interfere, pulse would support UUID 0x1108 and 0x1112
while ofono supports 0x111e and 0x111f. Device initiated connections
would prefer ofono if available because usually HFP is tried before HSP.
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
