← Back to team overview

ubuntu-phone team mailing list archive

Re: Defining the form factor of an Ubuntu Touch device

 

On 08.10.2015 15:08, Michael Zanetti wrote:


On 08.10.2015 14:57, Simon Fels wrote:
On 08.10.2015 14:30, Michał Sawicz wrote:
W dniu 08.10.2015 o 14:00, Simon Fels pisze:
A tablet stays a tablet. Having a modem included doesn't make it a
phone. The Bluetooth device class is meant to stay static for one device
forever. No dynamic changes. It is your first point to find out what
kind of Bluetooth device you've found.

Btw. that a tablet includes a GSM modem still doesn't say anything about
if it also allows you to do voice calls ... If we have a "phablet"
device then this needs to be categorized as a phone as it provides voice
call capabilities. See
https://www.bluetooth.org/en-us/specification/assigned-numbers/baseband
for some more details on the major and minor device classes we're
talking about here. Putting the device into the right major/minor class
is crucial as some car kits doesn't allow you to pair them only with
devices part of the phone device class...

Also what would be the benefit of having an option for the user to
override this?

I think you just wrote what would be the benefit - some car kits only
connect to phone devices. What if I wanted my 3G tablet (no voice, but
VoIP still works!) to connect to the car?

That would a use case, yes, but still really a workaround for a corner
case.

However that wouldn't work with our implementation playing the role of
the audio gateway strictly requires a modem with voice call
capabilities.. no way to inject your VoIP stack here. It also hardly
depends on how the hardware is build. For HFP on most Android devices
the audio is directly routed from the microphone to the BT chip without
involving the CPU so we can gurantee you're even able to inject your
VoIP audio data.

Hmm... wouldn't be so sure about that.. Yes, HFP's control channel is
based on AT commands, and it's also correct that most hardware wires the
sound chip with the Bluetooth chip directly, still, every Bluetooth chip
I came across so far allowed routing audio data through the HCI. AFAIK,
bypassing the HCI is the optional case here. I did see dummy AT command
layers injecting VoIP into HFP before...

On Android devices that is the regular case. The audio data is passed to the BT chip over a PCM line rather than through HCI. That still doesn't say it's not possible to do it but that is a way nobody tested yet and proved it works.

In our current setup we're using the PCM line approach which also saves us from burning CPU cycles on this rather than letting the BT chip which is optimised for this doing that.

The next bigger point is how HFP is currently implemented. With the shift to BlueZ 5 the implementation moved into ofono as that is the natural place where you want to do AT command processing. The current implementation expects a voice call capable modem to be present before we even even allow the HFP AG profile to be connected. As there can be only one provider in the system for a profile we would have to integrate what VoIP solution we want to use over HFP into ofono to let it expose a modem which we can use as control interface ... However that doesn't say that we can add another provider for the HFP profile which becomes active in scenarios where we don't have a GSM modem but then has to implement the whole profile support on its own with the point of proper audio routing still being sorted.

regards,
Simon


Follow ups

References