Bluetooth A2DP audio fix kernel

[rmausser]

So ive been looking into this bluetooth sound quality issue (sound quality of music over a2dp to bluetooth stereo devices is just terrible)

and apparently in linux the bluetooth stack is run in the kernel, and this is where you change the "bitpool" (the quality at which bluetooth audio is sent)

Android and webOS have it set to a maximum of 32, which only allows 32khz of audio. Most audio is 44Khz, and thus the recommended max bitpool is 52. (some overhead for good measure)

I have come across kernel fixes for it in Android,

UnixPsycho and RWhitby, is there anyway we can appropriate these kernel fixes to fix the issue in webOS?

I am attaching all the resources I found.

I am a web programmer, this kernel stuff might as well be written in cantonese, but I am hoping someone here can understand it and run with it.

[Q] Bluetooth Bitpool Setting - Compiled into the kernel? - xda-developers

http://forum.xda-developers.com/showthread.php?t=708685

Looks like Cyanogen sets the bitpool based on sampling frequency, which makes sense. For high sample rates they use 31, for low samples they use 53.

Code repository for Cyanogen Froyo is here https://github.com/CyanogenMod/andro...udio/ipctest.c

static uint8_t a2dp_default_bitpool(uint8_t freq, uint8_t mode)
{
	switch (freq) {
	case BT_SBC_SAMPLING_FREQ_16000:
	case BT_SBC_SAMPLING_FREQ_32000:
		return 53;

	case BT_SBC_SAMPLING_FREQ_44100:

		switch (mode) {
		case BT_A2DP_CHANNEL_MODE_MONO:
		case BT_A2DP_CHANNEL_MODE_DUAL_CHANNEL:
			return 31;

		case BT_A2DP_CHANNEL_MODE_STEREO:
		case BT_A2DP_CHANNEL_MODE_JOINT_STEREO:
			return 53;

		default:
			DBG("Invalid channel mode %u", mode);
			return 53;
		}

Lets fix the audio over bluetooth qualit once and for all!

[somline]

Nice find.
Sorry for highjacking:
Do you know where I could find the driver to the battery or the A6 chip in TouchPad?
Thanks

[unixpsycho]

Originally Posted by rmausser

So ive been looking into this bluetooth sound quality issue (sound quality of music over a2dp to bluetooth stereo devices is just terrible)

and apparently in linux the bluetooth stack is run in the kernel, and this is where you change the "bitpool" (the quality at which bluetooth audio is sent)

Android and webOS have it set to a maximum of 32, which only allows 32khz of audio. Most audio is 44Khz, and thus the recommended max bitpool is 52. (some overhead for good measure)

I have come across kernel fixes for it in Android,

UnixPsycho and RWhitby, is there anyway we can appropriate these kernel fixes to fix the issue in webOS?

I am attaching all the resources I found.

I am a web programmer, this kernel stuff might as well be written in cantonese, but I am hoping someone here can understand it and run with it.

[Q] Bluetooth Bitpool Setting - Compiled into the kernel? - xda-developers

Bluetooth A2DP bitpool - xda-developers

Looks like Cyanogen sets the bitpool based on sampling frequency, which makes sense. For high sample rates they use 31, for low samples they use 53.

Code repository for Cyanogen Froyo is here https://github.com/CyanogenMod/andro...udio/ipctest.c

static uint8_t a2dp_default_bitpool(uint8_t freq, uint8_t mode)
{
    switch (freq) {
    case BT_SBC_SAMPLING_FREQ_16000:
    case BT_SBC_SAMPLING_FREQ_32000:
        return 53;

    case BT_SBC_SAMPLING_FREQ_44100:

        switch (mode) {
        case BT_A2DP_CHANNEL_MODE_MONO:
        case BT_A2DP_CHANNEL_MODE_DUAL_CHANNEL:
            return 31;

        case BT_A2DP_CHANNEL_MODE_STEREO:
        case BT_A2DP_CHANNEL_MODE_JOINT_STEREO:
            return 53;

        default:
            DBG("Invalid channel mode %u", mode);
            return 53;
        }

Lets fix the audio over bluetooth qualit once and for all!

This isn't a kernel fix. This is a userspace bluetooth stack hack.

Last time I looked, webOS has a "special" bluetooth stack, so no source code.

[rmausser]

No way we could disable, the special one and replace it with an open-source one?

Or is that getting into closed source territory as well.

What a shame.

[unixpsycho]

I thought I saw somewhere that a group was trying to get the open source stack running?

I'm a kernel guy for webOS so i wouldn't know what's involved for userspace since the UI is dependant on certain things, but I know on a normal Linux system I would just grab the BlueZ sources and have at it.

There is a kernel module for a2dp, but it is a DSP plugin and I assume a userspace driver to talk to it directly.

[rmausser]

OK thanks UnixPsycho,

I am swamped with work and have just simple patches on the go, that I can do in my spare time.

This would take a while to wrap my head around, even with 13 years of linux under my belt.

If someone else could take this project on, that would be amazing.

Heres the code:

https://github.com/CyanogenMod/andro...udio/ipctest.c

[TheOneill]

If someone is still interested by a path for this, maybe I found something interesting making grep accross the compiled libs :

I'm using 2.2.4 on a Veer :

in /usr/lib/libPmBtBsaif.so which is a binary file, you find some ASCII sequence with something about bitpool and samplefreq and "%d" in the sting so that a specific integer is inserted (the bitppol or the sample freq returned by a specific function). As it is compiled, there's nothing we can do about these function, but we may try overwriting %d and hardcode the desired bitpool/freq.

I had interesting results with my Sony BT receiver patching the file in hex mode (very important to avoid inserting byte in the bin file) with np++ for instance. I tried to force bitpool 80 and samplefreq 48000, see attached pic. With that, I get a decent quality (without patching, the quality is really really poor), but it may be finetuned, and it may depend on receiver capabilites.

Someone else want to try that ?

As dkirker explains just below, these are just debugging outputs and therefore changing them does not affect audio quality unfortunately. I guess the quality difference I noticed what just due to the fact that I reset the phone right before testing the postmod whereas the phone had been running for a while when I tested the premod. I made some more tests yesterday in the same conditions (after a reset) and the quality is the same with or without the patch.

Sorry for that !

[dkirker]

Originally Posted by TheOneill

If someone is still interested by a path for this, maybe I found something interesting making grep accross the compiled libs :

I'm using 2.2.4 on a Veer :

in /usr/lib/libPmBtBsaif.so which is a binary file, you find some ASCII sequence with something about bitpool and samplefreq and "%d" in the sting so that a specific integer is inserted (the bitppol or the sample freq returned by a specific function). As it is compiled, there's nothing we can do about these function, but we may try overwriting %d and hardcode the desired bitpool/freq.

I had interesting results with my Sony BT receiver patching the file in hex mode (very important to avoid inserting byte in the bin file) with np++ for instance. I tried to force bitpool 80 and samplefreq 48000, see attached pic. With that, I get a decent quality (without patching, the quality is really really poor), but it may be finetuned, and it may depend on receiver capabilites.

Someone else want to try that ?

I have a strong feeling that those values are just debugging outputs... Generally that information is passed around in a system as integer values and not as strings. Unless you are passing JSON data between components, but those strings aren't formatted as JSON. As to why you perceived better quality after the change? I am not sure.

Ideally, you want to find where it is getting those numbers from.

[TheOneill]

yes, you're probably right, it looks like debugging outputs. When I tested yesterday with the bt receiver, I had a better quality after patching, but maybe it is just the negociation between the receiver and the phone that ened differently (as I guess that these values are negociated when pairing?). I'll try with the mw600 of a friend. I tried it in the past before patching anything and the sound was awfull.

[dkirker]

Originally Posted by TheOneill

yes, you're probably right, it looks like debugging outputs. When I tested yesterday with the bt receiver, I had a better quality after patching, but maybe it is just the negociation between the receiver and the phone that ened differently (as I guess that these values are negociated when pairing?). I'll try with the mw600 of a friend. I tried it in the past before patching anything and the sound was awfull.

Make sure that you do your tests after a fresh restart. Audio quality can degrade greatly when a system has been running for a while.

[rmausser]

Still no way to fix this?

Sad Face.