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:
On 4 February 2015 at 14:10, David Henningsson
<[email protected]> wrote:
On 2015-02-03 15:04, Tanu Kaskinen wrote:
On Mon, 2015-02-02 at 16:49 +0100, Georg Chini wrote:
I think the release notes for 6.0 should be revised to account for
that.
Indeed. Before I update the notes, though, I want to get a decision on
whether we will release with your patch to use both backends
side-by-side (probably implies another rc before final release), or will
we postpone that to the next release. Either is fine by me, but I'd vote
for releasing with your patch.
Hmm. I'm not totally sure about the differences between HF and AG so take
this with a grain of salt, but...
It seems to me that it's not extremely unlikely that either of us will
step
into the other domain in the future, i e, bluez 5 might implement AG
audio
or PulseAudio might implement a native support for HF.
Also, if the AG plugin of Bluez 5 supports RFCOMM/AT commands then we're
already partially overlapping, because that's what we use to set/get
headset
volume and mic gain. If we enable both backends, will that then send AT
commands from both backends when we try to set the volume, or...?
Hence, instead of removing all backend switching code, maybe we should
instead add a switching mode "both" which does what you say. Or
potentially
replace "auto" with "both", if "auto" now makes no sense.
Finally, I remember Arun had a strong preference for not enabling the
ofono
backend by default, so Arun, could you elaborate upon whether that still
makes sense given this new information?
The reason I was against a "both" mode is that it seems odd to me from
a system integration perspective. The current situation seems to be
either you have oFono as a part of your system and you're using it for
modem management, some amount of BT audio management, and so forth.
Else, you're using PulseAudio for the BT audio management (the stuff
that BlueZ used to do but dropped in 5.x).
That is not really correct. Even if you use ofono, you still need pulseaudio
for the BT audio, otherwise it just won't work. ofono will only manage
the connection for you.
I think you might've misunderstood me. With oFono, you need PulseAudio
for Bluetooth audio. As I wrote below, I don't think it makes sense
that we mandate the opposite dependency. That is to say, it does not
make sense to make oFono a dependency of PulseAudio for the use-cases
that we supported with BlueZ 4.0.
It seems odd to me to have a "both" mode -- I'd like to add back the
features we supported before the BlueZ 5.x migration caused us to
regress. Once Wim's HSP work is out, that basically leaves the HF role
(PA on your acting as a headset). If I understand correctly, that will
overlap with oFono (if oFono wasn't bringing a telephony stack along
with it, I wouldn't be objecting to just using it as our external dep
that provides these features)..
But that is the point of the HF role. If pulseaudio was going to support
the HF role, it would also need to implement an (external) handler for
RFCOMM. So you would need to duplicate the ofono functionality in
some way or do the integration the other way round.
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?
So to my mind, having a both mode does not seem too useful from a
system integration point of view -- either we have oFono provide these
and other services, system-wide, or we're having PA manage whatever
(sub?)set of features we want to.
I think the idea of having ofono manage the HF role and using pulseaudio
for the AG is from the practical (user) perspective at the moment as near
as you can get to the bluez4 situation. With both backends I finally can
connect my mobile and my headset which was not possible for bluez5
before.
Yes, it is not a great thing that we had to regress on this
functionality, but I think we're making progress towards restoring
that via the native backend now.
-- Arun
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
