Hi George! On Monday 09 December 2019 11:43:08 George Kiagiadakis wrote: > In general, I agree that HFP/HSP AT protocol handling is something that > the audio daemons should not have to worry about. However, I am > concerned with the level of fragmentation that exists in the bluetooth > stack. > > At the moment, the best case scenario is that we have 2 processes > involved in bluetooth audio (in the case where we route directly to/from > the speakers & microphone of the linux host in question): > > bluez5 <-> pulseaudio > > With pipewire & bluez-alsa, we have 3 processes: > > bluez5 <-> pipewire bluetooth session <-> pipewire daemon > > bluez5 <-> bluez-alsa <-> alsa application Yes, that is truth. > The 3 process separation here happens so that the bluetooth codecs run > in the process that sits in the middle. This avoids having to care about > codecs on the right side and also avoids slowing down the pipewire > daemon (so that it can still do low-latency audio processing) > > When ofono comes into play, we increase this by 1: > > bluez5 <-> ofono <-> pulseaudio > > bluez5 <-> ofono <-> pipewire bluetooth session <-> pipewire daemon > > bluez5 <-> ofono <-> bluez-alsa <-> alsa application Yes. > With your proposal, we have one more: > > bluez5 <-> hfphspd <-> ofono <-> pulseaudio > > bluez5 <-> hfphspd <-> ofono <-> pipewire bluetooth session <-> > pipewire daemon > > bluez5 <-> hfphspd <-> ofono <-> bluez-alsa <-> alsa application No, this is not how hsphpfd is suppose to work. Look at design & API: https://github.com/pali/hsphfpd-prototype/blob/prototype/hsphfpd.txt ofono would be there only in agent role, similar like audio daemon (pulseaudio/pipewire/bluez-alsa). So it would look like: +---- <-> ofono | bluez5 <-> hsphfpd | +---- <-> pulseaudio / pipewire / bluez-alsa You can connect / disconnect ofono without loosing audio functionality. (Or connect / disconnect audio daemon without loosing telephony modem functionality.) hsphfpd is central point for all HSP and HFP related operations and applications. > And it can become even more crazy when you do ugly hacks like what I > have done in Automotive Grade Linux, where I use bluez-alsa for its > codec implementation & HFP/HSP handling, and then route the audio using > a gstreamer-based helper process to the pipewire daemon process > (temporarily, to workaround issues in the pipewire native implementation): > > bluez5 <-> hfphspd <-> ofono <-> bluez-alsa <-> gstreamer helper <-> > pipewire daemon With hsphfpd involved, you would never talk with ofono. Also ofono is not required for this setup. > Instead of all of this crazy context switching, what I would prefer to > see is a standalone component library that someone could combine in a > single process to get things done. This would: > > * avoid re-implementing all kinds of stuff over and over in different > audio daemons (we do have 3 implementations atm: pulseaudio, pipewire & > bluez-alsa) HSP/HFP AT commands needed for audio handling are already designed to be handled by hsphfpd daemon. Please look at details. > * prevent people like me from doing ugly hacks to get work done > * improve collaboration between all the different people that care about > the bluetooth stack instead of having them antagonize each other This is reason why I started this discussion :) and proposed my hsphfpd daemon. > * avoid the context switching overkill; we should only have 1 process > between bluez and the audio daemon / solution, imho There is no context switching in hsphfpd design once audio connection is established. From hsphfpd you get native audio SCO socket, so audio is not routed throw hsphfpd nor bluez daemons. Socket directly pass data to kernel. > * potentially allow people to use some components in combination with a > proprietary bluetooth stack instead of bluez (a strong requirement in > the automotive industry at the moment, at least) The only what is needed is that "other stack" just export DBus interface for registering HSP and HFP profiles according to bluez documentation. Then hsphfpd would work with that bluetooth "other stack". > I imagine that this component library would include: > > * bluetooth audio codecs AT commands are covered by hsphfpd. Encoding / decoding of data is up to the application agent. Please look into hsphfpd.txt document. But creating a library which would do encoding and decoding of audio data and acts as a hsphfpd audio application agent is possible. If other projects want to use it (e.g. pulseaudio, bluez-alsa, pipewire, jack) we can start a separate discussion about API of such library. I guess that more audio daemons would be different requirements and to be usable in all projects we need to cover all of them. > * HFP/HSP commands handling This is already covered by hsphpfd. > * telephony handling In hsphfpd this is exported to external telephony agent. Possibly ofono or modem manager (whatever project will implement needed API and connects to hsphfpd daemon). > * exposure of common D-Bus APIs for side-channel things like power > management or phone dialing This is part of hsphfpd daemon, please look at hsphfpd.txt if it covers your needs. Btw, phone dialing is part of telephony handling. > ... and then every downstream user (pulse, pipewire, bluez-alsa, ...) > could reuse these components and implement the rest of the routing / > management logic in their own daemon. > > My two cents... > > Regards, > George -- Pali Rohár pali.rohar@xxxxxxxxx
