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