HFP Client SCO audio routing?

I’m trying to implement HFP Client on this board.

Since the board has no audio capabilities besides sending out to HDMI, I’m using a USB sound card, which seems to be working for everything (including a2dp), EXCEPT during a call.

I think that the audio routing policy is ok. Telecomm sees the USB as a “wired headset”, which it seems to be setting the routing up for during the call. I think there is a lower level problem…

EDIT:
I think I may be starting to understand what is going on here.
The BT PCM lines are on I2S2, which is shared with the HDMI and set up only as the default output. So even though the SCO channel is opened, the audio isn’t going anywhere.

So the question is where do I go to fix the bluetooth sound? Kernel? Or is this something with the audio routing in Android?

Bump…?

So it turns out that the bluetooth is hooked up to i2s2, which is shared with the HDMI. They’ve also got the i2s pins of the bluetooth chip set to high impedance (in a proprietary binary firmware file), and i2s2 is configured as output ONLY, with the SoC set as the master device.

A2DP is running over HCI, but SCO over HCI is disabled by default in Fluoride (formerly known as Bluedroid). I don’t know if the TI firmware will even send SCO over HCI, but I’m going to try enabling it in Fluoride and hope for the best.

I have an issue reported here; https://bugs.96boards.org/show_bug.cgi?id=664 but its temporarily stalled – Mr Xu appears to be from (lives in) Asia which makes discussing the topic somewhat challenging due to opposing sleep/wake cycles :S

It seems to be more a routing issue here, HFP/HSP profiles use SCO packets which are typically directly generated by the BT controller from I2S/PCM audio interface… Meaning BT controller needs to be configured with correct PCM information (typically through HCI vendor commands) and audio routed from/to the correct I2S interface. This is something which does not seem to be configured for now.

An other solution would be to send SCO packets over HCI instead, this requests to build Android BT stack (Fluoride) with HCI SCO support (BTM_SCO_HCI_INCLUDED).

Exactly. And I understand why the i2s is set up the way it is, but it would be extremely beneficial to have the option of setting it up to let the bluetooth have the i2s instead.

I’m going to attempt setting it up over HCI and cross my fingers that the TI firmware will actually send it there.

OK, does not seem to be straightforward, If I understand you will need at least a BT firmware update, BT PCM configuration and Audio routing/config changes on host side as well. I strongly suggest probing I2S with logical analyzer to see if routing/config (clock…) is correctly applied.

cf google/dragon/bluetooth/bdroid_buildcfg.h which defines/overwrite some flags for bt stack, I assume you need to add same file for hikey and define BTM_SCO_HCI_INCLUDED.

I definitely don’t have the equipment for probing the i2s, and the rest of it (SCO over i2s) is also a bit over my head :frowning:

But assuming that the firmware can do it, I’ll have no problem in configuring bdroid.

Of course it is just my luck that SCO over HCI is untested code and won’t even compile.

system/bt/bta/ag/bta_ag_sco.cc:1338:23: error: use of undeclared identifier ‘resp’

Edit: tried patching the first 4 errors, and its not even close to usable.

Whoa… too bad, you definitely need BT I2S…

Note that bluez-for-android can be used as replacement of Fluoride/Bluedroid but not sure it is compatible with Android master.

Their readme is a bit concerning, since it doesn’t mention anything above 5.1. Getting that working is probably a pretty deep rabbit hole. Best to get it working correctly (i2s), but I haven’t heard from Guodong Xu in a couple of days now, not that that implies that anything is wrong, just that its natural to feel a bit impatient.

So.

The device tree shows that its using simple-audio-card as the sound driver. Its currently got its codec set to the adv7533, which I presume is why its only reading as an output and not an input.

I’m having a hard time figuring out what to put in there, since the wl18xx driver doesn’t seem to implement an audio codec. bt-sco?

Does this look right?

	sco_codec: bt_sco {
		compatible = "linux,bt-sco";
	};

	sound {
		compatible = "simple-audio-card";
		simple-audio-card,name = "hikey-btsco";
		simple-audio-card,format = "i2s";

		simple-audio-card,bitclock-master = <&sound_master>;
		simple-audio-card,frame-master = <&sound_master>;

		simple-audio-card,cpu {
			sound-dai = <&i2s2>;
		};

		sound_master: simple-audio-card,codec {
			sound-dai = <&sco_codec>;
		};
	};

The wl18xx driver itself is totally out of the HFP/HSP audio path, the codec itself is implemented in BT controller. SoC<—I2S/PCM—>BT-CONTROLLER<—>AIR/SCO.

Thank you for confirming that.

Do you think, then, that bt-sco is the proper (fake) codec to feed into simple-audio-card?
https://android.googlesource.com/kernel/hikey-linaro/+/android-hikey-linaro-4.9/sound/soc/codecs/bt-sco.c

And you mentioned earlier about hooking up to a logic analyzer, do you think that this Saleae Logic 4 - 4 Channels Logic / 1 Channel Analog - Black : ID 2312 : $109.00 : Adafruit Industries, Unique & fun DIY electronics and kits along with a level shifter (txb0108) would be suitable?

Yes linux,bt-sco seems a really good candidate.

Yes that the idea, 3MHz is maybe a bit low (for general use cases), you can find much cheaper devices on the web with better sampling rate (~24Mhz).

That one is actually 12 MHz sample rate, which would make 4 samples per cycle for a peak capacity to measure an input signal of 3 MHz, which is about twice what a “CD quality” bit clock will run. With the phone sound running at 8 kHz, that puts the hard requirement at 256 kHz.

I was looking at cheaper units, but they seemed to be predominantly clones of older models of saleae units (and 2 month shipping from china on a ship), with the exception of dslogic, which look great on their spec sheet (16 channel at 100 MHz, 4 channel at 400 MHz)… but I’m not sure if they’re out of business or what, because every reputable vendor of those is showing out of stock, and their website and forums haven’t been updated in years.

I think I’ll stick with the saleae. They’ve got a decent reputation, and I can have it by tomorrow.

This is a good choice indeed ;-), now the question is how/where to probe, WL1837MOD pins look ‘relatively’ accessible but the schematics show four zero-ohm resistors (R934, R933, R917, R916) which could be good test-point candidates.

I was looking at cheaper units, but they seemed to be predominantly
clones of older models of saleae units (and 2 month shipping from
china on a ship), with the exception of dslogic, which look great on
their spec sheet (16 channel at 100 MHz, 4 channel at 400 MHz)… but
I’m not sure if they’re out of business or what, because every
reputable vendor of those is showing out of stock, and their website
and forums haven’t been updated in years.

[I’m can’t contribute much about BT but is we’re venturing briefly into logic analyzers… ]

There are a family of very cheap units tend to be those based around
the FX2 chips which are unusual in that they can DMA directly from the
I/O ports to the USB controller. This means they can achieve fairly high
data rates even with a simply micro-controller at their heart (and that
they never run out of storage buffer because they offload in real time
to the PC). They are also have first rate open source support in the
form of sigrok.

This is an example:

In fact there are lots of identical units on eBay that are even cheaper but they
tend to come with stolen software so I won’t
link to them.

Only warning is that I’ve never got mine to run at 24MHz for any length
of time… I’m running a rather weak PC and once I push the sample rate
about 4MHz the startup tends to get a little unreliable.

Barring any issues with customs, I should have my new probulator (genuine saleae 4 channel) some time today. I’m not entirely sure how to identify the resistors (R934, R933, R917, R916), since they aren’t marked on the board, and there are no layout files for it. But I think I can get at the pins on the WL18 with something thin and pointy (sewing pins?) but I probably won’t be able to scan any more than 2 pins at a time.

@danielt yeah, those are the ones I’ve been seeing around everywhere, and like you said, they come with stolen software generally, and even if not, they’re built for the purpose of pirating saleae software. While I greatly prefer open source, I’ve really become frustrated with the overseas manufacturing of half baked knock-offs with extremely poor quality control, and rampant piracy (and even your link specifically mentions “compatible with saleae software”). So anyway, decision is made and the saleae is on its way.

Hmnn… I searched the Hobby Electronics page for any any sign they were trying to benefit from Saleae’s software or trademark and didn’t see anything. Then I discovered that the title doesn’t get picked up by the search and that the title is pretty brazen :frowning: .

Progress!!!

# tinypcminfo -D0 -d0
Info for card 0, device 0:

PCM out:
      Access:	0x000009
   Format[0]:	0x000004
   Format[1]:	00000000
 Format Name:	S16_LE
   Subformat:	0x000001
        Rate:	min=8000Hz	max=8000Hz
    Channels:	min=1		max=1
 Sample bits:	min=16		max=16
 Period size:	min=2048		max=2048
Period count:	min=4		max=16

PCM in:
      Access:	0x000009
   Format[0]:	0x000004
   Format[1]:	00000000
 Format Name:	S16_LE
   Subformat:	0x000001
        Rate:	min=8000Hz	max=8000Hz
    Channels:	min=1		max=1
 Sample bits:	min=16		max=16
 Period size:	min=2048		max=2048
Period count:	min=4		max=16