Bluealsa with Google Pixel 8 Android Version 14 (Call sounds like a robot)

[bmt1596]

Hello Bluealsa development team!

I have an issue that I would like to seek your opinions on, hoping that you can help me resolve this concern.

I am using Bluealsa version 3.1.0 and have enabled the MSBC audio codec for handling calls. When connecting to other devices like the iPhone, I find that Bluealsa produces excellent results.

However, when connecting to a Google Pixel 8 phone running Android Version 14, I notice an issue where the PhoneUp and PhoneDown signals sound like a robot.

Based on my speculation, it seems that some SCO packets may have been lost during transmission over Bluetooth. My Bluetooth chip uses the USB protocol with an MTU size of 64 Bytes.

I have tried connecting the phone to other headphones like AirPods and Bose, and everything works fine. However, when connecting the phone to a device running the Bluealsa application, I encounter this issue.

Attached is a file containing a recording of the downlink call quality:

Record_Call_GooglePixel8.wav

Is the issue likely related to the Google Pixel 8, or is there some underlying problem from the Bluealsa side that I cannot determine? I hope you can help shed some light on this issue. Thank you.

[arkq]

However, when connecting the phone to a device running the Bluealsa application, I encounter this issue.

First of all can you provide some logs with debug enabled (BlueALSA compiled with --enable-debug). Then, in these logs, there should be information whether the mSBC is indeed used and whether there are some packets dropped. Also, when investigating some issues, please use the latest release (v4.1.1) or master if possible.

[bmt1596]

Thank you. I've enabled debugging and found that mSCO Decode was initialized when the call came in.

bluealsa: D: ../../src/sco.c:112: New incoming SCO link: F8:C3:CC:92:08:6A: 46
bluealsa: D: ../../src/hci.c:133: SCO link socket MTU: 46: 64
bluealsa: D: ../../src/ba-transport.c:1180: Starting transport: HFP Hands-Free (mSBC)
bluealsa: D: ../../src/ba-transport.c:297: Created BT socket duplicate: [46]: 48
bluealsa: D: ../../src/codec-msbc.c:82: Initializing mSBC codec
bluealsa: D: ../../src/sco.c:375: IO loop: START: sco_msbc_enc_thread: HFP Hands-Free (mSBC)
bluealsa: D: ../../src/ba-transport.c:441: PCM clients check keep-alive: 0 ms
bluealsa: D: ../../src/at.c:162: AT message: RESP: command:, value:OK
bluealsa: D: ../../src/ba-transport.c:1507: Created new IO thread [ba-sco-enc]: HFP Hands-Free (mSBC)
bluealsa: D: ../../src/ba-transport.c:297: Created BT socket duplicate: [46]: 49
bluealsa: D: ../../src/codec-msbc.c:82: Initializing mSBC codec
bluealsa: D: ../../src/sco.c:457: IO loop: START: sco_msbc_dec_thread: HFP Hands-Free (mSBC)
bluealsa: D: ../../src/ba-transport.c:1507: Created new IO thread [ba-sco-dec]: HFP Hands-Free (mSBC)
bluealsa: D: ../../src/at.c:162: AT message: RESP: command:, value:OK
D: ../../../src/asound/bluealsa-pcm.c:1309: Getting BlueALSA PCM: CAPTURE 00:00:00:00:00:00 sco

Just as you said, I did receive the following debug messages regarding the loss of the SCO data packet:

bluealsa: W: ../../src/codec-msbc.c:182: Missing mSBC packets (3 != 2): 1
bluealsa: W: ../../src/codec-msbc.c:182: Missing mSBC packets (1 != 0): 1
bluealsa: W: ../../src/codec-msbc.c:182: Missing mSBC packets (0 != 3): 1
bluealsa: W: ../../src/codec-msbc.c:182: Missing mSBC packets (3 != 2): 1
bluealsa: W: ../../src/codec-msbc.c:182: Missing mSBC packets (1 != 0): 1
bluealsa: W: ../../src/codec-msbc.c:182: Missing mSBC packets (2 != 1): 1
bluealsa: W: ../../src/codec-msbc.c:182: Missing mSBC packets (0 != 3): 1

[arkq]

Just as you said, I did receive the following debug messages regarding the loss of the SCO data packet:

There is one trick in current master branch which might help you a little bit - the real time priority for IO threads. See the --io-rt-priority= in the bluealsa manual. Other things to consider is the environment (too noisy in 2.4GHz), used BT chip (e.g. BT dongle)...

[borine]

Hmm, I wonder if this could be related to the introduction of LC3 codec and "super wideband" (SWB) mSBC support in Android 14? Other than that, I can't see any obvious reason why Android 14 mSBC should work any differently than iPhone with bluealsa. We haven't had any similar reports using earlier Android versions.

[bmt1596]

Hum. I just received information from my friend. He uses a Google Pixel Pro 7 phone and Android version 13. The same happened with his phone. Is the cause something different between Google Pixel phones? With only 8kHz CVSD sound available, it worked. Audio quality is poor of course.

Up to this point I have tested a lot with Iphone and Samsung and everything works very smoothly.

[bmt1596]

@borine I received a notification that Bluealsa does not support the following AT command:

bluealsa: D: ../../src/at.c:162: AT message: RESP: command:+BSIR, value: 1
bluealsa: W: ../../src/ba-rfcomm.c:1386: Unsupported AT message: RESP: command:+BSIR, value: 1

Will this cause the call quality to decrease? Because the phone also sends a wide band signal for the ring tone.

[borine]

Will this cause the call quality to decrease?

No, these log messages are for information only. The +BSIR RESP command is merely an indication from the phone to the hands-free device that the phone will send an in-band ringtone. The hands-free device does not (must not) send a reply to this command. BlueALSA does not care whether the incoming audio is ringtone or actual voice, it treats it all just the same, as audio to be made available to a connected capture client.

[bmt1596]

Humm. I think there's something wrong with the hardware here. I just changed to another bluetooth adapter (CSR8510 A10) and I no longer hear the robotic sound during i make a call with the Google Pixel Phone. As for capturing, I found everything worked very well and the sound quality was extremely good. I have a problem with the setup so that bluealsa can playback the signal through hci and reach the bluetooth adapter.

But I can't playback the sound even though I tried many different MTU values like 24, 48, 64, 60.

Below is a snippet of my hcidump log. I just find something a bit strange that even though I set the MTU value to 48 bytes, hci only always reads 24 bytes. The remaining write value is correct but still cannot hear anything when making calls.

 Type: Primary  Bus: USB
        BD Address: 00:1A:7D:DA:71:11  ACL MTU: 310:10  SCO MTU: 64:8
        UP RUNNING PSCAN
        RX bytes:1166 acl:0 sco:0 events:63 errors:0
        TX bytes:995 acl:0 sco:0 commands:63 errors:0
        Features: 0xff 0xff 0x8f 0xfe 0xdb 0xff 0x5b 0x87
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
        Link policy: RSWITCH HOLD SNIFF PARK
        Link mode: SLAVE ACCEPT
        Name: 'Sansa'
        Class: 0x000000
        Service Classes: Unspecified
        Device Class: Miscellaneous,
        HCI Version: 4.0 (0x6)  Revision: 0x22bb
        LMP Version: 4.0 (0x6)  Subversion: 0x22bb
        Manufacturer: Cambridge Silicon Radio (10)

> SCO data: handle 63 flags 0x00 dlen 24
> SCO data: handle 63 flags 0x00 dlen 24
> SCO data: handle 63 flags 0x00 dlen 24
> SCO data: handle 63 flags 0x00 dlen 24
< SCO data: handle 63 flags 0x00 dlen 48
< SCO data: handle 63 flags 0x00 dlen 48
< SCO data: handle 63 flags 0x00 dlen 48
< SCO data: handle 63 flags 0x00 dlen 48
> SCO data: handle 63 flags 0x00 dlen 24
> SCO data: handle 63 flags 0x00 dlen 24
> SCO data: handle 63 flags 0x00 dlen 24
> SCO data: handle 63 flags 0x00 dlen 24
< SCO data: handle 63 flags 0x00 dlen 48
> SCO data: handle 63 flags 0x00 dlen 24
> SCO data: handle 63 flags 0x00 dlen 24
> SCO data: handle 63 flags 0x00 dlen 24
> SCO data: handle 63 flags 0x00 dlen 24
> SCO data: handle 63 flags 0x00 dlen 24
> SCO data: handle 63 flags 0x00 dlen 24
> SCO data: handle 63 flags 0x00 dlen 24
> SCO data: handle 63 flags 0x00 dlen 24
> SCO data: handle 63 flags 0x00 dlen 24
> SCO data: handle 63 flags 0x00 dlen 24
< SCO data: handle 63 flags 0x00 dlen 48
< SCO data: handle 63 flags 0x00 dlen 48
< SCO data: handle 63 flags 0x00 dlen 48
< SCO data: handle 63 flags 0x00 dlen 48

Do you know what the cause for this could be?

[borine]

You can't choose the MTU from user space, it is always set by driver for the HCI Bus (in your case USB,using the btusb driver). The MTU values for read and write must be the same, and for mSBC codec the correct value for your USB device is 24. For CVSD the correct value is 48. It appears that you have tried to force the write size to be 48, and that definitely will cause problems for the USB driver. The value is especially critical for USB adapters to obtain the correct data rate, because they use an isochronous link which transfers fixed sized packets in fixed intervals.

I think the real problem here is that you are using an old kernel and a old version of bluez. SCO audio has had many issues with linux over many releases (see for example issue #400). This specific adapter you are using, CSR8510 A10, is known to cause issues, and not just for SCO audio - see for example https://forums.linuxmint.com/viewtopic.php?t=350117

So the simplest solution is probably to use a different adapter. I think there is nothing that BlueALSA can do to fix issues in the firmware or driver code.

[borine]

@bmt1596 Have you made any progress with this issue? In particular, have you tried the suggestions made in the comments, for example:

• have you tried a more recent version of bluealsa ?
• have you tried the --io-rt-priority= option ?
• have you tried a different bluetooth adapter ?
• have you tried a more recent linux kernel ?

[borine]

closing due to lack of activity