Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: HSP/HFP ofono bluetooth support for Linux desktop
To:     =?UTF-8?Q?Pali_Roh=c3=a1r?= <pali.rohar@gmail.com>
Cc:     ofono@ofono.org, linux-bluetooth@vger.kernel.org
References: <20200107192311.efit6zftt27encdc@pali>
 <721332d3-336a-b9d2-f8cd-72da785fb9dc@gmail.com>
 <20200108212537.zs6pesil2vjguvu6@pali>
 <57639029-7588-956b-8e3c-a2a6ed11b758@gmail.com>
 <20200213174621.e2q4ryu36p5ericx@pali>
From:   Denis Kenzior <denkenz@gmail.com>
Message-ID: <6679dd2b-4780-e44f-b86d-28cf65638888@gmail.com>
Date:   Thu, 13 Feb 2020 12:14:06 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <20200213174621.e2q4ryu36p5ericx@pali>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Pali,

> Used by who? Gateway role is fully broken and client (hfp) role is used

I guess that depends on your perspective.  I've already pointed out that 
the desktop 'AG' use case was never something we needed to implement. 
If you want to fix oFono to do that, great.  If you want to write your 
own daemon to do this, also great.

> probably only by some power users. Also there is no support for mSBC in
> pusleaudio.

Why is oFono at fault for this?  Genuine question.  What are the 
roadblocks to mSBC support?

> 
> So, no, really it is not used.
> 
>>> Main objection for handsfree-audio-api.txt is that it does not provide
>>> information about locally used codec and somehow mixes air codec and
>>> local codec. In my hsphfpd.txt I used term "AgentCodec" for bluetooth
>>> local codec and term "AirCodec" for bluetooth air codec format.
>>
>> Okay.  But, just FYI, at the time there was no hw that could do such
>> on-the-fly conversions, so this use case wasn't considered/implemented.
> 
> This cannot be truth as probably every bluetooth HW is doing on-the-fly
> conversion between CVSD and PCM. I was not able to find HW which allows
> me to send raw CVSD samples...

At the time this was all done in software.  Alternatively, the hardware 
was directly wired between the sound card / modem and the bluetooth 
chip.  So just opening the SCO socket was enough.

>> True.  In retrospect we probably should have used strings.  But it was
>> assumed that vendor extensions would go via the Bluetooth SIG Assigned
>> Numbers facility.  Anyhow, we can always add a 'Register2' method that could
>> take codecs as a string array or a combination of strings & ints. And if
>> Register2 was used, then use 'NewConnection2' with a signature that supports
>> passing in vendor codecs and whatever else that might be needed.
> 
> This is still not enough. Audio application (e.g. pulseaudio) need to
> register AgentCodec, not AirCodec. And current API is somehow mixed.
> Audio application needs to know what is the format which bluetooth chip
> sends to userspace (PCM? mSBC? CVSD? PCMA? AuriStream?) and which format
> bluetooth chip expects. I named this AgentCodec.

So how do you negotiate the 'AgentCodec'?  Does BlueZ expose this 
information?  If so, how? SCO socket option or ...?

>>> And also API does not provide socket MTU information or ability to
>>> change/specify which codec would be used.
>>
>> There was no need, we automatically defaulted to using Wide band if
>> available.  Third party codecs are a new use case (for oFono HFP), so would
>> require an API extension.
> 
> MTU is needed also for mSBC codec if encoding is done in software
> (pulseaudio). Without it, this wide band support in ofono is unusable
> for pulseaudio.

Isn't the MTU obtained from the SCO socket itself?  How is oFono at 
fault here?

> 
> And also API extension for choosing codec. Also for choosing if software
> of hardware encoding would be used. We know that there are lot of broken
> devices in different way and it is really needed for either blacklist
> some codec or switch between hw and sw encoding if something strange
> happen. Without it pulseaudio is not going to support more codes then
> default required (CVSD).

This seems to be a kernel / device driver / firmware  issue and should 
be solved at that level.

> 
>>>
>>> Non-audio APIs which are needed to export (for both HSP and HFP profiles):
>>>
>>> * battery level (0% - 100%)
>>> * power source (external, battery, unknown)
>>> * ability to send "our laptop" battery level and power source to remote device
>>> * send text message to embedded display
>>> * process button press event (exported via linux kernel uinput)
>>>
>>
>> I think all of these are feasible to support under the current oFono
>> structure, either via plugins or API extensions.
> 
> Ok. Are you going to implement them?
> I think that all of these are missing parts in ofono and something which
> is needed to be implemented for desktop/laptop HSP and HFP profile
> support.
> 

There are no plans to do this at the moment.

Regards,
-Denis