[pulseaudio-tickets] [Bug 73325] HSP not working in pulseaudio with BlueZ 5

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=73325

--- Comment #19 from Luiz Augusto von Dentz <luiz.dentz at gmail.com> ---
(In reply to comment #18)
> I've been trying a couple of things to get this moving. My goal was to make
> audio playback work on my external bluetooth Headset. 
> 
> 1) Pulseaudio registers itself as a Headset Audio Gateway to the profile
> manager. It then continues to set up the RFCOMM connection with the headset
> and hooks into some of the existing code for setting up the
> card/source/sinks and set up the SCO transport. See first commits of [0]
> 
>  + Selfcontained solution and simple solution.
>  + can reuse some of the existing bluetooth module code
>  - needs to do communicate with AT commands, many of those are not relevant
> to
>    pulseaudio but to a telephony stack.

Only if you are talking about HFP, in case of HSP all AT command are audio
related so doing it in PA would actually make sense and in fact reduce the
latency.

>  - needs some fairly lowlevel socket code for setting up the SCO connection

Well the fd passed is a already a SCO socket or you are talking about bind +
listen logic? I was thinking that perhaps this could be handled by bluetoothd
as well and then maybe it delivered SCO fd via a second NewConnection.


> 4) Implement new daemon that handles headsets and exposes a new DBus API to
> be used by pulseaudio and the telephony stack. See daemon part in [2] and
> pulseaudio module in [3]
> 
>  + relatively straightforward
>  + we can expose API to let the telephony stack handle the AT commands
>  + we can let pulseaudio handle the audio
>  + separate pulseaudio module, no bluez knowledge needed
>  - new API, new system daemon, DBus config, SELinux rules to pass fds.
> 
> [0] http://cgit.freedesktop.org/~wtay/pulseaudio/log/?h=hfp-gateway
> [1] http://cgit.freedesktop.org/~wtay/bluez-profile/log/
> [2] http://cgit.freedesktop.org/~wtay/headset-daemon/
> [3] http://cgit.freedesktop.org/~wtay/pulseaudio/log/?h=headsetd
> 
> The way forward, in my opinion, is to make the headset devices available
> with a new DBus API. Either as a new service or through new Objects in the
> pulseaudio DBus service. 
> 
> A telephone stack should be able to discover and talk AT commands with the
> headsets but when it wants to make sound, it should go through the
> pulseaudio API. You might, for example, want to control the telephony stack
> with the handsfree headset but have the sound go somewhere else.
> 
> What do you think?

Well this is actually what oFono has been doing so I don't see why we need
another daemon, if the problem is that there is no telephony stack that can
handle HFP (e.g. desktop) then HSP can be used instead.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-bugs/attachments/20140808/4ea65f88/attachment.html>