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>
From:   Denis Kenzior <denkenz@gmail.com>
Message-ID: <57639029-7588-956b-8e3c-a2a6ed11b758@gmail.com>
Date:   Wed, 12 Feb 2020 15:29:04 -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: <20200108212537.zs6pesil2vjguvu6@pali>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Pali,

On 1/8/20 3:25 PM, Pali Rohár wrote:
> Hello!
> 

Somehow this went straight to my Junk folder, so I didn't see this 
message at all until now.

> 
> Audio application (e.g. pulseaudio) really do not want to handle two
> separate services to monitor and process HSP/HFP devices. >
> For audio application are HSP and HFP devices equivalent, they provide
> same features: SCO socket, API for controlling microphone and speaker
> gain; plus optionally specify used codec.
> 
> So having two separate services which fully divided for audio
> application purpose does not make sense.
> 
> So it is possible that both HSP and HFP audio cards would be available
> via one audio API? Because I do not see how it could be done via design
> like dundee.
> 

One API sure.  Maybe on multiple services.  Honestly, I don't see why 
this would be such a burden for PA to watch 2 dbus services instead of 
1.  From oFono perspective it would make more sense to keep the HSP part 
a separate daemon.  I could be convinced otherwise if it is indeed a big 
burden for PA...

>> You can then implement the same API interfaces for setting up the HSP audio
>> stream as oFono does today (i.e. https://git.kernel.org/pub/scm/network/ofono/ofono.git/tree/doc/handsfree-audio-api.txt),
> 
> This API is unusable for both HSP and HFP audio streams. In pulseaudio
> it is somehow used, but it is not suitable.
> 

Funny.  "It is used but not suitable"?

> 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. 
There's really no reason why we couldn't extend our APIs to handle this.

> 
> Another objection against handsfree-audio-api.txt API is that it is
> bound to HF codecs (via number) and does not support for pass e.g. CSR
> codecs.

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.

> 
> What is completely missing in that API is controlling volume level.
>

It is there on the CallVolume interface

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

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

Regards,
-Denis