Reason for BCM43438 no SCO over HCI

[Adam Langley]

Hi,

I am just evaluating my hardware choices, and am curious for the reason btstack doesn't support SCO over HCI with the BCM43438?

Given this is the chip on the Raspberry Pi 3, it's a very attractive option, but only if SCO over HCI can work at some point.

Is there a technical limitation, or simply it hasn't been prioritised?

Thanks

[Matthias Ringwald]

Hi Adam

I don't think there's a technical limitation. So far, it's a lack of information about how to tell the BCM43438 to enable SCO over HCI.

Do you know if SCO work on the Raspberry Pi 3? And if yes, if the SCO goes over HCI or over the I2S/PCM interface of the Bluetooth chip?

I've looked at the bluez sources and and found commands to configure SCO to be routed over HCI. However, it didn't work. The commands are listed here:

https://github.com/mixtile/broadcom-bluetooth/blob/master/brcm_patchram_plus_usb.c

I've then posted on the Broadcom forum (no response useful response) and even managed to asked a Broadcom field application engineer, but I only got the same information as from the sources above but no suggestions what I might have done wrong. I'm wondering if there's some kind of order like: first do a reset, then send the command, do another reset.

My impression is that usually people just uses SCO via the I2S/PCM of the Bluetooth as they need to process the audio anyway, so it's easier to connect that to some DAC converter instead of first receiving the data on the host cpu and then sending it out via I2S. The little detail here is that most chipsets cannot handle mSBC in the chip itself, and so processing by the CPU is mandatory. I guess people then look for proprietary solutions: TI's CC256x series can do mSBC itself, but only if BLE is not supported. CSR has advanced DSPs in their Bluetooth chips.

If you get additional information, I'm happy to have a look and run a quick test on the Redbear Duo.

best

 Matthias

--
You received this message because you are subscribed to the Google Groups "btstack-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to btstack-dev...@googlegroups.com.
To post to this group, send email to btsta...@googlegroups.com.
Visit this group at https://groups.google.com/group/btstack-dev.
For more options, visit https://groups.google.com/d/optout.

[Matthias Ringwald]

Wong URL: SCO config is explained here:

https://github.com/MentorEmbedded/broadcom-bluetooth/blob/master/brcm_patchram_plus.c

Begin forwarded message:

[Adam Langley]

Hi Matthias,

Thanks for the detailed information.

I have posted on the Pi forums to see if the 43438 is electrically connected to I2S, but have received no response yet.

People are having success configuring it for A2DP streaming, but I'm not sure if that has any impact on the situation. A2DP transferred quite differently to SCO isn't it?

Perhaps there is a more direct route to getting started for me:

My goal is to connect 2 HFP devices to one BT radio - which means that I need SCO over HCI, and it should be capable of delivering 2 SCO channels simultaneously.

I have been using the WT32i to date, but with their iWrap - which is limited to a single SCO (even though they support up to 3 SCO over HCI).

Hence, I am looking at a HCI solution instead - including a stack.

This is a side project, so I'd like to start with components I can just plug together for now. Reading the front page for BTStack, it mentions that CSR 8x10, 8x11 do not support SCO over HCI at this time. But further down is reads:

CSR USB Dongles

complete, incl. SCO-over-HCI

Which would suit me perfectly. However I have obtained a few "CSR4 dual mode" dongles, and they all used 8510 chips (I assume this is an 8x10...).

So finally...

1. Which USB dongles should I be looking for that are CSR4 dual mode and BTStack supports for SCO over HCI?
2. If I get one of these dongles, can I expect it will support 2 SCO channels to different devices simultaneously?
3. Finally, will your stack work, including SCO over HCI with Bluegiga modules? I believe they're based on the BC05 internally

Thanks Matthias,

Adam

[Matthias Ringwald]

Hi Adam

I'll give the BCM43438 another try: the first orders from the RedBear IoT HAT (http://redbear.cc/iot-phat/) will ship soon (and I'll get one by express) and it comes with blueZ support. Further more, the UART is conveniently  available on the pin headers.

A2DP is (roughly) similar to MP3 via RTSP over HTTP - it uses regular L2CAP data. Only HSP/HFP are special as they use synchronous data at 64 kbps.

As for getting two SCO channels via I2S, I wouldn't rule it out flatly, however, that would need proprietary support from the vendor as the Bluetooth standard doesn't even mention "I2S".

Still, I'd rather go with SCO over HCI.

The BTstack front page says that SCO-over-HCI doesn't work for CSR dongles connected via UART (H4/H5) - again, due to a lack of document or support by CSR. CSR flat out rejected my support request and sent me to my distributor, which in turn said that they cannot provide technical support - which I totally understand. The CSR USB dongles however are configured to route SCO over HCI by default, so that's what works.

With SCO over HCI over USB, the SCO data goes over Synchronous Endpoints, which can be tricky, too. I never tried two SCO streams, but that should be fixable if it doesn't work with the default USB configuration settings.

It works well enough for tests, so I'd recommend starting this on OS X or Linux with two CSR Bluetooth dongles any Bluetooth 4.0 one will work (and you will get the same chip inside anyway). TI provides full customer support and hence, BTstack works well with their CC256x chipsets.

I never tried the newer Bluetgiga modules, mostly because we didn't try a BTstack port for embedded devices with the Bluetooth controller connected via USB. Even then, I guess I'd just connect a regular USB Bluetooth dongle to the dev board. I would expect that BTstack will receive the data from all SCO connections via USB on any chipset that is configured for SCO-over-HCI.

Next: multiple HFP devices at the same time. The HFP Specification is a bit vague about this: it doesn't explicit forbids it, but all text talks about "The Hands-Free Unit" and "The Gateway".

From a technical point of view, there's no hard issues that would prevent it though. It's more like the semantic of some actions might be unclear (both devices dialing at the same time). Anyway it seems doable for the Gateway role. 

The Handsfree Role certainly will get chaotic if both Gateways have an ongoing call.

So, supporting multiple Handsfree units (well, there can only be up to 3 SCO connections anyway) could be possible, but will require some "fine tuning" of the stack.

Best

 Matthias

[Adam Langley]

Hi again Matthias,

I've been playing with one of the CSR 8510 USB dongles, and have had some success with the AG demo.

Can I expect to be able to make a SCO connection over USB with this dongle? That's H2, right?

Because I cannot achieve any audio connection to a handsfree unit with the demo.

After running the hfp_ag_demo, I choose "a" (establish HFP), which works.

I then choose "c" (simulate incoming call) - the handsfree flashes.

I then press the button on the handsfree and choose "b" (establish audio) - and it says "establish audio connection to..." but nothing happens.

Thanks,

Adam

[Matthias Ringwald]

Hi Adam

Yes, the CSR8510 should work for SCO audio. Yes H2 refers to Bluetooth over USB. The HFP AG demo has the address of the remote hard code in the beginning, so if you didn't update that one it will connect to a different device (which won't work..)

In the A2DP branch, we just added a small fix to use the BD ADDR of an incoming connection for the "b" establish audio.

If it doesn't work, feel free to post the packet log at /tmp/hci_dump.pklg.

Best

 Matthias

[Adam Langley]

Hi Matthias,

I've tried the A2DP branch with 2 scenarios, and collected dumps:

I am using CSR8510 over libusb on OSX.

hci_dump_establish_audio_no_response.pklg

1. start BTStack "HFP_AG_DEMO"
2. turn on handsfree device
3. handsfree device connects to BTStack
4. press "b" (establish audio)
5. BTStack no SCO established (no error)

hci_dump_simulate_call_accept_on_hf.pklg

1. start BTStack "HFP_AG_DEMO"
2. turn on handsfree device
3. handsfree device connects to BTStack
4. press "c" (simulate call)
5. press "accept call" hardware button on handsfree device
6. BTStack error

(output from test 2)

Establish HFP service level connection to PTS module 44:5E:F3:AA:85:05...
Service level connection established from 44:5E:F3:AA:85:05.
data: 00 48 00 05 85 AA F3 5E 44 01 
HF speaker gain = 8
AG: EC/NR = 0
Establish Audio connection 44:5E:F3:AA:85:05...
Simulate incoming call from 1234567
AG rings
HFP: ATA
ERROR, status: 11
HF answers call, accept call by GSM
ERROR, status: 17

 I have attached the dumps.

Thanks Matthias,

Adam

[Matthias Ringwald]

Hello Adam

It looks like your Handsfree unit does not support wide-band speech and we're developing the wide-band speech (mSBC) in that branch. There was a left-over overwrite that selected transparent air encoding, which doesn't work for narrow-band. Please pull and try again. :)

wide-band is almost working although we seem to miss something when sending mSBC audio - my iPhone disconnects and does not receive my test sine. We'll figure it out..

best

 Matthias

--
You received this message because you are subscribed to the Google Groups "btstack-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to btstack-dev...@googlegroups.com.
To post to this group, send email to btsta...@googlegroups.com.
Visit this group at https://groups.google.com/group/btstack-dev.
For more options, visit https://groups.google.com/d/optout.

<hci_dump_establish_audio_no_response.pklg><hci_dump_simulate_call_accept_on_hf.pklg>

[Adam Langley]

Hi Matthias,

Yes that makes sense - I knew the unit didn't support mSBC, however I have switched the code in the code to CVSD (I tried both in fact) with no difference.

I have pulled the latest in A2DP, but there are a couple of fixes required to compile:

src/classic/hfp_ag.c:614 is still passing "hfp_connection->negotiated_codec" in all calls to hfp_emit_connection_event

and src/classic/hfp_hf.c is doing the same.

When I fixed that, it compiled, however I now get a segfault when the HFP is initialized:

SCO Demo: Sending sine wave, hexdump received data.
SDP service record size: 102
BTstack up and running.

Service level connection established from 44:5E:F3:AA:85:05.

SCO Demo: creating wav file sco_input.wav, 0x7fff73f9e050
Segmentation fault: 11

I've attached my dump again.

Thanks Matthias,

Adam

[Matthias Ringwald]

Hi Adam

Thanks for mentioning the compile error. I was just fixing the SDP record and ran into that one as well as the crash for CVSD. Fixed, let's try again.

Best

 Matthias

<hci_dump.pklg>

[Adam Langley]

Hi Matthias,

Absolutely that has done the trick. I now get the sine audio on the handsfree.

I also have audio captured in the WAV file - it's VERY noisy audio - is it possible that noise reduction on the handsfree needs to be actively enabled?

Thanks,

Adam

[Matthias Ringwald]

Hi Adam

Glad you got the sine wave on the handsfree unit. About the noise: there are two independent sources:

- Standard HFP (CVSD codec) is 8 khz/8 bit + maybe the HF isn't too good?

- Packet loss/errors is rather high, last time I saw invalid data in 1 out of 10 packets.

If you like, please put the wav file somewhere and post the link to it for a quick check.

According to the HFP spec, the HF is supposed to enable Noise Reduction if it has such a feature. There's a command that the HF sends to the AG when Noise Reduction is deactivated (it's also supported in the hfp_hf_demo). There's no command that the AG could send to the HF related to Noise Reduction.

We're mostly done with implementing HFP (and it also passes the official tests), but still lack experience with different units and their behaviours.

Best

 Matthias