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

[Georg Chini]

On 29.04.20 00:03, Pali Rohár wrote:

On Tuesday 28 April 2020 21:52:55 Georg Chini wrote:

On 28.04.20 21:06, Pali Rohár wrote:

On Tuesday 28 April 2020 20:50:33 Georg Chini wrote:

Personally I don't see a problem to remove the AG role support from
the ofono backend because nobody uses it. What I proposed earlier
- allow hsphfpd to disable the HFP HS role and keep a "legacy" ofono
backend for the HFP HS role - should not be that hard to implement
compared to all the time and work you already invested and it would
help us to keep users happy.

As I said, I have no problems with allowing to disable particular
profile from hsphpfd. But the way how ofono has it implemented, when it
is not possible to unregister specific profile and it always register
master SCO listening socket, it means that you cannot have two
applications which would implement or register HSP or HFP profile for
audio, independently of the role.

So you cannot use ofono's HFP AG role for connecting mobile phone and
other application (e.g. hsphpfd) for using HFP HS role for connecting
headset.

Sorry, forgive my ignorance. You can switch off ofonos AG role,
in that case it will only register the HS role with bluetoothd and
only react to connection attempts with the specific UUID.
Is it not possible that ofono registers one role and hsphfpd the
other?

Via --noplugin you specify which ofono plugins would not be loaded. So
you can instruct ofono to not register HF or AG role of HFP to
bluetoothd, which cause that bluetoothd does not create new RFCOMM
connection for particular profile UUID. So registering / unregistering
of UUIF can be done by restarting ofono with different parameters.

But for HSP and HFP this is not enough! SCO listening master socket is
created by ofono if at least one of HF or AG role plugin is loaded. And
you cannot control this behavior as ofono does not have API for it.


And even if it is not possible and you can't use both at the same
time (which would be a pity)

No it is not possible. It is even not possible to have one application
with HSP HS and one with HFP AG (see difference HSP and HFP, even
different profile is not possible).


That is definitely possible. This is how I have had working basic
headset support + mobile support for the last couple of years.
After switching off the AG role in ofono, a mobile will connect
to HFP provided by ofono while a headset connects to HSP
provided by the native backend. And actually I don't want to loose
this functionality (though at the moment the new board I have
has a broken USB3 implementation so that I cannot use BT at all).



As I wrote is exactly same as if two applications want to listen on TCP
port 1234 and both applications wants to accept only socket with
specific parameters which can be deduced only after accepting socket.

SCO sockets are not managed by bluetoothd daemon, but by target agent
application which implements that particular profile.


we still have to respect if a user
thinks that for him a working implementation for his mobile is
more important than good headset support and therefore prefers
the ofono backend over any other backend.

So what you want is currently impossible. You have to first fix ofono
daemon, design and export API for it and then implement other side to
use that API.

And I'm explaining again that this is reason why to have one central
daemon which would implement HSP and HFP profiles and proxies needed
support / sockets to target applications.

If one application is stealing listening sockets and cannot be
configured to not do it, other applications are just out of luck.

It is same as if two UDP or TCP applications wants to listen on port
1234 and both want to accept new connections. Without full cooperative
environment it does not work. hsphfpd daemon is there to accept new
connections from both RFCOMM and SCO sockets and do all needed stuff
with it (pass to other application, or process data on it directly).


The point is, that the applications that support the new hsphfpd
not yet exist, so we have at least to support the status quo until
there is some alternative.

Are there other modem softwares? I can write e.g. simple application for
hsphfpd which exports socket as tty device (via pts kernel interface).
If there are working modem software which can use tty modem then could
access also modem exported in this way.


Well, ofono provides support for all kinds of modems, so it should
be possible still to use ofono. Actually the main target of ofono are
hardware modems and the HFP stuff is more like an add-on.

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

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

[Pali Rohár]

On Tuesday 28 April 2020 21:52:55 Georg Chini wrote:
> On 28.04.20 21:06, Pali Rohár wrote:
> > On Tuesday 28 April 2020 20:50:33 Georg Chini wrote:
> > > Personally I don't see a problem to remove the AG role support from
> > > the ofono backend because nobody uses it. What I proposed earlier
> > > - allow hsphfpd to disable the HFP HS role and keep a "legacy" ofono
> > > backend for the HFP HS role - should not be that hard to implement
> > > compared to all the time and work you already invested and it would
> > > help us to keep users happy.
> > As I said, I have no problems with allowing to disable particular
> > profile from hsphpfd. But the way how ofono has it implemented, when it
> > is not possible to unregister specific profile and it always register
> > master SCO listening socket, it means that you cannot have two
> > applications which would implement or register HSP or HFP profile for
> > audio, independently of the role.
> > 
> > So you cannot use ofono's HFP AG role for connecting mobile phone and
> > other application (e.g. hsphpfd) for using HFP HS role for connecting
> > headset.
> Sorry, forgive my ignorance. You can switch off ofonos AG role,
> in that case it will only register the HS role with bluetoothd and
> only react to connection attempts with the specific UUID.
> Is it not possible that ofono registers one role and hsphfpd the
> other?

Via --noplugin you specify which ofono plugins would not be loaded. So
you can instruct ofono to not register HF or AG role of HFP to
bluetoothd, which cause that bluetoothd does not create new RFCOMM
connection for particular profile UUID. So registering / unregistering
of UUIF can be done by restarting ofono with different parameters.

But for HSP and HFP this is not enough! SCO listening master socket is
created by ofono if at least one of HF or AG role plugin is loaded. And
you cannot control this behavior as ofono does not have API for it.

> And even if it is not possible and you can't use both at the same
> time (which would be a pity)

No it is not possible. It is even not possible to have one application
with HSP HS and one with HFP AG (see difference HSP and HFP, even
different profile is not possible).

As I wrote is exactly same as if two applications want to listen on TCP
port 1234 and both applications wants to accept only socket with
specific parameters which can be deduced only after accepting socket.

SCO sockets are not managed by bluetoothd daemon, but by target agent
application which implements that particular profile.

> we still have to respect if a user
> thinks that for him a working implementation for his mobile is
> more important than good headset support and therefore prefers
> the ofono backend over any other backend.
> > 
> > So what you want is currently impossible. You have to first fix ofono
> > daemon, design and export API for it and then implement other side to
> > use that API.
> > 
> > And I'm explaining again that this is reason why to have one central
> > daemon which would implement HSP and HFP profiles and proxies needed
> > support / sockets to target applications.
> > 
> > If one application is stealing listening sockets and cannot be
> > configured to not do it, other applications are just out of luck.
> > 
> > It is same as if two UDP or TCP applications wants to listen on port
> > 1234 and both want to accept new connections. Without full cooperative
> > environment it does not work. hsphfpd daemon is there to accept new
> > connections from both RFCOMM and SCO sockets and do all needed stuff
> > with it (pass to other application, or process data on it directly).
> > 
> The point is, that the applications that support the new hsphfpd
> not yet exist, so we have at least to support the status quo until
> there is some alternative.

Are there other modem softwares? I can write e.g. simple application for
hsphfpd which exports socket as tty device (via pts kernel interface).
If there are working modem software which can use tty modem then could
access also modem exported in this way.

-- 
Pali Rohár
pali.ro...@gmail.com
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

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

[Georg Chini]

On 28.04.20 21:06, Pali Rohár wrote:

On Tuesday 28 April 2020 20:50:33 Georg Chini wrote:

Personally I don't see a problem to remove the AG role support from
the ofono backend because nobody uses it. What I proposed earlier
- allow hsphfpd to disable the HFP HS role and keep a "legacy" ofono
backend for the HFP HS role - should not be that hard to implement
compared to all the time and work you already invested and it would
help us to keep users happy.

As I said, I have no problems with allowing to disable particular
profile from hsphpfd. But the way how ofono has it implemented, when it
is not possible to unregister specific profile and it always register
master SCO listening socket, it means that you cannot have two
applications which would implement or register HSP or HFP profile for
audio, independently of the role.

So you cannot use ofono's HFP AG role for connecting mobile phone and
other application (e.g. hsphpfd) for using HFP HS role for connecting
headset.

Sorry, forgive my ignorance. You can switch off ofonos AG role,
in that case it will only register the HS role with bluetoothd and
only react to connection attempts with the specific UUID.
Is it not possible that ofono registers one role and hsphfpd the
other?

And even if it is not possible and you can't use both at the same
time (which would be a pity), we still have to respect if a user
thinks that for him a working implementation for his mobile is
more important than good headset support and therefore prefers
the ofono backend over any other backend.


So what you want is currently impossible. You have to first fix ofono
daemon, design and export API for it and then implement other side to
use that API.

And I'm explaining again that this is reason why to have one central
daemon which would implement HSP and HFP profiles and proxies needed
support / sockets to target applications.

If one application is stealing listening sockets and cannot be
configured to not do it, other applications are just out of luck.

It is same as if two UDP or TCP applications wants to listen on port
1234 and both want to accept new connections. Without full cooperative
environment it does not work. hsphfpd daemon is there to accept new
connections from both RFCOMM and SCO sockets and do all needed stuff
with it (pass to other application, or process data on it directly).


The point is, that the applications that support the new hsphfpd
not yet exist, so we have at least to support the status quo until
there is some alternative.

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

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

[Pali Rohár]

On Tuesday 28 April 2020 20:50:33 Georg Chini wrote:
> Personally I don't see a problem to remove the AG role support from
> the ofono backend because nobody uses it. What I proposed earlier
> - allow hsphfpd to disable the HFP HS role and keep a "legacy" ofono
> backend for the HFP HS role - should not be that hard to implement
> compared to all the time and work you already invested and it would
> help us to keep users happy.

As I said, I have no problems with allowing to disable particular
profile from hsphpfd. But the way how ofono has it implemented, when it
is not possible to unregister specific profile and it always register
master SCO listening socket, it means that you cannot have two
applications which would implement or register HSP or HFP profile for
audio, independently of the role.

So you cannot use ofono's HFP AG role for connecting mobile phone and
other application (e.g. hsphpfd) for using HFP HS role for connecting
headset.

So what you want is currently impossible. You have to first fix ofono
daemon, design and export API for it and then implement other side to
use that API.

And I'm explaining again that this is reason why to have one central
daemon which would implement HSP and HFP profiles and proxies needed
support / sockets to target applications.

If one application is stealing listening sockets and cannot be
configured to not do it, other applications are just out of luck.

It is same as if two UDP or TCP applications wants to listen on port
1234 and both want to accept new connections. Without full cooperative
environment it does not work. hsphfpd daemon is there to accept new
connections from both RFCOMM and SCO sockets and do all needed stuff
with it (pass to other application, or process data on it directly).

-- 
Pali Rohár
pali.ro...@gmail.com
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

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

[Georg Chini]

On 28.04.20 19:08, Pali Rohár wrote:

On Tuesday 28 April 2020 19:25:12 Tanu Kaskinen wrote:

It's not helpful to repeat that the ofono code needs massive changes as
a precondition to having a hsphfpd backend without specifying those
changes, because it sounds so unlikely to be true. Later in your mail
you mentioned that the profile switching needs to be changed from
synchronous to asynchronous. Good, now there's something concrete to
discuss.

ofono API does not support closing and unregistering profile connection:
https://git.kernel.org/pub/scm/network/ofono/ofono.git/tree/doc/handsfree-api.txt
https://git.kernel.org/pub/scm/network/ofono/ofono.git/tree/doc/handsfree-audio-api.txt
Without it, it is not possible to implement coexistency. There is only
API for unregistring agent, which is not enough. ofono API does not
support HSP profiles at all.

So HSP and HSP profile switching is not possible to implement with this
backend.

Next problem is that this ofono API does not provide MTU of acquired SCO
socket. Without it it not possible to implement correct handling of
buffer sizes, which is e.g. used by my changes for hsphfpd
implementation.

I already wrote all those problems in previous emails and I really do
not want to copy+paste content of my previous emails.

ofono API is basically broken design for audio applications and proper
usage needs to be changed and fixed. But I already did it, and it is
what resulted in hsphfpd API.


I do not want to disagree that for some people it works, I have no
reason to not trust Georg that it works for him.


Even if hsphfpd could do everything that oFono does, it's a new
project, I'd call it experimental at this stage. I don't want to tell
users that they have to change their working software stack in order to
keep old features when updating to a new PulseAudio version.

If oFono is not working for you and you therefore can't test it, then
don't test it. Fixing existing bugs in oFono isn't your job. Just avoid
touching the oFono code as much as possible.

I really cannot implement and use hsphpfd backend coexistence with
current ofono backend. And I cannot implement (asynchronous) support for
profile switching between A2DP, HSP and HFP profile which I did in that
published code with current ofono backend. This profile switching is
required for hsphfpd and it is not possible to implement it without
touching and fixing ofono code. So this was also another reason why I
removed it from my WIP codebase.

Ok, so you need to change how profile switching works. Can you abstract
away the differences between asynchronous and synchronous profile
switching? Like call a different card_set_profile() implementation with
ofono (this is just an example).

Why? I said that I spent to much time with that ofono and I really do
not want to invest more time in ofono backend which is basically
incompatible with hsphpfd daemon.


To me it seems that it should be entirely possible to move the old
bluez-util.c code to the ofono backend for those parts that cause major
problems with adapting the ofono code. In the worst case the whole
bluetooth infrastructure and modules need to be duplicated, and I
really hope we don't have to go there, but that's still better than
removing functionality. 

Well, why you do not try to yourself? You are talking about it like
something easy to implement, debug and deliver to users.

I also spend too much time trying to fix internal pulseaudio HSP profile
implementation and every time I think it works, something else appeared
to be broken again. But finally I was able to do it.

Why you are still trying to keep this ofono backend as is as we know
that is cause interopability problems, have broken API for audio, ofono
community is not willing to fix it and maintain it and moreover there is
replacement in my new hsphpfd design?


Neither Tanu nor I want to say that things are easy and we both do not
expect you to fix the ofono backend. But people are using it to connect
their mobile and I have not seen many complaints concerning this.
The complaints are all about headset support which I agree is unusable
for the ofono backend and far from perfect for the native backend.

Personally I don't see a problem to remove the AG role support from
the ofono backend because nobody uses it. What I proposed earlier
- allow hsphfpd to disable the HFP HS role and keep a "legacy" ofono
backend for the HFP HS role - should not be that hard to implement
compared to all the time and work you already invested and it would
help us to keep users happy.

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

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

[Pali Rohár]

On Tuesday 28 April 2020 19:25:12 Tanu Kaskinen wrote:
> It's not helpful to repeat that the ofono code needs massive changes as
> a precondition to having a hsphfpd backend without specifying those
> changes, because it sounds so unlikely to be true. Later in your mail
> you mentioned that the profile switching needs to be changed from
> synchronous to asynchronous. Good, now there's something concrete to
> discuss.

ofono API does not support closing and unregistering profile connection:
https://git.kernel.org/pub/scm/network/ofono/ofono.git/tree/doc/handsfree-api.txt
https://git.kernel.org/pub/scm/network/ofono/ofono.git/tree/doc/handsfree-audio-api.txt
Without it, it is not possible to implement coexistency. There is only
API for unregistring agent, which is not enough. ofono API does not
support HSP profiles at all.

So HSP and HSP profile switching is not possible to implement with this
backend.

Next problem is that this ofono API does not provide MTU of acquired SCO
socket. Without it it not possible to implement correct handling of
buffer sizes, which is e.g. used by my changes for hsphfpd
implementation.

I already wrote all those problems in previous emails and I really do
not want to copy+paste content of my previous emails.

ofono API is basically broken design for audio applications and proper
usage needs to be changed and fixed. But I already did it, and it is
what resulted in hsphfpd API.

> > I do not want to disagree that for some people it works, I have no
> > reason to not trust Georg that it works for him.
> >
> > > Even if hsphfpd could do everything that oFono does, it's a new
> > > project, I'd call it experimental at this stage. I don't want to tell
> > > users that they have to change their working software stack in order to
> > > keep old features when updating to a new PulseAudio version.
> > > 
> > > If oFono is not working for you and you therefore can't test it, then
> > > don't test it. Fixing existing bugs in oFono isn't your job. Just avoid
> > > touching the oFono code as much as possible.
> > 
> > I really cannot implement and use hsphpfd backend coexistence with
> > current ofono backend. And I cannot implement (asynchronous) support for
> > profile switching between A2DP, HSP and HFP profile which I did in that
> > published code with current ofono backend. This profile switching is
> > required for hsphfpd and it is not possible to implement it without
> > touching and fixing ofono code. So this was also another reason why I
> > removed it from my WIP codebase.
> 
> Ok, so you need to change how profile switching works. Can you abstract
> away the differences between asynchronous and synchronous profile
> switching? Like call a different card_set_profile() implementation with
> ofono (this is just an example).

Why? I said that I spent to much time with that ofono and I really do
not want to invest more time in ofono backend which is basically
incompatible with hsphpfd daemon.

> To me it seems that it should be entirely possible to move the old
> bluez-util.c code to the ofono backend for those parts that cause major
> problems with adapting the ofono code. In the worst case the whole
> bluetooth infrastructure and modules need to be duplicated, and I
> really hope we don't have to go there, but that's still better than
> removing functionality.   

Well, why you do not try to yourself? You are talking about it like
something easy to implement, debug and deliver to users.

I also spend too much time trying to fix internal pulseaudio HSP profile
implementation and every time I think it works, something else appeared
to be broken again. But finally I was able to do it.

Why you are still trying to keep this ofono backend as is as we know
that is cause interopability problems, have broken API for audio, ofono
community is not willing to fix it and maintain it and moreover there is
replacement in my new hsphpfd design?

-- 
Pali Rohár
pali.ro...@gmail.com
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

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

[Tanu Kaskinen]

On Tue, 2020-04-28 at 16:12 +0200, Pali Rohár wrote:
> On Tuesday 28 April 2020 16:33:01 Tanu Kaskinen wrote:
> > On Tue, 2020-04-28 at 13:08 +0200, Pali Rohár wrote:
> > > On Tuesday 28 April 2020 13:57:42 Tanu Kaskinen wrote:
> > > > Just to chime in on the ofono removal issue: I'm also of the opinion
> > > > that removing ofono support is not an option.
> > > 
> > > Well, in this case you have 3 choices:
> > > 
> > > * Fix it yourself or find somebody who will work on it and would maintain 
> > > this code in future
> > > * Try asking ofono community to start cooperate and tell them start
> > >   working and fixing that pulseaudio ofono code (including future 
> > > maintenance)
> > > * Do not take my now fully working hsphpfd support in pulseaudio and do 
> > > not implement HSP and HFP profiles properly in pulseaudio at all
> > > 
> > > I'm not going to spend another time with ofono and its buggy audio
> > > support, I tried it and it was waste of time, and specially now when
> > > ofono community is not interested in cooperation; and I have working
> > > better alternative suitable also for supporting other parts (like
> > > battery support, input button support, etc...)
> > > 
> > > And... what is the purpose of buggy ofono backend support in pulseaudio,
> > > now when I provided better code HSP and HFP profiles?
> > 
> > Last year a Collabora developer made a patch that fixed a crash in the
> > oFono backend. I assume their customer is using PulseAudio with oFono,
> > so I would also assume that it's not so buggy that it's useless (and
> > indeed, Georg reports that it's working fine for him). oFono also
> > integrates HFP to the telephony stack, which hsphfpd doesn't do.
> 
> Also there are lot of users for which HFP profile via current ofono
> pulseaudio implementation does not work, see tons of bugs in issue
> tracker and tons of blames for pulseaudio and its totally broken and
> non-working microphone bluetooth support on internet forums. And I
> understand it, for majority of people it does not work.
> 
> Really look at reality, bluetooth microphone support in pulseaudio is
> worse then poor. And *nobody* did anything in pulseaudio for years.
> I was able to implement now everything related to bluetooth audio.

That's great, thank you for your work!

> Is that Collabora developer going to implement all missing, needed and
> broken stuff in next days? Or at least next weeks/months? If not, who
> other is going to handle all those bluetooth problems? Or do you think
> that everything is working fine and there is no need to do anything with
> bluetooth related code?

It's not helpful to repeat that the ofono code needs massive changes as
a precondition to having a hsphfpd backend without specifying those
changes, because it sounds so unlikely to be true. Later in your mail
you mentioned that the profile switching needs to be changed from
synchronous to asynchronous. Good, now there's something concrete to
discuss.

> I do not want to disagree that for some people it works, I have no
> reason to not trust Georg that it works for him.
>
> > Even if hsphfpd could do everything that oFono does, it's a new
> > project, I'd call it experimental at this stage. I don't want to tell
> > users that they have to change their working software stack in order to
> > keep old features when updating to a new PulseAudio version.
> > 
> > If oFono is not working for you and you therefore can't test it, then
> > don't test it. Fixing existing bugs in oFono isn't your job. Just avoid
> > touching the oFono code as much as possible.
> 
> I really cannot implement and use hsphpfd backend coexistence with
> current ofono backend. And I cannot implement (asynchronous) support for
> profile switching between A2DP, HSP and HFP profile which I did in that
> published code with current ofono backend. This profile switching is
> required for hsphfpd and it is not possible to implement it without
> touching and fixing ofono code. So this was also another reason why I
> removed it from my WIP codebase.

Ok, so you need to change how profile switching works. Can you abstract
away the differences between asynchronous and synchronous profile
switching? Like call a different card_set_profile() implementation with
ofono (this is just an example).

To me it seems that it should be entirely possible to move the old
bluez-util.c code to the ofono backend for those parts that cause major
problems with adapting the ofono code. In the worst case the whole
bluetooth infrastructure and modules need to be duplicated, and I
really hope we don't have to go there, but that's still better than
removing functionality. 

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

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

[Pali Rohár]

On Tuesday 28 April 2020 16:33:01 Tanu Kaskinen wrote:
> On Tue, 2020-04-28 at 13:08 +0200, Pali Rohár wrote:
> > On Tuesday 28 April 2020 13:57:42 Tanu Kaskinen wrote:
> > > Just to chime in on the ofono removal issue: I'm also of the opinion
> > > that removing ofono support is not an option.
> > 
> > Well, in this case you have 3 choices:
> > 
> > * Fix it yourself or find somebody who will work on it and would maintain 
> > this code in future
> > * Try asking ofono community to start cooperate and tell them start
> >   working and fixing that pulseaudio ofono code (including future 
> > maintenance)
> > * Do not take my now fully working hsphpfd support in pulseaudio and do not 
> > implement HSP and HFP profiles properly in pulseaudio at all
> > 
> > I'm not going to spend another time with ofono and its buggy audio
> > support, I tried it and it was waste of time, and specially now when
> > ofono community is not interested in cooperation; and I have working
> > better alternative suitable also for supporting other parts (like
> > battery support, input button support, etc...)
> > 
> > And... what is the purpose of buggy ofono backend support in pulseaudio,
> > now when I provided better code HSP and HFP profiles?
> 
> Last year a Collabora developer made a patch that fixed a crash in the
> oFono backend. I assume their customer is using PulseAudio with oFono,
> so I would also assume that it's not so buggy that it's useless (and
> indeed, Georg reports that it's working fine for him). oFono also
> integrates HFP to the telephony stack, which hsphfpd doesn't do.

Also there are lot of users for which HFP profile via current ofono
pulseaudio implementation does not work, see tons of bugs in issue
tracker and tons of blames for pulseaudio and its totally broken and
non-working microphone bluetooth support on internet forums. And I
understand it, for majority of people it does not work.

Really look at reality, bluetooth microphone support in pulseaudio is
worse then poor. And *nobody* did anything in pulseaudio for years.
I was able to implement now everything related to bluetooth audio.

Is that Collabora developer going to implement all missing, needed and
broken stuff in next days? Or at least next weeks/months? If not, who
other is going to handle all those bluetooth problems? Or do you think
that everything is working fine and there is no need to do anything with
bluetooth related code?

I do not want to disagree that for some people it works, I have no
reason to not trust Georg that it works for him.

> Even if hsphfpd could do everything that oFono does, it's a new
> project, I'd call it experimental at this stage. I don't want to tell
> users that they have to change their working software stack in order to
> keep old features when updating to a new PulseAudio version.
> 
> If oFono is not working for you and you therefore can't test it, then
> don't test it. Fixing existing bugs in oFono isn't your job. Just avoid
> touching the oFono code as much as possible.

I really cannot implement and use hsphpfd backend coexistence with
current ofono backend. And I cannot implement (asynchronous) support for
profile switching between A2DP, HSP and HFP profile which I did in that
published code with current ofono backend. This profile switching is
required for hsphfpd and it is not possible to implement it without
touching and fixing ofono code. So this was also another reason why I
removed it from my WIP codebase.

I spend lot of time to understand how is that bluetooth related stuff
working, what is needed for implementation, designed it and implemented.
It is not easy task and I can say that I understand now all parts of
A2DP, HSP and HFP profiles, including how SCO and A2DP audio socket /
transfer works.

Do you think that I'm saying something which is wrong, does not make
sense or could be in better way? If yes, please show me it, so I can
improve that bluetooth parts.

-- 
Pali Rohár
pali.ro...@gmail.com
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

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

[Tanu Kaskinen]

On Tue, 2020-04-28 at 13:08 +0200, Pali Rohár wrote:
> On Tuesday 28 April 2020 13:57:42 Tanu Kaskinen wrote:
> > Just to chime in on the ofono removal issue: I'm also of the opinion
> > that removing ofono support is not an option.
> 
> Well, in this case you have 3 choices:
> 
> * Fix it yourself or find somebody who will work on it and would maintain 
> this code in future
> * Try asking ofono community to start cooperate and tell them start
>   working and fixing that pulseaudio ofono code (including future maintenance)
> * Do not take my now fully working hsphpfd support in pulseaudio and do not 
> implement HSP and HFP profiles properly in pulseaudio at all
> 
> I'm not going to spend another time with ofono and its buggy audio
> support, I tried it and it was waste of time, and specially now when
> ofono community is not interested in cooperation; and I have working
> better alternative suitable also for supporting other parts (like
> battery support, input button support, etc...)
> 
> And... what is the purpose of buggy ofono backend support in pulseaudio,
> now when I provided better code HSP and HFP profiles?

Last year a Collabora developer made a patch that fixed a crash in the
oFono backend. I assume their customer is using PulseAudio with oFono,
so I would also assume that it's not so buggy that it's useless (and
indeed, Georg reports that it's working fine for him). oFono also
integrates HFP to the telephony stack, which hsphfpd doesn't do.

Even if hsphfpd could do everything that oFono does, it's a new
project, I'd call it experimental at this stage. I don't want to tell
users that they have to change their working software stack in order to
keep old features when updating to a new PulseAudio version.

If oFono is not working for you and you therefore can't test it, then
don't test it. Fixing existing bugs in oFono isn't your job. Just avoid
touching the oFono code as much as possible.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

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

[Pali Rohár]

On Tuesday 28 April 2020 13:57:42 Tanu Kaskinen wrote:
> Just to chime in on the ofono removal issue: I'm also of the opinion
> that removing ofono support is not an option.

Well, in this case you have 3 choices:

* Fix it yourself or find somebody who will work on it and would maintain this 
code in future
* Try asking ofono community to start cooperate and tell them start
* working and fixing that pulseaudio ofono code (including future maintenance)
* Do not take my now fully working hsphpfd support in pulseaudio and do not 
implement HSP and HFP profiles properly in pulseaudio at all

I'm not going to spend another time with ofono and its buggy audio
support, I tried it and it was waste of time, and specially now when
ofono community is not interested in cooperation; and I have working
better alternative suitable also for supporting other parts (like
battery support, input button support, etc...)

And... what is the purpose of buggy ofono backend support in pulseaudio,
now when I provided better code HSP and HFP profiles?

-- 
Pali Rohár
pali.ro...@gmail.com
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

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

[Tanu Kaskinen]

On Tue, 2020-04-28 at 07:48 +0200, Georg Chini wrote:
> On 27.04.20 22:22, Pali Rohár wrote:
> > On Monday 27 April 2020 22:18:38 Georg Chini wrote:
> > > On 27.04.20 22:12, Pali Rohár wrote:
> > > > On Monday 27 April 2020 22:06:29 Georg Chini wrote:
> > > > > On 27.04.20 21:45, Georg Chini wrote:
> > > > > > On 27.04.20 01:44, Pali Rohár wrote:
> > > > > > > On Tuesday 31 March 2020 09:36:21 Georg Chini wrote:
> > > > > > > > One comment here: The hsphfpd should be able to co-exist with
> > > > > > > > ofono. ofono + PA currently is the only way you can use your 
> > > > > > > > mobile
> > > > > > > > on Linux and we should not break this (unless the hsphfpd 
> > > > > > > > supplies
> > > > > > > > the same functionality). So - similar to ofono - it should at 
> > > > > > > > least be
> > > > > > > > possible to switch off the corresponding role, so that ofono 
> > > > > > > > can be
> > > > > > > > used for one role and hsphfpd for the other.
> > > > > > > If you can disable HFP support in ofono, then hsphfpd and ofono 
> > > > > > > can
> > > > > > > coexist in system.
> > > > > > > 
> > > > > > > But coexistence of two HSP AG or HFP AG applications in system is
> > > > > > > impossible due to master listening SCO socket.
> > > > > > That is exactly my point. But you can have one application handle 
> > > > > > the
> > > > > > AG role while the other handles the HS role. For ofono mainly the HS
> > > > > > role is interesting, for PA mainly the AG role. Removing ofono 
> > > > > > completly
> > > > > > makes mobiles unusable under linux. In ofono, you can switch off
> > > > > > the AG role.
> > > > > You would only need an option so that hsphfpd does not register the HS
> > > > > role with bluetoothd and would need to keep the corresponding bits of 
> > > > > the
> > > > > ofono backend.
> > > > I can do this in hsphfpd daemon...
> > > > 
> > > > > That should not be much additional work and would not
> > > > > break the current use cases of the PA/ofono combination.
> > > > ... but I had to remove ofono backend from pulseaudio. Sorry it is
> > > > broken and I do not have power to fix ...
> > > The HS implementation is not broken but works very well.
> > My test results are different. (I spent more days with with this during
> > implementation of hsphfpd, integration into pulseaudio and
> > interoperability).
> > 
> It works well for me and for other people, so simply removing the 
> functionality
> is not an option in my opinion. If there are issues, they must be fixed, but
> that needs not be part of your patch set. Can you be a little bit more 
> specific
> what does not work?

Just to chime in on the ofono removal issue: I'm also of the opinion
that removing ofono support is not an option.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

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

[Georg Chini]

On 27.04.20 22:22, Pali Rohár wrote:

On Monday 27 April 2020 22:18:38 Georg Chini wrote:

On 27.04.20 22:12, Pali Rohár wrote:

On Monday 27 April 2020 22:06:29 Georg Chini wrote:

On 27.04.20 21:45, Georg Chini wrote:

On 27.04.20 01:44, Pali Rohár wrote:

On Tuesday 31 March 2020 09:36:21 Georg Chini wrote:

One comment here: The hsphfpd should be able to co-exist with
ofono. ofono + PA currently is the only way you can use your mobile
on Linux and we should not break this (unless the hsphfpd supplies
the same functionality). So - similar to ofono - it should at least be
possible to switch off the corresponding role, so that ofono can be
used for one role and hsphfpd for the other.

If you can disable HFP support in ofono, then hsphfpd and ofono can
coexist in system.

But coexistence of two HSP AG or HFP AG applications in system is
impossible due to master listening SCO socket.

That is exactly my point. But you can have one application handle the
AG role while the other handles the HS role. For ofono mainly the HS
role is interesting, for PA mainly the AG role. Removing ofono completly
makes mobiles unusable under linux. In ofono, you can switch off
the AG role.

You would only need an option so that hsphfpd does not register the HS
role with bluetoothd and would need to keep the corresponding bits of the
ofono backend.

I can do this in hsphfpd daemon...


That should not be much additional work and would not
break the current use cases of the PA/ofono combination.

... but I had to remove ofono backend from pulseaudio. Sorry it is
broken and I do not have power to fix ...

The HS implementation is not broken but works very well.

My test results are different. (I spent more days with with this during
implementation of hsphfpd, integration into pulseaudio and
interoperability).

It works well for me and for other people, so simply removing the 
functionality

is not an option in my opinion. If there are issues, they must be fixed, but
that needs not be part of your patch set. Can you be a little bit more 
specific

what does not work?

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

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

[Pali Rohár]

On Monday 27 April 2020 22:18:38 Georg Chini wrote:
> On 27.04.20 22:12, Pali Rohár wrote:
> > On Monday 27 April 2020 22:06:29 Georg Chini wrote:
> > > On 27.04.20 21:45, Georg Chini wrote:
> > > > On 27.04.20 01:44, Pali Rohár wrote:
> > > > > On Tuesday 31 March 2020 09:36:21 Georg Chini wrote:
> > > > > > One comment here: The hsphfpd should be able to co-exist with
> > > > > > ofono. ofono + PA currently is the only way you can use your mobile
> > > > > > on Linux and we should not break this (unless the hsphfpd supplies
> > > > > > the same functionality). So - similar to ofono - it should at least 
> > > > > > be
> > > > > > possible to switch off the corresponding role, so that ofono can be
> > > > > > used for one role and hsphfpd for the other.
> > > > > If you can disable HFP support in ofono, then hsphfpd and ofono can
> > > > > coexist in system.
> > > > > 
> > > > > But coexistence of two HSP AG or HFP AG applications in system is
> > > > > impossible due to master listening SCO socket.
> > > > That is exactly my point. But you can have one application handle the
> > > > AG role while the other handles the HS role. For ofono mainly the HS
> > > > role is interesting, for PA mainly the AG role. Removing ofono completly
> > > > makes mobiles unusable under linux. In ofono, you can switch off
> > > > the AG role.
> > > You would only need an option so that hsphfpd does not register the HS
> > > role with bluetoothd and would need to keep the corresponding bits of the
> > > ofono backend.
> > I can do this in hsphfpd daemon...
> > 
> > > That should not be much additional work and would not
> > > break the current use cases of the PA/ofono combination.
> > ... but I had to remove ofono backend from pulseaudio. Sorry it is
> > broken and I do not have power to fix ...
> 
> The HS implementation is not broken but works very well.

My test results are different. (I spent more days with with this during
implementation of hsphfpd, integration into pulseaudio and
interoperability).

-- 
Pali Rohár
pali.ro...@gmail.com
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

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

[Georg Chini]

On 27.04.20 22:12, Pali Rohár wrote:

On Monday 27 April 2020 22:06:29 Georg Chini wrote:

On 27.04.20 21:45, Georg Chini wrote:

On 27.04.20 01:44, Pali Rohár wrote:

On Tuesday 31 March 2020 09:36:21 Georg Chini wrote:

One comment here: The hsphfpd should be able to co-exist with
ofono. ofono + PA currently is the only way you can use your mobile
on Linux and we should not break this (unless the hsphfpd supplies
the same functionality). So - similar to ofono - it should at least be
possible to switch off the corresponding role, so that ofono can be
used for one role and hsphfpd for the other.

If you can disable HFP support in ofono, then hsphfpd and ofono can
coexist in system.

But coexistence of two HSP AG or HFP AG applications in system is
impossible due to master listening SCO socket.

That is exactly my point. But you can have one application handle the
AG role while the other handles the HS role. For ofono mainly the HS
role is interesting, for PA mainly the AG role. Removing ofono completly
makes mobiles unusable under linux. In ofono, you can switch off
the AG role.

You would only need an option so that hsphfpd does not register the HS
role with bluetoothd and would need to keep the corresponding bits of the
ofono backend.

I can do this in hsphfpd daemon...


That should not be much additional work and would not
break the current use cases of the PA/ofono combination.

... but I had to remove ofono backend from pulseaudio. Sorry it is
broken and I do not have power to fix ...


The HS implementation is not broken but works very well. I agree that
the AG implementation is broken. So from the ofono backend, only the
AG part needs to be removed. As far as I remember that is not much
and should not be that difficult to separate out.

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

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

[Pali Rohár]

On Monday 27 April 2020 22:06:29 Georg Chini wrote:
> On 27.04.20 21:45, Georg Chini wrote:
> > On 27.04.20 01:44, Pali Rohár wrote:
> > > On Tuesday 31 March 2020 09:36:21 Georg Chini wrote:
> > > > One comment here: The hsphfpd should be able to co-exist with
> > > > ofono. ofono + PA currently is the only way you can use your mobile
> > > > on Linux and we should not break this (unless the hsphfpd supplies
> > > > the same functionality). So - similar to ofono - it should at least be
> > > > possible to switch off the corresponding role, so that ofono can be
> > > > used for one role and hsphfpd for the other.
> > > If you can disable HFP support in ofono, then hsphfpd and ofono can
> > > coexist in system.
> > > 
> > > But coexistence of two HSP AG or HFP AG applications in system is
> > > impossible due to master listening SCO socket.
> > 
> > That is exactly my point. But you can have one application handle the
> > AG role while the other handles the HS role. For ofono mainly the HS
> > role is interesting, for PA mainly the AG role. Removing ofono completly
> > makes mobiles unusable under linux. In ofono, you can switch off
> > the AG role.
> 
> You would only need an option so that hsphfpd does not register the HS
> role with bluetoothd and would need to keep the corresponding bits of the
> ofono backend.

I can do this in hsphfpd daemon...

> That should not be much additional work and would not
> break the current use cases of the PA/ofono combination.

... but I had to remove ofono backend from pulseaudio. Sorry it is
broken and I do not have power to fix ...

> Like ofono, without the option, hsphfpd would register both roles.

-- 
Pali Rohár
pali.ro...@gmail.com
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

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

[Pali Rohár]

On Monday 27 April 2020 21:45:47 Georg Chini wrote:
> On 27.04.20 01:44, Pali Rohár wrote:
> > On Tuesday 31 March 2020 09:36:21 Georg Chini wrote:
> > > One comment here: The hsphfpd should be able to co-exist with
> > > ofono. ofono + PA currently is the only way you can use your mobile
> > > on Linux and we should not break this (unless the hsphfpd supplies
> > > the same functionality). So - similar to ofono - it should at least be
> > > possible to switch off the corresponding role, so that ofono can be
> > > used for one role and hsphfpd for the other.
> > If you can disable HFP support in ofono, then hsphfpd and ofono can
> > coexist in system.
> > 
> > But coexistence of two HSP AG or HFP AG applications in system is
> > impossible due to master listening SCO socket.
> 
> That is exactly my point. But you can have one application handle the
> AG role while the other handles the HS role. For ofono mainly the HS
> role is interesting, for PA mainly the AG role. Removing ofono completly
> makes mobiles unusable under linux. In ofono, you can switch off
> the AG role.

Well, this is one of the reason why central proxy daemon (like hsphfpd)
is needed for HSP and HFP profile, which just proxies relevant part of
HSP and HFP connections to relevant application. And reason why I
started with this design. It allows to implement both telephony and
audio parts independently in target application, audio in pulseaudio,
telephony in modem application, without any dependence between these two
applications.

Otherwise you would have to choose which application you want to use
either modem, either audio, either input device, either battery status,
but not all of them at the same time... This is one of the key feature
of hsphpfd to solve this problem.

-- 
Pali Rohár
pali.ro...@gmail.com
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

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

[Georg Chini]

On 27.04.20 21:45, Georg Chini wrote:

On 27.04.20 01:44, Pali Rohár wrote:

On Tuesday 31 March 2020 09:36:21 Georg Chini wrote:

One comment here: The hsphfpd should be able to co-exist with
ofono. ofono + PA currently is the only way you can use your mobile
on Linux and we should not break this (unless the hsphfpd supplies
the same functionality). So - similar to ofono - it should at least be
possible to switch off the corresponding role, so that ofono can be
used for one role and hsphfpd for the other.

If you can disable HFP support in ofono, then hsphfpd and ofono can
coexist in system.

But coexistence of two HSP AG or HFP AG applications in system is
impossible due to master listening SCO socket.


That is exactly my point. But you can have one application handle the
AG role while the other handles the HS role. For ofono mainly the HS
role is interesting, for PA mainly the AG role. Removing ofono completly
makes mobiles unusable under linux. In ofono, you can switch off
the AG role.


You would only need an option so that hsphfpd does not register the HS
role with bluetoothd and would need to keep the corresponding bits of the
ofono backend. That should not be much additional work and would not
break the current use cases of the PA/ofono combination.
Like ofono, without the option, hsphfpd would register both roles.

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

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

[Georg Chini]

On 27.04.20 01:44, Pali Rohár wrote:

On Tuesday 31 March 2020 09:36:21 Georg Chini wrote:

One comment here: The hsphfpd should be able to co-exist with
ofono. ofono + PA currently is the only way you can use your mobile
on Linux and we should not break this (unless the hsphfpd supplies
the same functionality). So - similar to ofono - it should at least be
possible to switch off the corresponding role, so that ofono can be
used for one role and hsphfpd for the other.

If you can disable HFP support in ofono, then hsphfpd and ofono can
coexist in system.

But coexistence of two HSP AG or HFP AG applications in system is
impossible due to master listening SCO socket.


That is exactly my point. But you can have one application handle the
AG role while the other handles the HS role. For ofono mainly the HS
role is interesting, for PA mainly the AG role. Removing ofono completly
makes mobiles unusable under linux. In ofono, you can switch off
the AG role.


___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

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

[Pali Rohár]

On Tuesday 31 March 2020 09:36:21 Georg Chini wrote:
> One comment here: The hsphfpd should be able to co-exist with
> ofono. ofono + PA currently is the only way you can use your mobile
> on Linux and we should not break this (unless the hsphfpd supplies
> the same functionality). So - similar to ofono - it should at least be
> possible to switch off the corresponding role, so that ofono can be
> used for one role and hsphfpd for the other.

If you can disable HFP support in ofono, then hsphfpd and ofono can
coexist in system.

But coexistence of two HSP AG or HFP AG applications in system is
impossible due to master listening SCO socket. It is same problem as
coexistence of two TCP applications which both want to listen on same
TCP port bound to wildcard address.

Coexistence of two "fully and correctly written" HSP AG or HFP AG
applications is possible only in the case these two applications know
about themselves and they properly register and unregister from bluez at
correct time and also they drop active connections, shutdown and close
all sockets at correct time.

After long debugging I was able to fix pulseaudio's internal HSP AG
implementation to correctly unregister when hsphfpd appear in the system
and register when hsphfpd disappear in the system.

So at least internal HSP AG implementation with lot of my patches could
be compatible with hsphfpd.

-- 
Pali Rohár
pali.ro...@gmail.com
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

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

[Pali Rohár]

On Tuesday 17 March 2020 13:06:52 Pali Rohár wrote:
> On Monday 16 March 2020 18:19:47 Tanu Kaskinen wrote:
> > On Sun, 2020-03-15 at 14:37 +0100, Pali Rohár wrote:
> > > 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).
> > 
> > I have not had time to discuss.
> > 
> > I think it makes sense to try the hsphfpd approach, if you're motivated
> > to write and maintain that all by yourself (plus the integration code
> > in PulseAudio). With luck you'll find someone to help, but I'm not
> > aware of anyone who has time for that.
> 
> As I said, I can develop integration code for pulseaudio too. And also I
> can maintain hsphfpd daemon.
> 
> I will try to find a time and prepare integration part for pulseaudio.

Done! Now I have working HSP and HFP profiles in pulseaudio via hsphfpd.
Also (asynchronous non-blocking) switching between them is working.

I pushed changes to hsphfpd branch of my pulseaudio fork repository:
https://gitlab.freedesktop.org/pali/pulseaudio/-/tree/hsphfpd

I opened also merge request for comments:
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/288

It is based on my A2DP changes. Please test it and let me know if there
are any problems.

Note that mere request is only WIP and therefore it lacks proper commit
messages, etc...

-- 
Pali Rohár
pali.ro...@gmail.com
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

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

[Georg Chini]

On 17.03.20 13:06, Pali Rohár wrote:

On Monday 16 March 2020 18:19:47 Tanu Kaskinen wrote:

On Sun, 2020-03-15 at 14:37 +0100, Pali Rohár wrote:

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).

I have not had time to discuss.

I think it makes sense to try the hsphfpd approach, if you're motivated
to write and maintain that all by yourself (plus the integration code
in PulseAudio). With luck you'll find someone to help, but I'm not
aware of anyone who has time for that.

As I said, I can develop integration code for pulseaudio too. And also I
can maintain hsphfpd daemon.

I will try to find a time and prepare integration part for pulseaudio.


Georg said that it doesn't make sense to implement this only for PA,
but if you get it to a working state, I don't see why PipeWire (and
maybe alsa-bluez) wouldn't use it too.

Ok.


There's one other approach, however, that you seem to reject for a
reason that is not clear to me: if I understood correctly the
discussion with the oFono developers[1], they're open to implementing
everything hsphfpd does in oFono.

There is a main rejection in design, that HSP and HFP cannot be in one
service and therefore on ofono side it needs to be on two separated
places, plus target audio application (pulseaudio) would need to
implement two separate services and endpoints, one for HSP and one for
HFP, even for audio part they are same.

In my hsphfpd API, there is just one service for both HSP and HFP
profiles and audio application needs to implement communication with
just one service which provides audio socket (either from HSP or HFP).


They said they're not planning to add
the missing features, but they didn't say they would reject patches.
For comparison, I'm not really planning to add any features to
PulseAudio either (no time for that), but that doesn't mean I reject
features implemented by other people than me.

Another thing against ofono: it is modem connection software. Why such
software needs to be requirement for desktop system which do not have
any cellular (or other) modem?

Also more people prefer to use other modem connection software, e.g.
ModemManager. Now if we add requirement that ofono is crucial part for
bluetooth, then there would be another problem: How to use ModemManager
on system with bluetooth head

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

[Stuart Naylor]

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

Sent from Mail for Windows 10


From: Pali Rohár 
Sent: Sunday, March 15, 2020 1:37:40 PM
To: pulseaudio-discuss@lists.freedesktop.org 

Cc: Georg Chini ; Russell Treleaven ; 
Luiz Augusto von Dentz ; Tanu Kaskinen ; 
Arun Raghavan ; David Heidelberg ; Pavel 
Machek ; Stuart Naylor ; 
emmanuel.fu...@laposte.net 
Subject: Re: Bluetooth HSP and HFP support in pulseaudio

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.ro...@gmail.com
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

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

[Pali Rohár]

On Monday 16 March 2020 18:19:47 Tanu Kaskinen wrote:
> On Sun, 2020-03-15 at 14:37 +0100, Pali Rohár wrote:
> > 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).
> 
> I have not had time to discuss.
> 
> I think it makes sense to try the hsphfpd approach, if you're motivated
> to write and maintain that all by yourself (plus the integration code
> in PulseAudio). With luck you'll find someone to help, but I'm not
> aware of anyone who has time for that.

As I said, I can develop integration code for pulseaudio too. And also I
can maintain hsphfpd daemon.

I will try to find a time and prepare integration part for pulseaudio.

> Georg said that it doesn't make sense to implement this only for PA,
> but if you get it to a working state, I don't see why PipeWire (and
> maybe alsa-bluez) wouldn't use it too.

Ok.

> There's one other approach, however, that you seem to reject for a
> reason that is not clear to me: if I understood correctly the
> discussion with the oFono developers[1], they're open to implementing
> everything hsphfpd does in oFono.

There is a main rejection in design, that HSP and HFP cannot be in one
service and therefore on ofono side it needs to be on two separated
places, plus target audio application (pulseaudio) would need to
implement two separate services and endpoints, one for HSP and one for
HFP, even for audio part they are same.

In my hsphfpd API, there is just one service for both HSP and HFP
profiles and audio application needs to implement communication with
just one service which provides audio socket (either from HSP or HFP).

> They said they're not planning to add
> the missing features, but they didn't say they would reject patches.
> For comparison, I'm not really planning to add any features to
> PulseAudio either (no time for that), but that doesn't mean I reject
> features implemented by other people than me.

Another thing against ofono: it is modem connection software. Why such
software needs to be requirement for desktop system which do not have
any cellula

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

[Tanu Kaskinen]

On Sun, 2020-03-15 at 14:37 +0100, Pali Rohár wrote:
> 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).

I have not had time to discuss.

I think it makes sense to try the hsphfpd approach, if you're motivated
to write and maintain that all by yourself (plus the integration code
in PulseAudio). With luck you'll find someone to help, but I'm not
aware of anyone who has time for that.

Georg said that it doesn't make sense to implement this only for PA,
but if you get it to a working state, I don't see why PipeWire (and
maybe alsa-bluez) wouldn't use it too.

There's one other approach, however, that you seem to reject for a
reason that is not clear to me: if I understood correctly the
discussion with the oFono developers[1], they're open to implementing
everything hsphfpd does in oFono. They said they're not planning to add
the missing features, but they didn't say they would reject patches.
For comparison, I'm not really planning to add any features to
PulseAudio either (no time for that), but that doesn't mean I reject
features implemented by other people than me.

Regarding the lack of time to discuss: I'm sorry it took this long to
get any input from me. Just staying up to date with everything
happening on GitLab, various mailing lists and IRC has taken almost all
my time. I have now decided to try allocating 20% of my PulseAudio time
for working on your bluetooth stuff. Georg has been in a similar
situation as you, so I'll give Georg another 20%, and even though
getting the 14.0 release out is supposed to be the highest priority
thing, that work hasn't progressed much lately either, so another 20%
goes there. Probably the end result is that I won't be able to keep up
with the GitLab messages any more, but it's worth trying...

[1] I've had to read the oFono discussion on the linux-bluetooth
mailing list, because your messages don't get through to the oFono
mailing list. Please subscribe to the list if you haven't done so yet
(and trim the Cc list, the messages get blocked due to that too), they
don't seem pay attention to the mailing list moderation queue.

-- 
Tanu

https://www.patreon.com/tanuk
h

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

[Pali Rohár]

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.ro...@gmail.com
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

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

[Pali Rohár]

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
> > 

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

[Georg Chini]

On 18.02.20 13:37, Pali Rohár wrote:

On Tuesday 18 February 2020 13:13:35 Georg Chini wrote:

On 18.02.20 11:29, Pali Rohár wrote:

On Tuesday 18 February 2020 11:06:03 Georg Chini wrote:

On 18.02.20 10:34, Pali Rohár wrote:

Hello!

On Tuesday 18 February 2020 09:42:38 Georg Chini wrote:

On 15.02.20 22:33, Pali Rohár wrote:

Hello!

More then two months ago I started discussion how to handle currently
unsupported parts of Bluetooth HSP and HFP profiles on Linux via
pulseaudio.

Main problems are:

1) These profiles are bound with telephony stack and without having half
   of telephony stack it is not possible to handle stable and working
   HFP profile. Telephony stack is needed for parsing AT commands and
   handling state machine.

There are several patch sets on gitlab and on the mailing list that
prove that you don't need half the telephony stack. Yes, you need
some of it but I think you overestimate what is really needed.

These patches does not work and completely break support for some
headsets which are currently working fine. Examples of such headsets are
from Creative Labs company. I already wrote it to pull request on
gitlab.

So no, this is not a solution, breaking support for headsets which are
currently working fine.

They are at least nearly working. Yes, they have some flaws
but with some work on them it can surely be improved.

They have important flaws, after they are integrated they completely
breaks support for headsets which are currently working. This is really
no-go.

But better to have a starting point than start from scratch.

Work
on the implementation is needed anyway and the old patches
on patchwork and the current ones on gitlab provide a good
starting point because a lot of the work is already done.

2) Only one application can own RFCOMM socket over which are transmitting
   AT commands.

3) Application which own socket needs to implement all features of HSP
   and HFP profiles. Therefore if users want to read battery status,
   this application needs to implement it. If users want to handle
   headset buttons, this application needs to implement it. And if users
   want to do telephony operations, this application needs to implement
   whole telephony stack.

Again I don't agree. There is no need to handle the whole telephony
stack if you only want headset support.

Unfortunately for some headsets it is needed :-(

I can't believe that.

Me too. But I already spend 3+ months in this area. During implementation
of hsphfpd and debugging more headsets I saw how they works, what they
implements and how to use it.

I still can't believe that not implementing all functionality renders

You still cannot believe it?

Then take free time for one half our year, starts collecting different
headsets, implement your own HFP profile implementation, start testing
it and come up with results.

I cannot say more about it.


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.

Maybe you have to supply some dummy answers
to certain AT commands, but it should be doable.

4) Wideband audio depends on HFP profile. Therefor 3), 2) and 1) must be
   solved if we want wideband high quality audio support for voice
   calls.

To solve these problems I proposed a new hsphfpd daemon which would
implement HSP and HFP profiles, therefore a new daemon which would own
rfcomm socket and would proxies AT commands (which could not resolve by
its own) to target applications. So telephony operations could be
implemented by one software (e.g. ofono), battery/power related by
another (e.g. upower) and audio by another (e.g. pulseaudio).

This design was rejected by ofono developers as they do not want to use
such proxy daemon. ofono already implements some parts of HFP profile
(but not HSP) and therefore is in the position of the "owner" of rfcomm
socket, like my design of hsphfpd. ofono already provides some API for
audio applications, but this API is not very suitable. I asked about
missing features and APIs which are designed and provided by hsphfpd,
but after a longer discussion ofono developer said that there are no
plans in ofono to implement missing features and APIs of HFP profile
which are currently missing in ofono. Also ofono's implementation of HFP
profile requires in computer to have connected and working cellular
modem, without it bluetooth HFP profile for bluetooth headsets does not
work. Pulseaudio has on wiki written some steps how to workar

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

[Pali Rohár]

On Tuesday 18 February 2020 13:13:35 Georg Chini wrote:
> On 18.02.20 11:29, Pali Rohár wrote:
> > On Tuesday 18 February 2020 11:06:03 Georg Chini wrote:
> > > On 18.02.20 10:34, Pali Rohár wrote:
> > > > Hello!
> > > > 
> > > > On Tuesday 18 February 2020 09:42:38 Georg Chini wrote:
> > > > > On 15.02.20 22:33, Pali Rohár wrote:
> > > > > > Hello!
> > > > > > 
> > > > > > More then two months ago I started discussion how to handle 
> > > > > > currently
> > > > > > unsupported parts of Bluetooth HSP and HFP profiles on Linux via
> > > > > > pulseaudio.
> > > > > > 
> > > > > > Main problems are:
> > > > > > 
> > > > > > 1) These profiles are bound with telephony stack and without having 
> > > > > > half
> > > > > >   of telephony stack it is not possible to handle stable and 
> > > > > > working
> > > > > >   HFP profile. Telephony stack is needed for parsing AT 
> > > > > > commands and
> > > > > >   handling state machine.
> > > > > There are several patch sets on gitlab and on the mailing list that
> > > > > prove that you don't need half the telephony stack. Yes, you need
> > > > > some of it but I think you overestimate what is really needed.
> > > > These patches does not work and completely break support for some
> > > > headsets which are currently working fine. Examples of such headsets are
> > > > from Creative Labs company. I already wrote it to pull request on
> > > > gitlab.
> > > > 
> > > > So no, this is not a solution, breaking support for headsets which are
> > > > currently working fine.
> > > They are at least nearly working. Yes, they have some flaws
> > > but with some work on them it can surely be improved.
> > They have important flaws, after they are integrated they completely
> > breaks support for headsets which are currently working. This is really
> > no-go.
> But better to have a starting point than start from scratch.
> > 
> > > Work
> > > on the implementation is needed anyway and the old patches
> > > on patchwork and the current ones on gitlab provide a good
> > > starting point because a lot of the work is already done.
> > > > > > 2) Only one application can own RFCOMM socket over which are 
> > > > > > transmitting
> > > > > >   AT commands.
> > > > > > 
> > > > > > 3) Application which own socket needs to implement all features of 
> > > > > > HSP
> > > > > >   and HFP profiles. Therefore if users want to read battery 
> > > > > > status,
> > > > > >   this application needs to implement it. If users want to 
> > > > > > handle
> > > > > >   headset buttons, this application needs to implement it. And 
> > > > > > if users
> > > > > >   want to do telephony operations, this application needs to 
> > > > > > implement
> > > > > >   whole telephony stack.
> > > > > Again I don't agree. There is no need to handle the whole telephony
> > > > > stack if you only want headset support.
> > > > Unfortunately for some headsets it is needed :-(
> > > I can't believe that.
> > Me too. But I already spend 3+ months in this area. During implementation
> > of hsphfpd and debugging more headsets I saw how they works, what they
> > implements and how to use it.
> I still can't believe that not implementing all functionality renders

You still cannot believe it?

Then take free time for one half our year, starts collecting different
headsets, implement your own HFP profile implementation, start testing
it and come up with results.

I cannot say more about it.

> 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).

> > 
> > > Maybe you have to supply some dummy answers
> > > to certain AT commands, but it should be doable.
> > > > > > 4) Wideband audio depends on HFP profile. Therefor 3), 2) and 1) 
> > > > > > must be
> > > > > >   solved if we want wideband high quality audio support for 
> > > > > > voice
> > > > > >   calls.
> > > > > > 
> > > > > > To solve these problems I proposed a new hsphfpd daemon which would
> > > > > > implement HSP and HFP profiles, therefore a new daemon which would 
> > > > > > own
> > > > > > rfcomm socket and would proxies AT commands (which could not 
> > > > > > resolve by
> > > > > > its own) to target applications. So telephony operations could be
> > > > > > implemented by one software (e.g. ofono), battery/power related by
> > > > > > another (e.g. upower) and audio by another (e.g. pulseaudio).
> > > > > > 
> > > > > > This design was rejected by ofono developers as they do not want to 
> > > > > > use
> > > > > > such proxy daemon

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

[Georg Chini]

On 18.02.20 11:29, Pali Rohár wrote:

On Tuesday 18 February 2020 11:06:03 Georg Chini wrote:

On 18.02.20 10:34, Pali Rohár wrote:

Hello!

On Tuesday 18 February 2020 09:42:38 Georg Chini wrote:

On 15.02.20 22:33, Pali Rohár wrote:

Hello!

More then two months ago I started discussion how to handle currently
unsupported parts of Bluetooth HSP and HFP profiles on Linux via
pulseaudio.

Main problems are:

1) These profiles are bound with telephony stack and without having half
  of telephony stack it is not possible to handle stable and working
  HFP profile. Telephony stack is needed for parsing AT commands and
  handling state machine.

There are several patch sets on gitlab and on the mailing list that
prove that you don't need half the telephony stack. Yes, you need
some of it but I think you overestimate what is really needed.

These patches does not work and completely break support for some
headsets which are currently working fine. Examples of such headsets are
from Creative Labs company. I already wrote it to pull request on
gitlab.

So no, this is not a solution, breaking support for headsets which are
currently working fine.

They are at least nearly working. Yes, they have some flaws
but with some work on them it can surely be improved.

They have important flaws, after they are integrated they completely
breaks support for headsets which are currently working. This is really
no-go.

But better to have a starting point than start from scratch.



Work
on the implementation is needed anyway and the old patches
on patchwork and the current ones on gitlab provide a good
starting point because a lot of the work is already done.

2) Only one application can own RFCOMM socket over which are transmitting
  AT commands.

3) Application which own socket needs to implement all features of HSP
  and HFP profiles. Therefore if users want to read battery status,
  this application needs to implement it. If users want to handle
  headset buttons, this application needs to implement it. And if users
  want to do telephony operations, this application needs to implement
  whole telephony stack.

Again I don't agree. There is no need to handle the whole telephony
stack if you only want headset support.

Unfortunately for some headsets it is needed :-(

I can't believe that.

Me too. But I already spend 3+ months in this area. During implementation
of hsphfpd and debugging more headsets I saw how they works, what they
implements and how to use it.

I still can't believe that not implementing all functionality renders
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.



Maybe you have to supply some dummy answers
to certain AT commands, but it should be doable.

4) Wideband audio depends on HFP profile. Therefor 3), 2) and 1) must be
  solved if we want wideband high quality audio support for voice
  calls.

To solve these problems I proposed a new hsphfpd daemon which would
implement HSP and HFP profiles, therefore a new daemon which would own
rfcomm socket and would proxies AT commands (which could not resolve by
its own) to target applications. So telephony operations could be
implemented by one software (e.g. ofono), battery/power related by
another (e.g. upower) and audio by another (e.g. pulseaudio).

This design was rejected by ofono developers as they do not want to use
such proxy daemon. ofono already implements some parts of HFP profile
(but not HSP) and therefore is in the position of the "owner" of rfcomm
socket, like my design of hsphfpd. ofono already provides some API for
audio applications, but this API is not very suitable. I asked about
missing features and APIs which are designed and provided by hsphfpd,
but after a longer discussion ofono developer said that there are no
plans in ofono to implement missing features and APIs of HFP profile
which are currently missing in ofono. Also ofono's implementation of HFP
profile requires in computer to have connected and working cellular
modem, without it bluetooth HFP profile for bluetooth headsets does not
work. Pulseaudio has on wiki written some steps how to workaround this
limitation by usage of modem simulator, but ofono developers wrote that
this is hack and should not be used at all. And HSP profile is not
supported at all.

So conclusion from ofono discussion is: They do not want to support my
proposed solution via hsphpfd. And also they do not plan to implement
missing features of HFP profile to their HFP implementations, like usage
of bluetooth headset without connected cellular modem into computers,
support for HSP profile, support for custom HSP and HFP audio codecs,
support for battery and input buttons, etc...

So ofono is fully unusable for any HSP or HFP features of bluetooth
headsets on regu

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

[Pali Rohár]

On Tuesday 18 February 2020 11:06:03 Georg Chini wrote:
> On 18.02.20 10:34, Pali Rohár wrote:
> > Hello!
> > 
> > On Tuesday 18 February 2020 09:42:38 Georg Chini wrote:
> > > On 15.02.20 22:33, Pali Rohár wrote:
> > > > Hello!
> > > > 
> > > > More then two months ago I started discussion how to handle currently
> > > > unsupported parts of Bluetooth HSP and HFP profiles on Linux via
> > > > pulseaudio.
> > > > 
> > > > Main problems are:
> > > > 
> > > > 1) These profiles are bound with telephony stack and without having half
> > > >  of telephony stack it is not possible to handle stable and working
> > > >  HFP profile. Telephony stack is needed for parsing AT commands and
> > > >  handling state machine.
> > > There are several patch sets on gitlab and on the mailing list that
> > > prove that you don't need half the telephony stack. Yes, you need
> > > some of it but I think you overestimate what is really needed.
> > These patches does not work and completely break support for some
> > headsets which are currently working fine. Examples of such headsets are
> > from Creative Labs company. I already wrote it to pull request on
> > gitlab.
> > 
> > So no, this is not a solution, breaking support for headsets which are
> > currently working fine.
> They are at least nearly working. Yes, they have some flaws
> but with some work on them it can surely be improved.

They have important flaws, after they are integrated they completely
breaks support for headsets which are currently working. This is really
no-go.

> Work
> on the implementation is needed anyway and the old patches
> on patchwork and the current ones on gitlab provide a good
> starting point because a lot of the work is already done.
> > 
> > > > 2) Only one application can own RFCOMM socket over which are 
> > > > transmitting
> > > >  AT commands.
> > > > 
> > > > 3) Application which own socket needs to implement all features of HSP
> > > >  and HFP profiles. Therefore if users want to read battery status,
> > > >  this application needs to implement it. If users want to handle
> > > >  headset buttons, this application needs to implement it. And if 
> > > > users
> > > >  want to do telephony operations, this application needs to 
> > > > implement
> > > >  whole telephony stack.
> > > Again I don't agree. There is no need to handle the whole telephony
> > > stack if you only want headset support.
> > Unfortunately for some headsets it is needed :-(
> I can't believe that.

Me too. But I already spend 3+ months in this area. During implementation
of hsphfpd and debugging more headsets I saw how they works, what they
implements and how to use it.

> Maybe you have to supply some dummy answers
> to certain AT commands, but it should be doable.
> > 
> > > > 4) Wideband audio depends on HFP profile. Therefor 3), 2) and 1) must be
> > > >  solved if we want wideband high quality audio support for voice
> > > >  calls.
> > > > 
> > > > To solve these problems I proposed a new hsphfpd daemon which would
> > > > implement HSP and HFP profiles, therefore a new daemon which would own
> > > > rfcomm socket and would proxies AT commands (which could not resolve by
> > > > its own) to target applications. So telephony operations could be
> > > > implemented by one software (e.g. ofono), battery/power related by
> > > > another (e.g. upower) and audio by another (e.g. pulseaudio).
> > > > 
> > > > This design was rejected by ofono developers as they do not want to use
> > > > such proxy daemon. ofono already implements some parts of HFP profile
> > > > (but not HSP) and therefore is in the position of the "owner" of rfcomm
> > > > socket, like my design of hsphfpd. ofono already provides some API for
> > > > audio applications, but this API is not very suitable. I asked about
> > > > missing features and APIs which are designed and provided by hsphfpd,
> > > > but after a longer discussion ofono developer said that there are no
> > > > plans in ofono to implement missing features and APIs of HFP profile
> > > > which are currently missing in ofono. Also ofono's implementation of HFP
> > > > profile requires in computer to have connected and working cellular
> > > > modem, without it bluetooth HFP profile for bluetooth headsets does not
> > > > work. Pulseaudio has on wiki written some steps how to workaround this
> > > > limitation by usage of modem simulator, but ofono developers wrote that
> > > > this is hack and should not be used at all. And HSP profile is not
> > > > supported at all.
> > > > 
> > > > So conclusion from ofono discussion is: They do not want to support my
> > > > proposed solution via hsphpfd. And also they do not plan to implement
> > > > missing features of HFP profile to their HFP implementations, like usage
> > > > of bluetooth headset without connected cellular modem into computers,
> > > > support for HSP profile, support for custom HSP and HFP audio codecs,
> > > > support for b

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

[Georg Chini]

On 18.02.20 10:34, Pali Rohár wrote:

Hello!

On Tuesday 18 February 2020 09:42:38 Georg Chini wrote:

On 15.02.20 22:33, Pali Rohár wrote:

Hello!

More then two months ago I started discussion how to handle currently
unsupported parts of Bluetooth HSP and HFP profiles on Linux via
pulseaudio.

Main problems are:

1) These profiles are bound with telephony stack and without having half
 of telephony stack it is not possible to handle stable and working
 HFP profile. Telephony stack is needed for parsing AT commands and
 handling state machine.

There are several patch sets on gitlab and on the mailing list that
prove that you don't need half the telephony stack. Yes, you need
some of it but I think you overestimate what is really needed.

These patches does not work and completely break support for some
headsets which are currently working fine. Examples of such headsets are
from Creative Labs company. I already wrote it to pull request on
gitlab.

So no, this is not a solution, breaking support for headsets which are
currently working fine.

They are at least nearly working. Yes, they have some flaws
but with some work on them it can surely be improved. Work
on the implementation is needed anyway and the old patches
on patchwork and the current ones on gitlab provide a good
starting point because a lot of the work is already done.



2) Only one application can own RFCOMM socket over which are transmitting
 AT commands.

3) Application which own socket needs to implement all features of HSP
 and HFP profiles. Therefore if users want to read battery status,
 this application needs to implement it. If users want to handle
 headset buttons, this application needs to implement it. And if users
 want to do telephony operations, this application needs to implement
 whole telephony stack.

Again I don't agree. There is no need to handle the whole telephony
stack if you only want headset support.

Unfortunately for some headsets it is needed :-(

I can't believe that. Maybe you have to supply some dummy answers
to certain AT commands, but it should be doable.



4) Wideband audio depends on HFP profile. Therefor 3), 2) and 1) must be
 solved if we want wideband high quality audio support for voice
 calls.

To solve these problems I proposed a new hsphfpd daemon which would
implement HSP and HFP profiles, therefore a new daemon which would own
rfcomm socket and would proxies AT commands (which could not resolve by
its own) to target applications. So telephony operations could be
implemented by one software (e.g. ofono), battery/power related by
another (e.g. upower) and audio by another (e.g. pulseaudio).

This design was rejected by ofono developers as they do not want to use
such proxy daemon. ofono already implements some parts of HFP profile
(but not HSP) and therefore is in the position of the "owner" of rfcomm
socket, like my design of hsphfpd. ofono already provides some API for
audio applications, but this API is not very suitable. I asked about
missing features and APIs which are designed and provided by hsphfpd,
but after a longer discussion ofono developer said that there are no
plans in ofono to implement missing features and APIs of HFP profile
which are currently missing in ofono. Also ofono's implementation of HFP
profile requires in computer to have connected and working cellular
modem, without it bluetooth HFP profile for bluetooth headsets does not
work. Pulseaudio has on wiki written some steps how to workaround this
limitation by usage of modem simulator, but ofono developers wrote that
this is hack and should not be used at all. And HSP profile is not
supported at all.

So conclusion from ofono discussion is: They do not want to support my
proposed solution via hsphpfd. And also they do not plan to implement
missing features of HFP profile to their HFP implementations, like usage
of bluetooth headset without connected cellular modem into computers,
support for HSP profile, support for custom HSP and HFP audio codecs,
support for battery and input buttons, etc...

So ofono is fully unusable for any HSP or HFP features of bluetooth
headsets on regular desktop or laptop computer with Linux.

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.

This is not true. You can disable the ofono headset support selectively
in ofono, so ofono could still handle telephony while PA handles headsets.

Ok, so if this is truth that you can disable ofono <--> bluetooth
support then you can still use your ce

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

[Pali Rohár]

Hello!

On Tuesday 18 February 2020 09:42:38 Georg Chini wrote:
> On 15.02.20 22:33, Pali Rohár wrote:
> > Hello!
> > 
> > More then two months ago I started discussion how to handle currently
> > unsupported parts of Bluetooth HSP and HFP profiles on Linux via
> > pulseaudio.
> > 
> > Main problems are:
> > 
> > 1) These profiles are bound with telephony stack and without having half
> > of telephony stack it is not possible to handle stable and working
> > HFP profile. Telephony stack is needed for parsing AT commands and
> > handling state machine.
> There are several patch sets on gitlab and on the mailing list that
> prove that you don't need half the telephony stack. Yes, you need
> some of it but I think you overestimate what is really needed.

These patches does not work and completely break support for some
headsets which are currently working fine. Examples of such headsets are
from Creative Labs company. I already wrote it to pull request on
gitlab.

So no, this is not a solution, breaking support for headsets which are
currently working fine.

> > 2) Only one application can own RFCOMM socket over which are transmitting
> > AT commands.
> > 
> > 3) Application which own socket needs to implement all features of HSP
> > and HFP profiles. Therefore if users want to read battery status,
> > this application needs to implement it. If users want to handle
> > headset buttons, this application needs to implement it. And if users
> > want to do telephony operations, this application needs to implement
> > whole telephony stack.
> Again I don't agree. There is no need to handle the whole telephony
> stack if you only want headset support.

Unfortunately for some headsets it is needed :-(

> > 4) Wideband audio depends on HFP profile. Therefor 3), 2) and 1) must be
> > solved if we want wideband high quality audio support for voice
> > calls.
> > 
> > To solve these problems I proposed a new hsphfpd daemon which would
> > implement HSP and HFP profiles, therefore a new daemon which would own
> > rfcomm socket and would proxies AT commands (which could not resolve by
> > its own) to target applications. So telephony operations could be
> > implemented by one software (e.g. ofono), battery/power related by
> > another (e.g. upower) and audio by another (e.g. pulseaudio).
> > 
> > This design was rejected by ofono developers as they do not want to use
> > such proxy daemon. ofono already implements some parts of HFP profile
> > (but not HSP) and therefore is in the position of the "owner" of rfcomm
> > socket, like my design of hsphfpd. ofono already provides some API for
> > audio applications, but this API is not very suitable. I asked about
> > missing features and APIs which are designed and provided by hsphfpd,
> > but after a longer discussion ofono developer said that there are no
> > plans in ofono to implement missing features and APIs of HFP profile
> > which are currently missing in ofono. Also ofono's implementation of HFP
> > profile requires in computer to have connected and working cellular
> > modem, without it bluetooth HFP profile for bluetooth headsets does not
> > work. Pulseaudio has on wiki written some steps how to workaround this
> > limitation by usage of modem simulator, but ofono developers wrote that
> > this is hack and should not be used at all. And HSP profile is not
> > supported at all.
> > 
> > So conclusion from ofono discussion is: They do not want to support my
> > proposed solution via hsphpfd. And also they do not plan to implement
> > missing features of HFP profile to their HFP implementations, like usage
> > of bluetooth headset without connected cellular modem into computers,
> > support for HSP profile, support for custom HSP and HFP audio codecs,
> > support for battery and input buttons, etc...
> > 
> > So ofono is fully unusable for any HSP or HFP features of bluetooth
> > headsets on regular desktop or laptop computer with Linux.
> > 
> > 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.
> 
> This is not true. You can disable the ofono headset support selectively
> in ofono, so ofono could still handle telephony while PA handles headsets.

Ok, so if this is truth that you can disable ofono <--> bluetooth
support then you can still use your cellular modem to work with ofono
(which is great!), but obviously you loose telephony support on HFP
bluetooth profile. And therefore without telephony support on HFP you
cannot use HFP nor 

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

[Georg Chini]

On 15.02.20 22:33, Pali Rohár wrote:

Hello!

More then two months ago I started discussion how to handle currently
unsupported parts of Bluetooth HSP and HFP profiles on Linux via
pulseaudio.

Main problems are:

1) These profiles are bound with telephony stack and without having half
of telephony stack it is not possible to handle stable and working
HFP profile. Telephony stack is needed for parsing AT commands and
handling state machine.

There are several patch sets on gitlab and on the mailing list that
prove that you don't need half the telephony stack. Yes, you need
some of it but I think you overestimate what is really needed.


2) Only one application can own RFCOMM socket over which are transmitting
AT commands.

3) Application which own socket needs to implement all features of HSP
and HFP profiles. Therefore if users want to read battery status,
this application needs to implement it. If users want to handle
headset buttons, this application needs to implement it. And if users
want to do telephony operations, this application needs to implement
whole telephony stack.

Again I don't agree. There is no need to handle the whole telephony
stack if you only want headset support.


4) Wideband audio depends on HFP profile. Therefor 3), 2) and 1) must be
solved if we want wideband high quality audio support for voice
calls.

To solve these problems I proposed a new hsphfpd daemon which would
implement HSP and HFP profiles, therefore a new daemon which would own
rfcomm socket and would proxies AT commands (which could not resolve by
its own) to target applications. So telephony operations could be
implemented by one software (e.g. ofono), battery/power related by
another (e.g. upower) and audio by another (e.g. pulseaudio).

This design was rejected by ofono developers as they do not want to use
such proxy daemon. ofono already implements some parts of HFP profile
(but not HSP) and therefore is in the position of the "owner" of rfcomm
socket, like my design of hsphfpd. ofono already provides some API for
audio applications, but this API is not very suitable. I asked about
missing features and APIs which are designed and provided by hsphfpd,
but after a longer discussion ofono developer said that there are no
plans in ofono to implement missing features and APIs of HFP profile
which are currently missing in ofono. Also ofono's implementation of HFP
profile requires in computer to have connected and working cellular
modem, without it bluetooth HFP profile for bluetooth headsets does not
work. Pulseaudio has on wiki written some steps how to workaround this
limitation by usage of modem simulator, but ofono developers wrote that
this is hack and should not be used at all. And HSP profile is not
supported at all.

So conclusion from ofono discussion is: They do not want to support my
proposed solution via hsphpfd. And also they do not plan to implement
missing features of HFP profile to their HFP implementations, like usage
of bluetooth headset without connected cellular modem into computers,
support for HSP profile, support for custom HSP and HFP audio codecs,
support for battery and input buttons, etc...

So ofono is fully unusable for any HSP or HFP features of bluetooth
headsets on regular desktop or laptop computer with Linux.

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.


This is not true. You can disable the ofono headset support selectively
in ofono, so ofono could still handle telephony while PA handles headsets.



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 b

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

[Pali Rohár]

Hello!

More then two months ago I started discussion how to handle currently
unsupported parts of Bluetooth HSP and HFP profiles on Linux via
pulseaudio.

Main problems are:

1) These profiles are bound with telephony stack and without having half
   of telephony stack it is not possible to handle stable and working
   HFP profile. Telephony stack is needed for parsing AT commands and
   handling state machine.

2) Only one application can own RFCOMM socket over which are transmitting
   AT commands.

3) Application which own socket needs to implement all features of HSP
   and HFP profiles. Therefore if users want to read battery status,
   this application needs to implement it. If users want to handle
   headset buttons, this application needs to implement it. And if users
   want to do telephony operations, this application needs to implement
   whole telephony stack.

4) Wideband audio depends on HFP profile. Therefor 3), 2) and 1) must be
   solved if we want wideband high quality audio support for voice
   calls.

To solve these problems I proposed a new hsphfpd daemon which would
implement HSP and HFP profiles, therefore a new daemon which would own
rfcomm socket and would proxies AT commands (which could not resolve by
its own) to target applications. So telephony operations could be
implemented by one software (e.g. ofono), battery/power related by
another (e.g. upower) and audio by another (e.g. pulseaudio).

This design was rejected by ofono developers as they do not want to use
such proxy daemon. ofono already implements some parts of HFP profile
(but not HSP) and therefore is in the position of the "owner" of rfcomm
socket, like my design of hsphfpd. ofono already provides some API for
audio applications, but this API is not very suitable. I asked about
missing features and APIs which are designed and provided by hsphfpd,
but after a longer discussion ofono developer said that there are no
plans in ofono to implement missing features and APIs of HFP profile
which are currently missing in ofono. Also ofono's implementation of HFP
profile requires in computer to have connected and working cellular
modem, without it bluetooth HFP profile for bluetooth headsets does not
work. Pulseaudio has on wiki written some steps how to workaround this
limitation by usage of modem simulator, but ofono developers wrote that
this is hack and should not be used at all. And HSP profile is not
supported at all.

So conclusion from ofono discussion is: They do not want to support my
proposed solution via hsphpfd. And also they do not plan to implement
missing features of HFP profile to their HFP implementations, like usage
of bluetooth headset without connected cellular modem into computers,
support for HSP profile, support for custom HSP and HFP audio codecs,
support for battery and input buttons, etc...

So ofono is fully unusable for any HSP or HFP features of bluetooth
headsets on regular desktop or laptop computer with Linux.

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.