[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 #18 from wim.taymans at gmail.com <wim.taymans at gmail.com> ---
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.
 - needs some fairly lowlevel socket code for setting up the SCO connection

2) Make pulseaudio use the MediaEndpoint API. See next commits of [0]

 + simulates what bluez4 used to do
 + can reuse more of the existing code
 - more complicated, needs to have either pulseaudio do all async DBus calls or
   run the MediaEndpoint/Profile in separate threads. (I did not attempt this).
 - still need to handle AT commands and socket code
 - need to punch DBus holes for calling the MediaTransport API.

3) Implement the Profile in a separate program, calling the MediaEndpoint API
on pulseaudio to configure the stream. See last commits of [0] and [1] for the
daemon

 + more like what bluez4 used to do, can revive old headset code
 - need to simulate old bluez4 behaviour in the new app
 - still need to handle AT commands, can't easily have telephony stack take
over.
 - needs to punch DBus holes so that pulseaudio can call the app implementation
of the MediaTransport API.
 - needs more SELinux permissions to be able to pass fd from new app to
pulseaudio.

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?

-- 
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/517f661e/attachment.html>