If I'm wrong about headsets reporting their desired bitpool values, and in fact they aren't providing that information at all, then a quick modification of sbc.c can be done to change the default sbc encoder settings:

static void sbc_set_defaults(sbc_t *sbc, unsigned long flags)
{
	sbc->frequency = SBC_FREQ_44100;
	sbc->mode = SBC_MODE_STEREO;
	sbc->subbands = SBC_SB_8;
	sbc->blocks = SBC_BLK_16;
	sbc->bitpool = 32;
#if __BYTE_ORDER == __LITTLE_ENDIAN
	sbc->endian = SBC_LE;
#elif __BYTE_ORDER == __BIG_ENDIAN
	sbc->endian = SBC_BE;
#else
#error "Unknown byte order"
#endif
}

You may even be able to do a hex edit on the libsbc binary to set the default to 53 by changing a few bytes in the right place.

The information in my previous post is still good, but I think this post is a better starting point for someone out there who's willing to give this a shot and report back.

I tried making the change suggested above in sbc.c to set the default bitpool to 54 but logcat still shows the same 32:2 value when I turn on my headphones.

W/BTLD ( 432): ### alloc : 3, blk len 240, chmode:15, bitpool 32:2, subbands 12

To test the change I recompiled the whole Android build and dropped a new liba2dp.so on my HD2. Maybe that's not the .so that contains this code or maybe there's something else. I'll experiment more and see what I can figure out.

Originally Posted by mcheffe

I tried making the change suggested above in sbc.c to set the default bitpool to 54 but logcat still shows the same 32:2 value when I turn on my headphones.

W/BTLD ( 432): ### alloc : 3, blk len 240, chmode:15, bitpool 32:2, subbands 12

To test the change I recompiled the whole Android build and dropped a new liba2dp.so on my HD2. Maybe that's not the .so that contains this code or maybe there's something else. I'll experiment more and see what I can figure out.

If you're making the change in post #21, then I think you'll want to replace the libsbc binary. If you've already done that and you are still getting a negotiated bitpool of 32, then that means your headset might be reporting a max bitpool of 32 (thus overriding whatever you set in sbc.c) so you should look at post #19 for some possible edits to liba2dp.

Originally Posted by bex0rs

If you're making the change in post #21, then I think you'll want to replace the libsbc binary. If you've already done that and you are still getting a negotiated bitpool of 32, then that means your headset might be reporting a max bitpool of 32 (thus overriding whatever you set in sbc.c) so you should look at post #19 for some possible edits to liba2dp.

Yes, based on the build output, it looks like sbc.c is linked into liba2dp.so.

While changing liba2dp.so didn't seem to affect anything, also changing libaudio.so breaks the bluetooth device connection.

I/BluetoothA2dpService( 224): checkSinkSuspendState() : state = 2 prevState = 0
I/BluetoothA2dpService( 224): checkSinkSuspendState() : mTargetA2dpState = -1
I/BluetoothA2dpService( 224): checkSinkSuspendState() : initialStart = false initialSuspend = false
I/BluetoothA2dpService( 224): setSinkPriority = Auto Connect
D/BluetoothA2dpService( 224): A2DP state : device: 00:0F:F6:2C:06:15 State:0->2
E/BTLD ( 416): bta_av_link_role_ok hndl:x41 role:1, conn_audio:x1, bits:1, features:x1
W/BTLD ( 416): bta_dm_rm_cback:1, status:0
W/BTLD ( 416): new conn_srvc id:18, app_id:0
E/BTLD ( 416): Disabling LPM
E/BTLD ( 416): bta_av_start_ok suspending: 0, role:x0
I/BTL-IFS ( 416): send_ctrl_msg: [BTL_IFS CTRL] send BTLIF_DTUN_SIGNAL_EVT (CTRL) 44 pbytes (hdl 15)
E/BTL_AV_CODEC: ( 416): Not started yet!
E/BTL_AV_CODEC: ( 416): Not started yet!
E/BluetoothEventLoop.cpp( 224): event_filter: Received signal org.bluez.AudioSink:Playing from /org/bluez/433/hci0/dev_00_0F_F6_2C_06_15
E/BluetoothEventLoop.cpp( 224): event_filter: Received signal org.bluez.AudioSink:PropertyChanged from /org/bluez/433/hci0/dev_00_0F_F6_2C_06_15
E/BluetoothEventLoop.cpp( 224): event_filter: Received signal org.bluez.AudioSink:PropertyChanged from /org/bluez/433/hci0/dev_00_0F_F6_2C_06_15
I/BluetoothA2dpService( 224): checkSinkSuspendState() : state = 4 prevState = 2
I/BluetoothA2dpService( 224): checkSinkSuspendState() : mTargetA2dpState = -1
I/BluetoothA2dpService( 224): checkSinkSuspendState() : initialStart = false initialSuspend = false
D/A2DP ( 184): a2dp_init rate: 44100 channels: 2
D/A2DP ( 184): a2dp_thread started
D/A2dpAudioInterface( 184): A2dpAudioStreamOut::set 80, 0, 0, 0
D/A2dpAudioInterface( 184): setBluetoothEnabled 1
I/BluetoothA2dpService( 224): Send mute tone for remote AVDTP START
D/A2DP ( 184): bluetooth_init
E/A2DP ( 184): bt_audio_service_open failed
I/AudioFlinger( 184): AudioFlinger's thread 0x1ebf0 ready to run


I'm wondering if these files need to be built along with the ROM they're running on so that they maintain compatibility with other libraries in the system.

It looks to me like the source is broken down like this (based on the Android.mk Makefile in bluez/audio):

libaudio.so:
a2dp.c
avdtp.c
control.c
device.c
gateway.c
headset.c
ipc.c
main.c
manager.c
module-bluetooth-sink.c
sink.c
source.c
telephony-dummy.c
unix.c

liba2dp.so:
liba2dp.c
ipc.c
../sbc/sbc.c.arm
../sbc/sbc_primitives.c
../sbc/sbc_primitives_neon.c

Note that liba2dp.so refers to sbc.c.arm and not sbc.c. I don't know if sbc.c.arm is generated from sbc.c or what. I don't understand much of this yet as I'm still trying to learn the Android build.

Also, comments in the Makefile imply that libaudio.so is the A2DP plugin and liba2dp.so is used by Audioflinger. It is also possible to interpret the comments as meaning both the .so's comprise the plugin and liba2dp.so part is linked in to Audioflinger.

Anyway, not much progress yet...

Originally Posted by mcheffe

While changing liba2dp.so didn't seem to affect anything, also changing libaudio.so breaks the bluetooth device connection.

Also, comments in the Makefile imply that libaudio.so is the A2DP plugin and liba2dp.so is used by Audioflinger. It is also possible to interpret the comments as meaning both the .so's comprise the plugin and liba2dp.so part is linked in to Audioflinger.

Anyway, not much progress yet...

Keep at it, I'd love it if you could fix this!! My HD2 will then be the perfect device!

I do plan to try more experiments on this, just been busy lately. I've been running my modified liba2dp.so on my HD2 for a while now but I don't think it's having much effect. I really need to figure out what files comprise all the pieces of the Bluez implementation so I can test a proper install of all the files I built.

Sent from my HTC HD2

Hi all, having the same trouble with low quality a2db, even if it's way better than stupid WP7. There are some config files in "/etc/bluetooth/" on my Desire HD running Froyo, might this be a way to change A2DP settings? I'm in no way familiar with linux or conf files, but I'd hesitate to use other than stock roms or do some recompiling myself. Thanks, Cheers...

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

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;
		}

Well I´m also interested on a solution regarding this problem.
Just updated latest HTC Stock 2.29.405.2 and compared to previous Version it looks like something has changed (louder/quality?) - log still shows bitpool of 32

Config:
HW: HTC Desire
Player: Poweramp + equalizer
Headset: Sennheiser MM450

Anyone experiencing changes regarding A2dp for this rom version?

Beside this i wont use cyanogen mod - so i would appreciate a solution which works for nearly everyone
You can change bitpool on other mobile os very easy but not on android - ridiculous

I contribute some testing if some generic solution could be possible - i´m not able to generate code