<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED --- - HSP not working in pulseaudio with BlueZ 5" href="https://bugs.freedesktop.org/show_bug.cgi?id=73325#c18">Comment # 18</a> on <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED --- - HSP not working in pulseaudio with BlueZ 5" href="https://bugs.freedesktop.org/show_bug.cgi?id=73325">bug 73325</a> from <a class="email" href="mailto:wim.taymans@gmail.com" title="wim.taymans@gmail.com <wim.taymans@gmail.com>"> wim.taymans@gmail.com</a> <pre>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] <a href="http://cgit.freedesktop.org/~wtay/pulseaudio/log/?h=hfp-gateway">http://cgit.freedesktop.org/~wtay/pulseaudio/log/?h=hfp-gateway</a> [1] <a href="http://cgit.freedesktop.org/~wtay/bluez-profile/log/">http://cgit.freedesktop.org/~wtay/bluez-profile/log/</a> [2] <a href="http://cgit.freedesktop.org/~wtay/headset-daemon/">http://cgit.freedesktop.org/~wtay/headset-daemon/</a> [3] <a href="http://cgit.freedesktop.org/~wtay/pulseaudio/log/?h=headsetd">http://cgit.freedesktop.org/~wtay/pulseaudio/log/?h=headsetd</a> 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?</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>