<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#c23">Comment # 23</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:luiz.dentz@gmail.com" title="Luiz Augusto von Dentz <luiz.dentz@gmail.com>"> Luiz Augusto von Dentz</a> <pre>(In reply to <a href="show_bug.cgi?id=73325#c22">comment #22</a>) > > > > 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. > > Well almost, HSP has RING and the button press event. In practice you will > use HFP but theoretically, the phone stack could also do a RING on a pure > HSP headset. iirc RING is BT specific meaning a Telephony stack would not do anything with it, in fact I believe RING is more of an indication to the headset to play the ringtone if inband is not supported. > > > > > > - 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. > > I am talking about the bind + connect code. This is among things what got > removed from bluez5, you say it should be added again? It's really not > complicated but the main problem is that you would then need the bluez5 > headers to compile the module (and if you use any of the functions, also > link to bluez). Yep, I think we should avoid any extra dependency thus my suggestion to actually handle this in bluetoothd for HSP alone, for HFP we cannot do it because since version 1.6 it does have a much more complicated setup, one that involves codec negotiation via AT commands so the HFP entity has to have control over the SCO socket. > > > > 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. > > I have been looking at ofono as well but could not get this part to work. I > made a litte testapp to register an AudioAgent and wait for NewConnection() > but I could not make it work, no Cards showed up when I connected a headset. > The API looks like it would work. What do I need for this to work? Try with this one: <a href="https://gitorious.org/pulseaudio/vudentzs-mainline/commits/fceee2a876110186f8fdc87743e3ee7f7bf8c1ae">https://gitorious.org/pulseaudio/vudentzs-mainline/commits/fceee2a876110186f8fdc87743e3ee7f7bf8c1ae</a> Make sure you have compile it with --with-bluetooth-headset-backend=ofono and you must have a modem registered in oFono, apparently the modem cannot be a bluetooth one (e.g. a phone connected via BT) for some reason (possible a bug), without that oFono won't register for HFP Audio Gateway, for HFP Headset should work.</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>