Why is sound distorted when using Wl18xx HFP/HSP over HCI?

Hi,

Can you try the below commands and see if it helps?

hcitool cmd 0x3f 0x0210 0x01 0x78 0xff 0x01 0xff
hcitool cmd 0x03 0x002f 0x01

Regards,
Gigi Joseph.

Hi Gigi.

No, it does not help. Nothing changes in audio, distortion is still there. The audio I play is a short voice message, but through headset voice sounds metallic and slower than normal.

Please find below the output of your commands:

root@freescale ~$ hcitool cmd 0x3f 0x0210 0x01 0x78 0xff 0x01 0xff
< HCI Command: ogf 0x3f, ocf 0x0210, plen 5
01 78 FF 01 FF
> HCI Event: 0x0e plen 6
01 10 FE 00 78 04

root@freescale ~$ hcitool cmd 0x03 0x002f 0x01
< HCI Command: ogf 0x03, ocf 0x002f, plen 1
01
> HCI Event: 0x0e plen 4
01 2F 0C 0C

I am not able to understand if they ran with success or not. What do you think? I think second command failed.

I tried to send same commands before starting Bluez, output is different and seems correct:

HCI Command: ogf 0x3f, ocf 0x0210, plen 5
  01 78 FF 01 FF
> HCI Event: 0x0e plen 6
  01 10 FE 00 78 04

HCI Command: ogf 0x03, ocf 0x002f, plen 1
  01
> HCI Event: 0x0e plen 4
  01 2F 0C 00

But again sound is distorted. Moreover, kernel prints these messages during audio playback:

Bluetooth: Unknown type 2 conn 9a81c400
Bluetooth: Unknown type 2 conn 9a81c400
Bluetooth: Unknown type 2 conn 9a81c400
Bluetooth: Unknown type 2 conn 9a81c400
...

Regards,

Federico

Hi Federico,

Looking at the error prints, it seems the host stack does not handle the num_completed_pkts correctly. The "type= 2" corresponds to eSCO link. It seems the stack is not correctly handling it. And this could lead to breaks in the audio.

You might want to try to force a SCO connection, or try to handle the eSCO data correctly.

Regards,
Gigi Joseph.

Hi Gigi.

Can you please explain how to force a SCO connection?

Also, can you please explain the meaning of these commands you gave me and that I tried:

hcitool cmd 0x3f 0x0210 0x01 0x78 0xff 0x01 0xff
hcitool cmd 0x03 0x002f 0x01

Regards,

Federico

Hi Federico,

You tried:
Send_HCI_VS_Write_SCO_Configuration (configures "HCI" connection type, host tx buffer size, etc ) & HCI_Write_SCO_Flow_Control_Enable commands.

Forcing SCO connection will depend on your stack implementation. For example, BlueZ stack has a module param ("disable_esco") on bluetooth.ko. You can use that.

Another option would be to use: processors.wiki.ti.com/.../CC256x_VS_HCI_Commands (Byte: 3/Bit:7) and clear eSCO support from LMP supported features.

Regards,
Gigi Joseph.

Hi Gigi.

I tried to force SCO connection by settings disable_esco=1 kernel parameter for bluez. I am still sending the two commands you gave me (Send_HCI_VS_Write_SCO_Configuration & HCI_Write_SCO_Flow_Control_Enable).  Unfortunately, no success.

When I connect to headset with such parameter, kernel keeps printing these messages very fast:

Bluetooth: hci0 SCO packet for unknown connection handle 257
Bluetooth: hci0 SCO packet for unknown connection handle 257
Bluetooth: hci0 SCO packet for unknown connection handle 257
Bluetooth: hci0 SCO packet for unknown connection handle 257
Bluetooth: hci0 SCO packet for unknown connection handle 257

What does it mean?

Moreover, I am not able to play anything, I do not hear any sound. Please help me.

I made second test, using the SetFeature command you suggested (and removing the disable_esco parameter). In this case, kernel does not print any error, but when I play the audio file I do not hear anything. Moreover, during playback, btmon does not dump any HCI data/event.

How can i solve this problem?

Hi,

It looks to me that the SCO data is being dropped by the stack, as it does not recognize the sco connection. This is not a wl18xx issue, but looks to be related to the stack. Please post this on some BlueZ forums, and you will get better response there.

Regards,
Gigi Joseph.