[IDEA] Add option to select SBC XQ/XQ+ encoding quality for bluetooth transmission

[Nutul]

Force 44.1 kHz sampling frequency for A2DP profile. Some Bluetooth devices can handle streams sampled at either 48kHz or 44.1kHz, in which case they normally default to using 48kHz. With this option, bluealsa will request such a device uses only 44.1 kHz sample rate.

Understood.

[TheOldPresbyope]

Actually, the official A2DP v1.2 spec says

4.3 SBC codec interoperability requirements

4.3.1 Reference

It is mandatory to support SBC codec interoperability requirements in this profile. The SBC specification is a part of the Bluetooth specification. ...

4.3.2.1 Sampling Frequency

... For the decoder in the SNK, the sampling frequencies 44.1 kHz and 48 kHz are mandatory to support. The encoder in the SRC shall support at least one of the sampling frequencies of 44.1 kHz and 48 kHz.
...

where I added the bold emphasis. SNK = the sink device and SRC = the source device.

I'm comfortable that we can force 44.1 kHz sampling in the SBC encoding always.


Regards,
Kent

[TheOldPresbyope]

So, I started dabbling with the SBC quality option.

[Aside: is there a better way to determine the quality actually negotiated in a connection? What I'm doing works but seems nerdy. bluealsa-cli and bluealsa-aplay are useful but AFAICT don't drill down to this level of detail.]

Test host: 64-bit moOde 8.3.3 on RPI3B+
Test speakers: JBL Flip2 BT speaker (includes SBC codec only), Sennheiser HD4.50BTNC headphones (includes SBC, aptX codecs)

First, stock moOde (e.g., high quality SBC) with the JBL paired, connected, selected as output device, and while playing a track

Code:

pi@moode:~ $ sudo service bluealsa status
...blah blah blah...
Jul 06 10:07:57 moode bluealsa[1462]: bluealsa: [5148] D: codec-sbc.c:262: SBC setup: 48000 Hz JointStereo allocation=SNR blocks=16 sub-bands=8 bit-pool=51 => 345000 bps
...blah blah blah...

So, we have 48kHz sampling frequency and the 345kpbs stereo bitrate stated in the bluealsa docs for high quality SBC.

Second, add the --sbc-quality=xq option to the service file, reboot, reconnect, etc.

Code:

pi@moode:~ $ sudo service bluealsa status
...blah blah blah...
Jul 06 09:45:31 moode bluealsa[1454]: bluealsa: [238436] D: codec-sbc.c:262: SBC setup: 44100 Hz DualChannel allocation=SNR blocks=16 sub-bands=8 bit-pool=38 => 452
025 bps
---blah blah blah...

Yup, the sampling frequency has been forced to 44.1kHz and the bitrate has increased to 452kbps. Can I hear the difference? Ha ha ha, not with this speaker and my ears, but playback certainly isn't worse, and seems stable.

Third, rinse and repeat with --sbc-quality=xq+. The relevant line from the service status request is now

Code:

Jul 06 09:55:53 moode bluealsa[1456]: bluealsa: [3501] D: codec-sbc.c:262: SBC setup: 44100 Hz DualChannel allocation=SNR blocks=16 sub-bands=8 bit-pool=47 => 551250 bps

So, sampling frequency is again 44.1kHz while the bitrate increases to the documented 551kbps. Tracks are playing through the speaker fine.

What about the headphones and their aptX codec?

In all three cases---none, xq, xq+---I see the same two lines (not necessarily in the same order) in the service status concerning the aptX codec:

Code:

Jul 06 10:10:38 moode bluealsa[1462]: bluealsa: [1462] D: ba-transport.c:1949: Created new IO thread [ba-a2dp-aptx]: A2DP Source (aptX)
Jul 06 10:10:38 moode bluealsa[1462]: bluealsa: [6911] D: a2dp-aptx.c:135: IO loop: START: a2dp_aptx_enc_thread: A2DP Source (aptX)

This is what I would expect since we're now not using the SBC codec. However, the sampling frequency does change---which seems to contradict a statement made by @jenzd . For stock moOde, the negotiated sampling frequency is 48kHz. OTOH, with either  --sbc-quality=xq or --sbc-quality=xq+ option set

Code:

pi@moode:~ $ bluealsa-aplay -L
bluealsa:DEV=00:16:94:29:7F:10,PROFILE=a2dp,SRV=org.bluealsa
   HD 4.50BTNC, trusted audio-card, playback
   A2DP (aptX): S16_LE 2 channels 44100 Hz

 
I can't hear the difference. In all cases, playback through the Sennheisers sounds good and is stable.

Note that AFAIK the A2DP spec writers choose 44.1kHz and 48kHz simply because those two frequencies were commonly used in CD and TV audio production and not because they had any thoughts that 48kHz would result in better quality sound. As a practical matter, the resampling which takes place seems to have minimal if any audible effect if done competently (obviously opinions on this differ and I'm just as opinionated as the next person, if not more so).

Regards,
Kent

[TheOldPresbyope]

Huh, I just noticed that when I use a moOde 8.3.3 player as the "Bluetooth speaker" for another, or for my Android Pixel 6a phone, the negotiated connection uses aptX-HD. Not too shabby.

Example, m833p4b is a stock moOde 8.3.3 player on an RPi4B while m833p3lcd is a moOde 8.3.3 player on an RPi3B+ (with, natch, an LCD screen) with the --sbc-quality=xq+ option set. If I use m833p4b as the sender and m833p3lcd as the receiver

Code:

pi@m833p3lcd:~ $ bluealsa-aplay -L
bluealsa:DEV=DC:A6:32:03:17:AC,PROFILE=a2dp,SRV=org.bluealsa
   M833P4B, audio-card, capture
   A2DP (aptX-HD): S24_LE 2 channels 48000 Hz

Note that the sampling frequency is 48kHz which means the --sbc-quality=xq+ option on the receiving system didn't override the sending system's request.

If I do the reverse using m833p3lcd as the sender, then the negotiated sampling frequency is 44.1kHz. Interesting.

Regards,
Kent

[Tim Curtis]

In a recent commit I set the default SBC quality to xq+. Bluealsa should fall back to lower quality if the client doesn't support xq+. https://github.com/moode-player/moode/bl...te.service

[TheOldPresbyope]

Cool.

[Tim Curtis]

Hopefully it functions that way in practice.

Bluetooth and its codecs are a real piece of work. The whole "encoding is free but decoding requires a fee" is a fine example of a high entropy thinking.

[jenzd]

Thanks for adding the switch! 

It seems that I was wrong to suspect that sample rate would be fixed for other codecs as well. I probablly didn't understand the source code correctly (which is quite long and distributed over many files).

Even better so - no side effects. In case somebody really wants to use 44.1 kHz there is still the switch "--a2dp-force-audio-cd" which could be used.

By the way: "bluealsa-cli --verbose list-pcms" shows the codec details as well. They are, however, less readable as they are given by a hexadecimal number after the codec name, e.g. "Selected codec: SBC:21150228", and you need to refer to the source code of bluealsa to decode it (https://github.com/arkq/bluez-alsa/blob/...ecs.h#L515).

In this example the flags say:

'2': sampling frequency 44.1 kHz,
'1': joint stereo
'1': block length 16,
'5': subbands 8 & allocation loudness,
'02': min bitpool = 2
'28': max bitpool = 40

Cheers
Jens