[Bluetooth A2DP] [DB820c] Low Quality Audio over Bluetooth A2DP

Products Support DragonBoard 820c
#1

Hi,

I am using latest OpenEmbedded Release on DragonBoard820c(p4).
Release: http://snapshots.linaro.org/96boards/dragonboard820c/linaro/openembedded/rocko/latest/rpb/

Bootimage: boot–4.11-r0-dragonboard-820c-20180322030504-99-99.img
Rootfs Image: rpb-desktop-image-dragonboard-820c-20180322030504-99.rootfs.img.gz

Setup :
DB820c P4 Board.
Bluetooth Device: JBL GO/ Jabra Smart Headphones

root@dragonboard-820c:~# uname -a
Linux dragonboard-820c 4.11.12+linaro #1 SMP PREEMPT Thu Mar 22 03:17:34 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux

Issue :
We get very laggy and low-quality audio while using Bluetooth a2dp profile both for playback and capture.
For using a2dp profile we are using bluez5 and open-source bluez-alsa utility.

Refernce for bluez-alsa: https://github.com/Arkq/bluez-alsa/
Recipe for bluez-alsa : https://github.com/Arkq/bluez-alsa/wiki/Yocto-OE-recipe

We are using following commands :

root@dragonboard-820c:~# btattach -B /dev/ttyMSM1 &
root@dragonboard-820c:~# systemctl start bluez-alsa
root@dragonboard-820c:~# bluetoothctl
[bluetooth]# power on
[bluetooth]# scan on
[bluetooth]# pair 78:44:05:F2:66:B9
[bluetooth]# connect 78:44:05:F2:66:B9
[bluetooth]# exit
root@dragonboard-820c:~# aplay -D bluealsa:HCI=hci0,DEV=78:44:05:F2:66:B9,PROFILE=a2dp Front_Center_8k.wav
Playing WAVE ‘Front_Center_8k.wav’ : Signed 16 bit Little Endian, Rate 8000 Hz, Mono

we also tried to run it on latest linaro release and with different sampling rates, but we got the same result.

Can you please suggest any missing items to improve the quality of audio over a2dp?
Let me know if you need any more information.

Thanks,
Krupal

#2

Well, 8 kHz is going to be pretty bad sound quality no matter how you look at it. Pretty much what you would get with an old analog telephone. Even for HFP, you really want to target 16 kHz.

Typical “music” sample rate will be 44.1 or 48 kHz, but you aren’t likely to be running that kind of rate over bluetooth without compression.

#3

Thanks for the reply,

Agreed, with statement, but i have tested for all different supported sampling rates including 8kHz, 16kHz, 32kHz, 44.1kHz, 48kHz and even 64kHz music. (for both 8-bit and 16-bit)

In all case, i was able to hear and record very laggy audio.(Almost similar to audio running on vlc at speed of 0.4).

Can you give me the music configuration(sample rate and 8/16 bit) that works perfectly on DB820c Bluettoth A2DP for linux release?

#4

I normally would interpret “laggy” to mean high latency. Like when you hear a time delay on a VoIP phone call. But what you are saying is that the audio is actually slowed down? So a 5 second chunk of audio will take, for example, 10 seconds to play back? If that is the case, then you are going to have to look into your sample rates a lot more closely and make sure that it matches right through the entire chain, and also make sure that you aren’t trying to write data to the HCI faster than it can transfer it.

#5

With this command you are using the generic H4 protocol at standard baudrate (115200bps) which could explain why you get slow throughput and slowed down sound. I suggest you to specify the protocol (qca).

$ btattach -B /dev/ttyMSM1 -p qca

Your device should then be configured to run at 3Mbps. The reason is that HCI specification does not define any command to switch UART baudrate on controller side, each vendor has its own opcodes.

Note that some patches are currently in development to detect/and probe Bluetooth from kernel instead of relying on this userspace trick (btattach).

#6

Thank you ! @Loic

It worked by specifying the qca protocol.

Does “probe bluetooth from kernel” means initializing from kernel driver.?
I did it using udev and a system service which uses btattach. Is there any other way out where we can eliminate use of btattach.?

#7

Yes.

This is the goal of upcoming patches. For now the only solution is btattach.