<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=Windows-1252"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="EN-GB" link="blue" vlink="#954F72"> <div class="WordSection1"> I dunno if this is a pulseaudio problem but it is a freedesktop problem as the current solution doesn’t work well and is huge bloat. Between Bluez and Pulseaudio HSP/HFP profiles probably should have the similar adoption as A2dp. Maybe with a2dp becoming more common on devices for bi-directional sound via BT5. Still not sure if that will just be the same situation as HSP/HFP with the additional at commands of mic pickup, Its highly likely worth looking at if something is on offer, as currently its doesn’t really work. Stuart <o:p> </o:p> Sent from <a href="https://go.microsoft.com/fwlink/?LinkId=550986"> Mail</a> for Windows 10 <o:p> </o:p> </div> <hr style="display:inline-block;width:98%" tabindex="-1"> <div id="divRplyFwdMsg" dir="ltr">From: Pali Rohár <pali.rohar@gmail.com> Sent: Sunday, March 15, 2020 1:37:40 PM To: pulseaudio-discuss@lists.freedesktop.org <pulseaudio-discuss@lists.freedesktop.org> Cc: Georg Chini <georg@chini.tk>; Russell Treleaven <rtreleaven@bunnykick.ca>; Luiz Augusto von Dentz <luiz.dentz@gmail.com>; Tanu Kaskinen <tanuk@iki.fi>; Arun Raghavan <arun@arunraghavan.net>; David Heidelberg <david@ixit.cz>; Pavel Machek <pavel@ucw.cz>; Stuart Naylor <stuartiannaylor@outlook.com>; emmanuel.fuste@laposte.net <emmanuel.fuste@laposte.net> Subject: Re: Bluetooth HSP and HFP support in pulseaudio <div> </div> </div> <div class="BodyFragment"> <div class="PlainText">Hello! One month passed and I have not answer which solution would pulseaudio choose for HSP and HFP support. Could you please really look at my email about state of HSP / HFP support? On Saturday 15 February 2020 22:33:10 Pali Rohár wrote: > If Linux desktop / laptop with pulseaudio want to support HFP profile > there are following options: > > 1) As written above, implement full HFP profile, therefore telephony > stack in pulseaudio and handle all users features in pulseaudio > (input devices, power devices, telephony features) including audio > features (wide band support, custom codec support). In this setup > pulseaudio would be incompatible with ofono and ofono must be stopped > on that computer to prevent ofono from taking rfcom socket. > > 2) Delegate all non-audio features of HSP and HFP profiles from 1) to > hsphfpd daemon and implement in pulseaudio only audio related > features via DBus API provided by hsphfpd daemon. In this setup > hsphfpd would own rfcom socket and via DBus API would communicate > with other applications (e.g. pulseaudio, upower). This setup is > incompatible with ofono, as ofono developers wrote that they do not > want to use this design and because ofono implements own handling of > HFP profiles, ofono daemon would need to be stopped on such machine > to prevent ofono from taking rfcom socket. So telephony functions would > not be supported until somebody write alternative telephony software > which would connect to hsphfpd as ofono devs do not want to use > hsphfpd. > > 3) In pulseaudio drop support for all desktop and laptop computers which > do not have connected cellular modem compatible with ofono. In this > way we could use ofono's HFP implementation for some basic audio > stuff. But no additional features (like battery status or input > buttons) would be provided. Also no custom codecs, etc. > > 4) In pulseaudio do not implement proper and full HFP profile support at > all. Just say to users, that if they want to use bluetooth HFP > headset, they have to change operating system from Linux to some > other which implement it. > > 5) Like 4) but be silent and do not say anything to users. Do not answer > to question from users about bluetooth HSP/HFP. Just do not do > anything. ... > So please, pulseaudio developers/maintainers, write what you think and > which option you choose and who would implement that option. Remember, > that silence means you automatically chose option 5) which would be rude > to all pulseaudio users. Does really silence mean that option 5) was automatically chosen? I hope that not. If you have not had time to discuss, compare and choose solution, please write at least that you are not going to choose option 5). -- Pali Rohár pali.rohar@gmail.com </div> </div> </body> </html>