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

[jenzd]

The bluez-alsa package which is supplied with Moode already contains support for bluetooth transmission with the enhanced SBC quality modes XQ and XQ+ described in http://soundexpert.org/articles/-/blogs/...udio-codec. These are, however, not used by default. The standard SBC encoding quality is "high".

To activate one of the enhanced encoder modes, SBC quality needs to be explicitly selected by adding the switch "--sbc-quality=<mode>" when the bluealsa service is started. This can be done in the file /etc/systemd/system/bluealsa.service. Available options for <mode> are (see https://github.com/arkq/bluez-alsa/blob/...alsa.8.rst):

• low - low audio quality (mono: 114 kbps, stereo: 213 kbps)
  
• medium - medium audio quality (mono: 132 kbps, stereo: 237 kbps)
  
• high - high audio quality (mono: 198 kbps, stereo: 345 kbps)
  
• xq - SBC Dual Channel HD (SBC XQ) (452 kbps)
  
• xq+ - SBC Dual Channel HD (SBC XQ+) (551 kbps)
  

Side note: In the current version 4.1.0 of bluez-alsa the SBC XQ and XQ+ modes force the bluetooth connection to a sample rate of 44.1 kHz. Otherwise either 44.1 kHz or 48 kHz are negotiated at connection time. To force 44.1 kHz for other codecs/quality modes as well, the additional switch "--a2dp-force-audio-cd" can be used.

Idea: Would it be possible to add an option to Moode's bluetooth configuration page to select the SBC encoding quality (high/XQ /XQ+)?

Thanks & best regards
Jens

[Tim Curtis]

That could be done but what happens if we just make the internal default xq+ instead of high?
According to the Soundexpert article virtually all modern BT devices support the XQ+ rate.

[TheOldPresbyope]

Huh. Shows how long it’s been since I’ve studied the bluez-alsa docs carefully. Turns out the XQ/XQ+ options were added to them a bit over a year ago.

Now I’ll have to figure out which BT devices I have do/don’t support the enhanced modes. 

Regards,
Kent

[Tim Curtis]

This Git issue mentions an auto-fallback mechanism from the XQ/XQ+ modes.
https://github.com/Arkq/bluez-alsa/issues/272

If this can be confirmed then we could just simply specify --sbc-quality=xq+ in the systemd unit to replace the internal default of "high"and then let bluealsa handle which SBC mode to use with a given client.

The only concern with this may be that even though bluealsa negotiated for example xq+ with a client that for some reason the higher data rate caused glitches. In this case we would need to add as option to Bluetooth Control screen that allows the SBC quality mode to be set.

[Nutul]

The only concern with this may be that even though bluealsa negotiated for example xq+ with a client that for some reason the higher data rate caused glitches. In this case we would need to add as option to Bluetooth Control screen that allows the SBC quality mode to be set.

That would be my only concern.
I'll never use BT for critical (or even just pleasure) listening, but I agree it would be unpleasant not being able to switch to a lesser - but glitch-less - quality.

[jenzd]

Apart from rare glitches for some devices (due to dual channel mode instead of joint stereo and high bitrate which, however, should both be supported if the device is truely bluetooth compliant), there is another (maybe minor) issue with the current specifiic implementation in bluealsa.

As far as I have seen in the source code (and backed by a few quick tests), bluealsa limits the sample rate to 44.1 kHz when "--sbc-quality=xq" or "--sbc-quality=xq+" are specified. Not only for SBC (intended for XQ/XQ+ here), but also if another codec is finally used by the device (e.g. aptX), i.e. "--sbc-quality=xq/xq+" effectively implies the switch "--a2dp-force-audio-cd". Otherwise 48 kHz sample rate would be typically preferred over 44.1 kHz when the sample rate is negotiated.
(See https://github.com/arkq/bluez-alsa/blob/...sbc.c#L125

Code:

    if (config.sbc_quality == SBC_QUALITY_XQ ||
            config.sbc_quality == SBC_QUALITY_XQPLUS) {
        info("Activating SBC Dual Channel HD (SBC %s)",
                config.sbc_quality == SBC_QUALITY_XQ ? "XQ" : "XQ+");
        config.a2dp.force_44100 = true;
    }

where config.a2dp.force_44100 is a global rather than a SBC specific setting, if I understand the code correctly.)

Since Moode is primarily targeted on music which - in most cases - has a native sample rate of 44.1 kHz, this may even be seen as a feature, since "--a2dp-force-audio-cd" is what you might want to choose anyway. Still I would see this as a rather unexpected side effect.

Best regards
Jens

[Tim Curtis]

Apart from rare glitches for some devices (due to dual channel mode instead of joint stereo and high bitrate which, however, should both be supported if the device is truely bluetooth compliant), there is another (maybe minor) issue with the current specifiic implementation in bluealsa.

As far as I have seen in the source code (and backed by a few quick tests), bluealsa limits the sample rate to 44.1 kHz when "--sbc-quality=xq" or "--sbc-quality=xq+" are specified. Not only for SBC (intended for XQ/XQ+ here), but also if another codec is finally used by the device (e.g. aptX), i.e. "--sbc-quality=xq/xq+" effectively implies the switch "--a2dp-force-audio-cd". Otherwise 48 kHz sample rate would be typically preferred over 44.1 kHz when the sample rate is negotiated.
(See https://github.com/arkq/bluez-alsa/blob/...sbc.c#L125

Code:

    if (config.sbc_quality == SBC_QUALITY_XQ ||
            config.sbc_quality == SBC_QUALITY_XQPLUS) {
        info("Activating SBC Dual Channel HD (SBC %s)",
                config.sbc_quality == SBC_QUALITY_XQ ? "XQ" : "XQ+");
        config.a2dp.force_44100 = true;
    }

where config.a2dp.force_44100 is a global rather than a SBC specific setting, if I understand the code correctly.)

Since Moode is primarily targeted on music which - in most cases - has a native sample rate of 44.1 kHz, this may even be seen as a feature, since "--a2dp-force-audio-cd" is what you might want to choose anyway. Still I would see this as a rather unexpected side effect.

Best regards
Jens

Interesting. I think it's OK to have it be 44.1K and not have any resampling to 48K being done cos as you say most music is 44.1K.

Question: if --sbc-quality=xq+ is specified in the systemd unit does bluealsa intelligently fallback to lower quality setting if client does not support xq+ ??

I'm trying to determine whether SBC quality options need to be added to Bluetooth Control screen.

[Nutul]

Apart from rare glitches for some devices (due to dual channel mode instead of joint stereo and high bitrate which, however, should both be supported if the device is truely bluetooth compliant), there is another (maybe minor) issue with the current specifiic implementation in bluealsa.

As far as I have seen in the source code (and backed by a few quick tests), bluealsa limits the sample rate to 44.1 kHz when "--sbc-quality=xq" or "--sbc-quality=xq+" are specified. Not only for SBC (intended for XQ/XQ+ here), but also if another codec is finally used by the device (e.g. aptX), i.e. "--sbc-quality=xq/xq+" effectively implies the switch "--a2dp-force-audio-cd". Otherwise 48 kHz sample rate would be typically preferred over 44.1 kHz when the sample rate is negotiated.
(See https://github.com/arkq/bluez-alsa/blob/...sbc.c#L125

Code:

    if (config.sbc_quality == SBC_QUALITY_XQ ||
            config.sbc_quality == SBC_QUALITY_XQPLUS) {
        info("Activating SBC Dual Channel HD (SBC %s)",
                config.sbc_quality == SBC_QUALITY_XQ ? "XQ" : "XQ+");
        config.a2dp.force_44100 = true;
    }

where config.a2dp.force_44100 is a global rather than a SBC specific setting, if I understand the code correctly.)

Since Moode is primarily targeted on music which - in most cases - has a native sample rate of 44.1 kHz, this may even be seen as a feature, since "--a2dp-force-audio-cd" is what you might want to choose anyway. Still I would see this as a rather unexpected side effect.

Best regards
Jens

I agree with you, to some extent; the culprit being... is BT actually capable of delivering more-than-cd quality? I mean, it's true that ALSA, once received the stream, can do whatever manipulation it wants to please the audio layer, before spitting the stream out, provided it does not degrade the received quality (or at least this is what we all may want, right?)

But... couldn't it be that force_44100 = true is there to _prevent_ ALSA from using a less-refined quality, rather than _forcing_ it to use a lesser one?

[jenzd]

A fallback is implemented and appears to work (see https://github.com/arkq/bluez-alsa/blob/...-sbc.c#L60):

Code:

    if (quality == SBC_QUALITY_XQ ||
            quality == SBC_QUALITY_XQPLUS) {
        /* Check whether XQ/XQ+ is possible. If not,
         * downgrade to high quality. */
        if (conf->frequency == SBC_SAMPLING_FREQ_44100 &&
                conf->channel_mode == SBC_CHANNEL_MODE_DUAL_CHANNEL &&
                conf->block_length == SBC_BLOCK_LENGTH_16 &&
                conf->subbands == SBC_SUBBANDS_8 &&
                conf->allocation_method == SBC_ALLOCATION_LOUDNESS)
            bitpool = quality == SBC_QUALITY_XQ ? 38 : 47;
        else {
            warn("Unable to use SBC %s, downgrading to high quality",
                    quality == SBC_QUALITY_XQ ? "XQ" : "XQ+");
            quality = SBC_QUALITY_HIGH;
        }
    }

and a few lines later

Code:

    /* Clamp selected bit-pool value to supported range. */
    return MIN(MAX(conf->min_bitpool, bitpool), conf->max_bitpool);

My bluetooth speaker JBL Flip 6 (in fact a mono device) does not seem to support XQ/XQ+ mode and falls back to joint stereo (i.e. high quality).

Best regards
Jens

[jenzd]

But... couldn't it be that force_44100 = true is there to _prevent_ ALSA from using a less-refined quality, rather than _forcing_ it to use a lesser one?

See the description of the switch "--a2dp-force-audio-cd" (wich is internally mapped to force_44100 = true) https://github.com/arkq/bluez-alsa/blob/...alsa.8.rst:

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.

Cheers
Jens