[pulseaudio-discuss] Bluetooth HSP and HFP support in pulseaudio

Tue Feb 18 15:02:28 UTC 2020

On Tuesday 18 February 2020 15:29:02 Georg Chini wrote:
> On 18.02.20 13:37, Pali Rohár wrote:
> > > a headset useless. There must be ways to work around such broken
> > > implementations. Would those headsets then not also break with
> > > your hsphfpd if there is no application that handles the telephony
> > > stuff? If not, you obviously found a workaround already.
> > In hsphfpd I implemented small telephony stack which is used when there
> > is no application connected. It is just very simple, reject all
> > incoming calls, correctly send notifications that there is no active
> > call (for AT commands which may change internal telephony state).
> That's what I say. So there is a workaround.

"Workaround" is not a solution for something which is going to be
discussed how is going to be implemented.

But basically take what is needed (e.g. from my hsphfpd prototype code),
implement it... and you would ends up with half of working telephony
stack.

> > > I don't understand. What you loose are the telephony functions
> > > of the headset like re-dialing and nothing else. The telephone
> > > functionality of a headset cannot be implemented in an audio
> > > server anyway. See also my comments at the bottom.
> > You loose all functionality. HFP profile is implemented in ofono. If you
> > turn then plugin off, then you would loose whole HFP profile
> > functionality. Pulseaudio does not implement HFP profile. What you do
> > not understand on this fact?
> > 
> > If you turn off module which handles HFP profile, then you cannot
> > connect any HFP device to your computer as there is not running any
> > application which could be able to handle HFP profile. I really do not
> > know how to formulate this fact to be better understandable.
> I am only talking about the co-existence of ofono and PA. So you
> can use ofono to implement telephony on one device and you
> could (if it were implemented) use a headset with PA at the same
> time without interference. (If PA would implement a button press
> event, you could even pick up a call by sending the event to ofono.
> I implemented this myself a while ago.)

So this helps only in scenario when you have two devices, first you want
to use for telephony without audio and second one for audio without
telephony. Ok, I agree that this is useful and would work.

But it does not help with you want to use bluetooth HFP headset for both
audio and telephony at the same time...

> > > > Seems you misunderstood the point. The point is that if you implement
> > > > HFP profile in one application and HSP in second application, then you
> > > > need to implement common functionality on two different places.
> > > > 
> > > > So if HSP profile stay implemented in pulseaudio, you would have to
> > > > implement those missing functionality in pulseaudio.
> > > > And if HFP profile is implemented in ofono (or other application) then
> > > > missing functionality must be implemented in that ofono application.
> > > > 
> > > > So you would have implementation of e.g. power supply in two different
> > > > locations (for HSP in pulseaudio, for HFP in ofono). And this
> > > > functionality is basically same, so you would have to implement same
> > > > logic on two different places.
> > > > 
> > > > If you would need to extend it, you would have to do it again on two
> > > > different places.
> > > > 
> > > > In hsphfpd design, I implemented it on one place, in one daemon, which
> > > > shares common functions/code.
> > > All well, but it seems that actually none of the other audio stacks
> > > wants your hsphfpd.
> > Source please.
> > 
> > I got positive reactions about hsphfpd design except from ofono developers.
> I only saw reactions that boiled down to "feel free to implement it, might
> be nice,
> but we are not committing to use it" on the PA mailing list. But maybe I
> read what
> I wanted to read and maybe you got other reactions elsewhere.

That is from ofono developers who are not going to use it.

> > > > > The RFCOMM channel is created when the profile is connected,
> > > > > so it should be possible to have one RFCOMM to device A in AG role
> > > > > and another one to device B in HS role and have ofono handle one
> > > > > device while PA handles the other.
> > > > Seems you again misunderstood the main problem. Please look at my
> > > > hsphppfd email where I already tried to explain it. Via rfcomm socket
> > > > are handled all functionality of *one* device. I'm taking about one HFP
> > > > device which provides power supply, input event, text display, telephony
> > > > and audio functions. And all this can be handled only by application
> > > > which owns rfcomm socket, application which implements HFP profile.
> > > And where is the problem? We don't need (and can't implement)
> > > telephony functions of a headset in PA. Again, see below.
> > Telephony functions are part of HFP profile.
> > 
> > That *you* do not need it, does not mean that other Linux users do not
> > need it too.
> > 
> > For example I would really like to use buttons for telephony dialing
> > which are presents on bluetooth headsets.
> > 
> > Why other people, including me, should not be allowed to use it, just
> > because you decided "I do not need it, so other people do not need it
> > too, so we do not implement it"??
> I said above only that telephony functions do not belong into
> PA and should not be implemented in PA. Isn't that what you
> are saying as well all the time?

Yes, exactly. But because buttons on some headsets are bound with
telephony functions you would not have support for input events. And
because CSR extensions handles both telephony (SMS part) and codec
selection you would not have wide band CSR codec support without parts
of telephony stack. So implementation of these input events on some
headsets would need to be handled by same application which would
implement telephony functions. Similarly for CSR extensions and its
wideband audio codecs and SMS support and raw text on displays. And
there is also CSR extension for battery status reporting...

> > 
> > > > > > And you cannot share rfcom socket to more applications as it is
> > > > > > stateful. So what you wrote is not possible to implement. So this is a
> > > > > > big problem.
> > > > > > 
> > > > > > To allow splitting functionality between more applications I designed
> > > > > > hsphfpd daemon which acts like proxy for rfcomm bluetooth socket and
> > > > > > export needed functionality via DBus APIs to more applications, like you
> > > > > > described above. Please look at my email about hsphfpd where I written
> > > > > > more details about it.
> > > > > > 
> > > > > Yes, but it does not make sense to implement hsphfpd only for PA.
> > > > I wrote email about hsphfpd to other teams like bluez-alsa or pipewire
> > > > and they can benefit from it. Otherwise they would have to reimplement
> > > > and reimplement whole bluetooth related parts again and again. And
> > > > extending it for new futures...
> > > > 
> > > > > Then you can implement things directly in PA.
> > > > But why on the earth you would implement power supply, input event
> > > > handling, text displaying function, phone dialing functionality and
> > > > other things in audio server = pulseaudio?
> > > Why do you insist that we either have to implement all or nothing?
> > > My personal opinion is that we should implement the functionality
> > > that makes sense in the day-to-day usage of a headset. For me this
> > > mainly includes battery status and button press events. In addition
> > Some buttons are bound to telephony stack, so you in this case telephony
> > stack is needed. (Which buttons? This depends on headset).
> > 
> > > to that we could forward everything that we do not handle ourselves
> > > via D-Bus like your hsphfpd does, but that would already be a bit out
> > > of scope for an audio server. (Maybe something like this could be
> > > an additional module?)
> > So this means to move hsphfpd functionality into pulseaudio...
> Yes, the idea would be to start with what the audio stack needs
> and then maybe some day extend it, possibly in form of a module.

... and result would be same as in ofono's unusable HFP profile
implementation... No please do not repeat same design errors.

I already spend time to look deeply at this protocol stack, what is
there, how to split it into smaller parts and designed it in way that
can be easily extendable for future vendor extensions with focus on
common parts: audio, power, input, telephony and all other features
provided by the last HFP 1.7 specification; HSP specification; Apple
extensions and CSR extensions. Basically everything which is already
commonly used.

> That would be better than having a standalone daemon that is
> only supported by a single person and it would bring things forward.
> I am not sure however how the other maintainers would think of
> that.
> > 
> > > Telephony functionality does definitely not belong into PA, so I hope
> > > you do not misunderstand me. The thing is, that your hsphfpd is a
> > > very good idea but it seems like a lost cause to me because it comes
> > > years too late.
> > Why it is too late? On Linux we have not HFP implementation (except that
> > in ofono). So when talking how to implement it, it is a good time to do
> > it properly and not again in way which is not usable (like ofono's one).
> Doesn't the alsa bluetooth stuff also implement HFP?

It has own HFP implementation, support some features, but everything
written above (which are by hsphfpd design).

> > 
> > > On the other hand, I do not want that we just sit back
> > > and do nothing because "it is all too complicated".
> 
> 

-- 
Pali Rohár
pali.rohar at gmail.com