Bluetooth Controller: How to send/receive SCO audio packets? (IDFGH-97)

[mringwal]

This might be more of a 'how can I..?' question then an actual issue (well, I could say my issue is that I cannot find the necessary documentation...)

Does the ESP32 Bluetooth Controller support sending/receiving of SCO packets for Hands-free Profile?

I did a quick test with BTstack's HFP AG example and was able to open an SCO connection.
A connected speaker did receive some noise for a bit (it should have been a sine wave though), but I didn't see a single SCO packet getting received from the Bluetooth Controller via the VHCI interface.

If SCO is supported, what is needed to receive SCO packets via the VHCI interface?

As a follow up: Is there an easy way to track the speed of outgoing SCO packets? The HCI interface defines the HCI_Write_Synchronous_Flow_Control_Enable (which BTstack sends), but I didn't see no Number Completed Packets for the SCO connection.

HCI_Write_Synchronous_Flow_Control_Enable Overview:

• TI's CC256x chipset support it
• on USB Bluetooth Controllers isochronous endpoints are used (hence provides flow control)
• UART Broadcom/Cypress Controllers don't support it.

Thanks for reading this far!

[mywang-espressif]

Hi @mringwal , let me try to answer the first question first. For ESP32 bluetooth controller, SCO packets can be configured with two data path: HCI and PCM, the latter is the path routed to PCM hardware, which is the default setting. I can change the default data path setting to HCI for you. Can you give me some instructions to use your test example so that I can verify my modication?

[mringwal]

hi @mywang-espressif SCO via PCM makes sense (same with all standalone HCI Controllers). If SCO is configured for PCM, can the PCM data be read by the CPU, too? At what pins is the SCO data as PCM/I2S available?

To test with SCO via HCI, you could run the hfp_hf example and pair from a mobile phone. With packet log enabled, you should see SCO packets in the log (but the logging will slow you down). Maybe just print a "SCO received" instead in the hfp_hf_demo to make sure that SCO receiving works. hfp_hf example will send a 441 Hz sine wave, so if you call yourself, you should hear a sine. Sending requires SCO Flow Control to work, though.

If possible, it would be great to have an esp_... call to configure SCO to either specify the GPIO or select "SCO via HCI" during/after init.

[mringwal]

Hi! How can I configure SCO to get routed over HCI?

[nuntipat]

Hello @mywang-espressif, may I know if there is any update on this issue? For your information, here is the log after I'm testing the hfp_hf example.
Thank you,
Nuntipat

[00:02:18.093] LOG -- hfp_hf_demo.c.252: USER:'i'
Dial 1234567
[00:02:18.093] LOG -- hfp.c.127: HFP_TX ATD1234567;

[00:02:18.186] LOG -- hfp_hf.c.971: HFP_RX 
OK
[00:02:18.321] LOG -- hfp_hf.c.971: HFP_RX 
+CIEV: 3,2
[00:02:18.321] LOG -- hfp.c.1328: Parsed status of the AG indicator 2, status 
[00:02:18.322] LOG -- hfp.c.1104: 2 

AG_INDICATOR_STATUS_CHANGED, AG indicator 'callsetup' (index: 3) to: 2
[00:02:18.505] LOG -- hfp_hf.c.971: HFP_RX 
+BCS:1
[00:02:18.505] LOG -- hfp.c.1254: hfp parse HFP_CMD_AG_SUGGESTED_CODEC 1

[00:02:18.505] LOG -- hfp_hf.c.506: hfp: codec confirmed: CVSD
[00:02:18.511] LOG -- hfp.c.127: HFP_TX AT+BCS=1

[00:02:18.548] LOG -- hfp_hf.c.971: HFP_RX 
OK
[00:02:18.557] LOG -- hci.c.1888: Connection_incoming: DC:A9:04:49:B8:CA, type 2
[00:02:18.558] LOG -- hci.c.184: create_connection_for_addr DC:A9:04:49:B8:CA, type fe
[00:02:18.561] LOG -- hci.c.3143: sending hci_accept_connection_request, remote eSCO 1
[00:02:18.569] LOG -- hfp_hf.c.589: HFP: sending hci_accept_connection_request, sco_voice_setting 0x60
[00:02:18.596] LOG -- hci.c.1954: Synchronous Connection Complete (status=0) DC:A9:04:49:B8:CA
[00:02:18.596] LOG -- hfp.c.659: eSCO Connection established.ASSERT_ERR(0), in ld_acl.c at line 4245abort() was called at PC 0x40082829 on core 0
0x40082829: lock_acquire_generic at /home/nuntipat/esp/esp-idf/components/newlib/./locks.c:141


Backtrace: 0x4008a3b0:0x3ffc02e0 0x4008a54b:0x3ffc0300 0x40082829:0x3ffc0320 0x40082949:0x3ffc0350 0x400d36de:0x3ffc0370 0x400d3739:0x3ffc03b0 0x400e4b5e:0x3ffc03d0 0x400e4b6f:0x3ffc03f0 0x400f3aec:0x3ffc0420 0x400edc32:0x3ffc0440 0x4001791d:0x3ffc0460 0x400ee1b1:0x3ffc0480 0x400ee3a2:0x3ffc04c0 0x400188f5:0x3ffc04f0 0x40055fca:0x3ffc0530 0x40083aae:0x3ffc0550 0x40031b6a:0x3ffc0570 0x400156a5:0x3ffc05a0 0x400552cd:0x3ffc05c0 0x4008667b:0x3ffc05e0 0x4008201a:0x3ffc0600 0x400e2ee5:0x00000000
0x4008a3b0: invoke_abort at /home/nuntipat/esp/esp-idf/components/esp32/./panic.c:648

0x4008a54b: abort at /home/nuntipat/esp/esp-idf/components/esp32/./panic.c:648

0x40082829: lock_acquire_generic at /home/nuntipat/esp/esp-idf/components/newlib/./locks.c:141

0x40082949: _lock_acquire_recursive at /home/nuntipat/esp/esp-idf/components/newlib/./locks.c:169

0x400d36de: _puts_r at /Users/ivan/e/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdio/../../../.././newlib/libc/stdio/puts.c:98 (discriminator 2)

0x400d3739: puts at /Users/ivan/e/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdio/../../../.././newlib/libc/stdio/puts.c:138

0x400e4b5e: report_recv_called_from_isr at /home/nuntipat/esp/esp-idf/components/btstack/./main.c:98

0x400e4b6f: host_recv_pkt_cb at /home/nuntipat/esp/esp-idf/components/btstack/./main.c:122

0x400f3aec: vhci_send at ??:?

0x400edc32: r_eif_send at ??:?

0x400ee1b1: hci_tx_start at hci_tl.c:?

0x400ee3a2: r_hci_tl_send at ??:?

0x40083aae: r_assert_err at ??:?

0x4008667b: r_rwbtdm_isr_wrapper at intc.c:?

0x4008201a: _xt_lowint1 at /home/nuntipat/esp/esp-idf/components/freertos/./xtensa_vectors.S:1105

0x400e2ee5: uart_tx_char at /home/nuntipat/esp/esp-idf/components/vfs/./vfs_uart.c:117


================= CORE DUMP START =================
HOoAAAcAAAB0AQAA
3Nf8PyAC/D/U1/w/
sM/8P3DX/D91pkMAiC38P4gt/D/c1/w/gC38PxgAAAAU0CfmzAC3AtzX/D8AAAAA
AQAAANjF/D9tYWluAEtphyT15dApB9IAAAAAANTX/D8AAAAAIQUGAAEAAAACAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADyp/D+kqfw/DKr8PwAAAAAAAAAA

[mringwal]

Any progress on this? We've got a few more commercial inquiries about using HSP/HFP with ESP32, but so far that's no possible even with our Bluetooth stack as SCO is not accessible.

[mywang-espressif]

Hi @mringwal, I am sorry for the late response. I have studied this case and there are some issues in the use of SCO/eSCO link. According to our plan, we to resolve the issues within next month, to support such profile as HFP.
The audio data path can be configured as either PCM or HCI. Voice over HCI suffers an issue that will leads to crash. the latter. The former data path, bluetooth controller can access internal PCM interface which can be configured to be output to GPIO.
The HCI controller to host flow control for SCO link is not available for now, it is also an issue to be fixed.
Due to the existing issues, the SCO link demands for comprehensive test. All in all I will keep you informed of our progress for the SCO.

[mringwal]

hi @mywang-espressif Thanks for the current status.

So, in theory SCO could be routed to GPIOs and works there. How is this configured?

Some ideas:

• Could an ESP32 application also receive PCM data that the Bluetooth Controller has routed to GPIO? :)

• The main need for SCO over HCI is to support Wide-Band Speech.
  If the Bluetooth Controller could decoded/encode the SBC data + do some Packet Loss Concealment before passing it out/in via PCM, SCO does not need to go over HCI.

[mywang-espressif]

Hi @mringwal . The HFP Hands Free Unit is now merged into ESP-IDF master:
commit adcad91
I am afraid that for this initial commit, there is some bugs left unresolved and no example is there, but we will try to improve it soon.

Audio data path can be set as either: 1.PCM interface or 2. VoHCI. We have provide the menuconfig options in ESP32 bluedroid host, which actually invokes
esp_err_t esp_bredr_sco_datapath_set(esp_sco_data_path_t data_path)
as declared in esp_bt.h, which is supposed to be called after esp_bt_controller_enable().

If 1. PCM interface is used, the internal PCM signals from bluetooth IP can be "matrix"ed to GPIO pins, related signals include PCMFSYNC_OUT_IDX, PCMCLK_OUT_IDX, PCMDOUT_IDX, PCMDIN_IDX etc as shown in components/soc/esp32/include/soc/gpio_sig_map.h
If 2. VoHCI is used, ESP32 CPU can get access to the data and WBS can be built upon that.

Currently, some known issues I have found during development are left:

1. For VoHCI(voice over HCI), the HCI downstream SCO packet sent to controller is somehow required to use a packet length of 120Bytes, according to my test from ESP32 bluedroid. I will figure out the limitations for this packet length later.
2. For VoHCI, the HCI event number_of_completed_packets brings invalid SCO handles to the host, I found that the 16-bit handle along with packet_status flag and reserved bits is often 0x3980, and the actual SCO handle is 0x180. Currently the ESP32 bluedroid host just masks the upper bits.
3. The controller-to-host SCO packet flow control does not yet work.

Those are the issues of current state. I am sorry for the incomplete work but we will try to resolve the issues. Suggestions from you are highly valued.

[mringwal]

Hello @mywang-espressif Thanks for the update! From your description it already sounds possible to use HSP/HFP/SCO now.

As for the known issues:

1. fixed packet length: USB requires a packet len of 3 + 24 resp 48 bytes per active SCO connection. On TI's CC2564, larger sizes are required as well and 120 is recommended (I think I've used 60 byte packets). Just documenting this seems good enough.
2. What is the meaning of the top-most 4 bits? Bluetooth spec says they are reserved. It wouldn't hurt to mask the upper bits in BTstack as well.
3. Usually, this should not be needed. If I know that it doesn't work, I can try to keep track of received SCO packets in the VHCI wrapper and just drop them if there's no additional space.

I'll give it a try soon.

[mringwal]

hi @mywang-espressif - sorry, it took me so long to give this a try.

I've added a call to esp_bredr_sco_datapath_set(ESP_SCO_DATA_PATH_HCI) after esp_bt_controller_enable(ESP_BT_MODE_BTDM):
bluekitchen/btstack@d72415a

When opening an SCO connection, I don't see SCO packets getting received. What am I missing?

Could you do a quick check with the BTstack hfp_hf_demo? If needed, the SCO payload can be set to 120 by setting sco_packet_length to 123 in example/sco_demo_util.c:578.

Thanks!

[mringwal]

Just updated to current esp-idf master. Right now, I get this crash on btstack's develop branch for an incoming SCO connection in hfp_hf_demo.

...
[00:00:00.543] LOG -- main.c.250: transport: configure SCO over HCI, result 0x0000
...
[00:00:26.280] LOG -- hfp_hf.c.606: HFP: sending hci_accept_connection_request, sco_voice_setting 0x60
Guru Meditation Error: Core 0 panic'ed (IntegerDivideByZero). Exception was unhandled.
Core 0 register dump:
PC : 0x4002faf5 PS : 0x00060031 A0 : 0x80030d4e A1 : 0x3ffc0550
A2 : 0x00000000 A3 : 0x0000a0f4 A4 : 0x800371a0 A5 : 0x3ffd41e0
A6 : 0x00000000 A7 : 0x40088554 A8 : 0x00000000 A9 : 0x00000000
0x40088554: r_global_int_restore at ??:?

A10 : 0x3ffbd600 A11 : 0x3ffb824c A12 : 0x03ffffff A13 : 0x02ee03ba
A14 : 0x00000000 A15 : 0x00000070 SAR : 0x00000020 EXCCAUSE: 0x00000006
EXCVADDR: 0x00000000 LBEG : 0x4000c2e0 LEND : 0x4000c2f6 LCOUNT : 0x00000000
Core 0 was running in ISR context:
EPC1 : 0x4002faf5 EPC2 : 0x00000000 EPC3 : 0x00000000 EPC4 : 0x00000000

Backtrace: 0x4002faf5:0x3ffc0550 0x40030d4b:0x3ffc0570 0x4003a7e5:0x3ffc05a0 0x40087992:0x3ffc05c0 0x400883ab:0x3ffc05e0 0x400820ee:0x3ffc0600 0x4000bfed:0x00000000
0x40087992: r_rwbt_isr at ??:?

0x400883ab: r_rwbtdm_isr_wrapper at intc.c:?

0x400820ee: _xt_lowint1 at /Projects/esp32/esp-idf/components/freertos/xtensa_vectors.S:1105

================= CORE DUMP START =================
WBMAAAYAAAB0AQAA
WAb9P/AE/T9QBv0/
8AT9P/AF/T8AkNnhBD38PwQ9/D9YBv0//Dz8PxkAAACwjd4EAz+SyVgG/T8AAAAA
AAAAAFQC/T9JRExFAAs+GVUNuibYLFEAAAAAAFAG/T8AAAAAIw0GAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEDR/D+o0fw/ENL8PwAAAAAAAAAA
AQAAAAAAAABItUA/AAAAAEgdAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAU7K6
qB4IQB5WEUAwCgYA6roIgLAF/T8IAAAAAAAAACMABgBYBv0/AQAAAAAAAABAPPw/
JDz8PwAAAAAjAAYAIwAGAAD+/D8BAAAAAAAAAAAAAAAgCAYAgAX8PwAAAAAAAAAA
AAAAAKEgCEAA/vw/pNIIQCzT+z8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAACMABgAA/vw/AQAAAAAAAAAAAAAA0AX9PwAAAAAAAAAA
IwAGAFgG/T8BAAAAAAAAAAAAAADwBf0/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/AX9PwAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAA==
WAD9P1D+/D9QAP0/
UP78P/D//D8DbQAA8Dz8P/A8/D9YAP0/6Dz8PxgAAABmK916LzXiI1gA/T8AAAAA
AQAAAFTu/D9tYWluAL3uqhIleTbivmIAAAAAAFAA/T8AAAAAIQAGAAEAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEDR/D+o0fw/ENL8PwAAAAAAAAAA
AQAAAAAAAABItUA/AAAAAEgdAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAFZz1
qB4IQPC/AEAwBgYA7LYIgBD//D8AAAAAIwYGACAGBgAAAAAAAAAAALAF/D/4FwiA
4P78P8gI/D8DbQAAAAAAAAIAAAAFAAAAAQAAABgAAAC87F3mFQP8P0nDAEBrwwBA
/////6EgCEACAAAApNIIQCzN+z8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAALAF/D9KxQiAIP/8P+gI/D8DbQAA
aHYOgED//D/oCPw//////yxD/D+AAAAAAQAAAAAAAAC0cg6AYP/8P9NNYhCo0fw/
AAAAAHgGAAAAAAAAAAAAANsoDoCQ//w/CgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
BQAAAAAAAAAgAAAAAQAAAE0fDYCw//w/pCUOQAAAAACADAAAVKH8P1AS/T8jAAYA
AAAAAND//D8AAAAAAAAAAAAAAABYAP0/AQAAAAAAAAAAAAAA8P/8PwAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPz//D8AAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
zBD9P0AP/T/EEP0/
QA/9P2AQ/T8AAAAA3Dz8P9w8/D/MEP0/1Dz8PxgAAAD8B/0//Af9P8wQ/T/0B/0/
AQAAAMgI/T9UbXIgU3ZjAPlCRYrLCWUAAAAAAMQQ/T8AAAAAIQAGAAEAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEDR/D+o0fw/ENL8PwAAAAAAAAAA
AQAAAAAAAABItUA/AAAAAEgdAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA9Dlj
qB4IQDrYCEAwCwYAL9kIgAAQ/T8EP/w/AAAAAAEAAABYAP0/AQAAAAAAAAA62AiA
4A/9PwAAAABwPPw/HAj9PwAAAAAAAAAAAwAAAAAAAAClpaWlpaWlpQAAAAAAAAAA
AAAAAKEgCEAAAAAApNIIQJzd+z8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMBD9PwAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAJzd+z8AAAAAAAAAAAAAAAAAAAAAYBD9PwAAAAAAAAAA
AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAABsEP0/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAA==
QOX8P7Dj/D845fw/
sOP8P9Dk/D/2fW43zCr9P+Ts/D9A5fw/jDz8PwMAAAAQ0/w/ENP8P0Dl/D8I0/w/
FgAAADzT/D9lc3BfdGltZXIAJU7fdVAAAAAAADjl/D8AAAAAIQAGABYAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEDR/D+o0fw/ENL8PwAAAAAAAAAA
AQAAAAAAAABItUA/AAAAAEgdAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtr6e
qB4IQGDQCEAwAAYAdyYNgHDk/D/k0vw/AAAAADDT/D8AAAAAAQAAAAAAAABg0AiA
UOT8PwAAAADwPvw/8D78P7Dr/D/ICPw/AQAAAAAAAAClpaWlpaWlpQAAAAAAAAAA
AAAAAKEgCECw6/w/pNIIQAyy+z8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsOT8PwAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAANDk/D8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAADc5Pw/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAA=
xCr9P2Ao/T+8Kv0/
YCj9P1Aq/T+saxG0lDz8P0jl/D/EKv0/jDz8Pw0AAAD4MP0/+DD9P8Qq/T/wMP0/
DAAAAMAi/T9idHN0YWNrX3N0ZGluAGMA////f7wq/T8AAAAAIQAGAAwAAAABAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEDR/D+o0fw/ENL8PwAAAAAAAAAA
AQAAAAAAAABItUA/AAAAAEgdAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAS7CS
qB4IQGDQCEAwCgYAluAIgCAp/T/MMP0/AAAAABgx/T8AAAAAAQAAADws/T9g0AiA
ACn9PwAAAADwPvw/8D78PyAAAAAfAAAADQAAABMAAAClpaWlpaWlpWzEAEB3xABA
AAAAAKEgCEAgAAAApNIIQIz3+z8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAPgAAAAAAAAAAAKWlpaWQ5QiAYCn9PyQv/T+wKf0/
AAAAAPkAAAClpaWlpaWlpf////+lpaWlpaWlpaWlpaUwM/0/JDP9Pw0AAAAAAAAA
xYcOgKAp/T8kL/0/8Cn9P6WlpaWlpaWlpaWlpaWlpaW0Kf0/AAAAAAAAAAAAAAAA
AAAAAP//////////+AAAAIjID4DgKf0/AAAAADws/T//////4Cn9PwAAAAAAAAAA
/////+Ap/T8AAAAAjKH8P/////8AAAAAAAAAANAK/D8AAAAAMCr9PwAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAJ0BAAAKCngAAAAAAAAAAAD8x/w//////wAAAAAAAAAA
AQAAAAAAAAAAAAAAAAAAAAAAAABQKv0/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXCr9PwAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==
3Oz8P1Dr/D/U7Pw/
UOv8P3Ds/D/0q8HuSOX8P5Q8/D/c7Pw/jDz8PwEAAACs6Pw/rOj8P9zs/D+k6Pw/
GAAAANjo/D9pcGMwAHvsYy/1ATgenl0AAAAAANTs/D8AAAAAIQAGABgAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEDR/D+o0fw/ENL8PwAAAAAAAAAA
AQAAAAAAAABItUA/AAAAAEgdAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOHFK
qB4IQGDQCEAwAAYAbxcIgBDs/D+A6Pw/AAAAAMzo/D8AAAAAAQAAAAAAAABg0AiA
8Ov8PwAAAADwPvw/8D78PwA7/j/oCPw/AgAAAAAAAAClpaWlpaWlpQAAAAAAAAAA
AAAAAKEgCEAAO/4/pNIIQKy5+z8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUOz8PwAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAHDs/D8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABmDwiAsDv+P3g8/D88P/w/
AAAAAAAAAAB87Pw/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAA==
================= CORE DUMP END =================
E (9081) esp_core_dump: Skipped 1 tasks with bad TCB!
E (9087) esp_core_dump: Crashed task has been skipped!
CPU halted.

[markingle]

I have a need for HFP as well. I will begin testing the code with my setup an report any issues. Thanks for working on this feature!

[DTurnbow]

So what is the current status?
Where would I find the HSP/HFP sample code?

[394645065]

Any update for this?

[serafxxx]

Any update?

[mringwal]

I just tried again, and while it doesn't crash, I don't seem to receive any SCO packets via HCI ( I did not try sending). Is this a consequence of "The controller-to-host SCO packet flow control does not yet work."?

Btw is there an example that uses Bludroid to compare to?

[glennhuber]

I really need HFP/HSP profiles... sco data to & from a headset. I need to receive the packets via HCI. Is this being worked on? Is there an ETA on a solution? Any examples planned?

[mywang-espressif]

I am sorry for the late response. There is an error in the comment of function "esp_bredr_sco_datapath_set". This function should be used after an HCI reset command is set to the controller and before (e)SCO link is established. I will fix this issue then. Currently the HFP example using bluedroid is not merged into ESP-IDF. The example will be added later.

[glennhuber]

Okay, I may have been unclear in my previous comment. I want functionality similar to VOIP except the routing would be static. A smart phone would facilitate the devices association. Each ESP32 will have a BT headset connected. The mic voice data ((e)sco) would be sent via WIFI to the other device and played on it's headset ((e)sco) and vice versa. The volume and general buttons events would be needed also. The ESP32 would function as a "gateway" of sorts. I understand that there is a problem receiving data from the headset mic and/or sending that data to the host from the controller via HCI. Am I correct? Has that headset-mic->controller->host issue been resolved. Will there be an example illustrating receiving & sending packets to a BT headset via HCI?

[mringwal]

@mywang-espressif Thanks Karl for the hint. When calling "esp_bredr_sco_datapath_set" after HCI Reset, SCO data is sent and received. Excellent!

Follow up question: how I can send SCO correctly/optimally?

If you try hfp_hf_demo (with SCO_DEMO_MODE = SCO_DEMO_MODE_SINE in sco_demo_util.c) from BTstack's develop branch, there are small glitches on the receiver. The current code monitors the SCO RX packets, does some averaging and then uses a timer to decide when to send the next one - this was done to work with CSR or Broadcom H4 Controllers.

It would be easiest/best, when the ESP32 Link Layer could implement the SCO Flow Control from Host to Controller would be supported as with the TI CC2564 - there, BTstack just sends as many packets as there are SCO buffers and gets an HCI Num Complete Event when a packet was sent.

Could I just send 'num total sco packets ' - 1 SCO packets initially and then assume that one was sent out whenever I receive an SCO packet?

[AndrijKostio]

Hi! I have a project with HFP profile aimed to use, but there is a problem establishing a bidirectional audio transfer. Either the HF can receive the audio data from AG or the AG can receive them from HF, but not in both directions when the audio connection has been established, and the working direction is set unpredictably. The situation is identical with SCO over HCI and PCM. When the HCI is set as data path, the in and outgoing data callbacks seams to work, they are called at least, but one of them always carry no information tough it should present.
Is it possible to create a two way audio transfer?

[glennhuber]

@mringwal Where did you place the call to esp_bredr_sco_datapath_set( ESP_SCO_DATA_PATH_HCI ) in the file (hfp_hf.c or sco_demo_util.c)? Thanks.

[howroyd]

Any news on HSP working, please?

[piotrkundu]

@igrr Is anybody looking at this from your side? Looks like @mywang-espressif is no longer active in this thread. The ticket has been open for 2 years, any thing we can do to help out getting this solved?

[blueMoodBHD]

Hi all. Sorry for the late reply. We are working on an example which introduces how to use HF, such as connection, sending data and etc. The codes are now under internal reviewing, and will be merged into master. Will update once it gets merged. Thanks.

[mringwal]

Thanks! From the view of BTstack, explaining how to send SCO packets correctly would already be enough to move on as we already have HFP examples for AG and HF.

[AbnerFederer]

Hi all,

Confirmed news.

The HF example code and AG component with AG example code will be soon available on the Github IDF master branch. Please pay attention to it if you need.

Thanks
Abner

[mringwal]

@AbnerFederer Thanks for the update!

How was the outgoing SCO Flow Control solved? (see original question above).
Did Espressif implement regular HCI SCO Flow control? Or, was there another mechanism added to check when the next SCO packet can be sent?

[AbnerFederer]

Hi @mringwal

Please take a look of esp_hf_client_outgoing_data_ready(); API.
It should be used in your application where outgoing data is ready for each SCO packet.

Thanks
Abner

[mringwal]

@AbnerFederer esp_hf_client_outgoing_data_ready() just calls BTA_HfClientCiData(); I'd like to know how to send SCO correctly at VHCI level.

I guess I'll try the example and if it works, I'll take a deep dive into Bluedroid sources to see if there are any changes. Thanks.

[AbnerFederer]

Hi @mringwal

I just finished HFP AG components and the demo. Plan to dive into it too to do some optimization.
Keep in touch. : ）

Thanks.
Abner

[Hasaken]

Hi @AbnerFederer,

Good news, please keep us informed as soon as you make updates to idf. Thanks.

[AbnerFederer]

Hi all,

HFP Unit and AG (components and demo) are available on master branch now.

Thanks
Abner

[Alvin1Zhang]

@mringwal Thanks for reporting, feel free to reopen if you still have the issue or create another ticket if you have more issues, thanks.

[KollarRichard]

Hi, i have similar issue. In HFP_AG example the bt_app_hf_outgoing_cb is not called and bt_app_hf_incoming_cb works properly.

[KollarRichard]

@saikat00

Hi
I am working in a project which need BT HFP profile and as per ESP-IDF api I also initialize the HFP profile and every thing is working fine now SCO Audio communication is also working in VoHCI mode but there are some issues

1. Noise in reciver end
2. CPU Reboot (crash)after 33 sec

is it like this? #4660 For me worked this solution #4661.

[mringwal]

@KollarRichard How is the audio on the receiving side - that was my initial problem here. In BTstack, I've tried to send a constant sine tone to be able to spot any audio problems.

[gaso1111]

Hi
I am new here.
I am working on hfp_hf project. Compiling and flashing works, I can make an audio connection. With the oscilloscope I can see that data is coming out. Data is in PCM format, left justified. Data is sent in PCM master mode, but I need I2S slave mode for a codec.
I thought it would be easy to change mode in I2S registers. But I'm not sure now whether I2S inerface is used in this example.
I tried to see what is the content of I2S_CONF_REG (0) and I2S_CONF_REG (1) and I could only get value 0x00 although according to documentatio init value is 0xf00. Now I'm not sure this example uses I2S at all.
My question is:

• how can I use I2S interface in slave mode in this example

• I don't know which buffers are used to store and send the I2S audio packets over bluetooth?

• Could you please also show where the Bluetooth is configured in terms of I2S configuration?

Thank you for your support.

[ghost]

Hi @gaso1111

There is already a Merge Request to enable PCM configuration to slave mode and falling edge trigger in menuconfig and will soon be available in Github. You can use this lib first to continue your work.

PCM slave+rising edge.zip

Thanks
Weitianhua

[gaso1111]

Hi @Wth-Esp
Thanks for the quick response.
I copied this file to the position of the old file and started new project. File is located in ... \ esp-idf-v4.0 \ esp-idf-v4.0 \ components \ bt \ controller \ lib
New project is based on ... \ esp-idf-v4.0 \ esp-idf-v4.0 \ examples \ bluetooth \ bluedroid \ classic_bt \ hfp_hf.
With the old file it was possible to compile without errors, but with the new file I got a lot of errors (see appendix with compile errors).
What's wrong here?

Thank you very much!
hf_profile_slave_1_error.txt

[ghost]

Hi, @gaso1111

The lib above is for the Master branch. So there might be some updates the host doesn't have.

And because of HF-AG is a new feature for release/v4.1, we might not backport the PCM configuration to the release branch pre-to release/v4.1 branch.

Thanks
Abner

[gaso1111]

Hello @ Wth-Esp
unfortunately I couldn't achieve much with that.
I tried release / v4.1 but had a lot of problems there.
Compiling in release / v4.1 may work once, but the next time I compile I always get errors and then I had to reinstall the ESP-IDF Tools Installer. It seems that release / v4.1 is somehow not stable.
Once I managed to compile but I could only see that I2S switched to slave mode, but no data on Tx / Rx path.
Is there a better version of HFP example where I2S is in slave mode and data are available?
What is your plan with HFP in slave mode, when could it be ready for testing?
How long should it take?

With best regards

[ghost]

Hi @gaso1111

Shall I build a lib for you base on the latest release/v4.0?
Could you please provide the commit you want?

Thanks
Weitianhua

[gaso1111]

Hello @ Wth-Esp
as i mentioned i had problems with realese v4.1 and v4.2 when compiling.
I can compile and work on Realese V4.0. I downloaded the realese V4.0 from there https://github.com/espressif/esp-idf/releases/download/v4.0/esp-idf-v4.0.zip
In Sourcetree I tried using V4.0 and this commit: b0f053d [b0f053d] and it worked!
If you could make a library for realese V4.0 that would be very good for me.
So I need HFP with PCM (I2S) in slave mode.
Best regards

[ghost]

Hi @gaso1111
Here are the lib and IDF patch.
pcm_release_4.0.zip

Please help yourself config the PCM mode in menuconfig like photos
below.

By the way, I think your question is another issue, so, the next time, please start another issue thread for a new issue.

Thanks
Weitianhua

[gaso1111]

Hello @Wth-Esp
hfp_slave_errors.txt

I have integrated everything as you have recommended. I was able to start and configure menuconfig. But with build (compiling) it didn't work. You can see the errors in the attachment. What is the problem and how can I get it to work?

Best regards

[gaso1111]

Hello @ Wth-Esp
Please can you help me further. Our project is blocked by this problem.
Thank you very much

[ghost]

@gaso1111
I don't know why you cannot build successfully. And I cannot know the right commit from your log. Please get IDF with git clone and git checkout release/v4.0 or git checkout b0f053d and then git submodule update --init. Then replace the lib.

Here is my commit log for your reference:
IDF commit:

BT lib ($IDF_PATH/components/bt/controller/lib)

Thanks
Weitianhua

[gaso1111]

Hello @Wth-Esp
With this it was possible to compile, but on PCM pins there was no data. I connected an external codec and it was in PCM master mode. BCLK and WCLK signals are present, but I couldn't see any data from the ESP.
As I mentioned because of this problem, our project is blocked. What can I do next? Is there any deadline, when is the next release where you can select it in menuconfig and that it works?

Thank you very much