howto wep 500

I didn't receive any feedback so far, so I give it a second try this
weekend.

So the S16_LE stream sometime was byte swapped (big endian format
instead of little endian, randomly). Verified with hcidump with
arecord (only fragment reassembly and usb code was involved, so it
couldn't be anything in userland, and quickly it become clear it's a
bug in the headset firmware). This always happens in all isocs
supporting 16 bit transfers (and some isocs just returns partial
garbage or a zero stream). voice 0x40 in isoc=2 also returns streams
of zeros or garbage. So I tried voice 0x40 in isoc=1 and it returns
nothing sane too.

So I figured out the phone had to be using alaw or mulaw. I thought
alaw and mulaw should work with isochronous alternative 2 too (default
of hci_usb) but it doesn't with my headset (alt 2 supports 1 16bit
channel or 2 8bit channels for two bluetooth handles in the same
isochronous endpoint).

Luckily I kept trying in all possible ways and finally I got it
working perfectly by adding to modules.d a file like this:

options hci_usb isoc=1

And adding this line at the end of /etc/init.d/bluetooth start:

        hciconfig hci0 voice 0x240

After this I had to patch bluez-utils-3.30 and to recompile it 16bit
for skype, and now skype works perfectly with my headset. I've still a
minor issue with twinkle, the capture doesn't produce crystal clear
sound. I use a-law for all my asterisk voip so in theory twinkle
should learn to forward the packets generated by the headset directly
to the network without converting them to S16_LE, but arecord |aplay
in S16_LE mode returns a fine good sound quality too through the plug
device, so even if it converts back and forth it's ok.

diff -ur bluez-utils-3.30/audio/pcm_bluetooth.c /var/tmp/portage/net-wireless/bluez-utils-3.30/work/bluez-utils-3.30/audio/pcm_bluetooth.c
--- bluez-utils-3.30/audio/pcm_bluetooth.c	2008-04-14 04:03:03.000000000 +0200
+++ /var/tmp/portage/net-wireless/bluez-utils-3.30/work/bluez-utils-3.30/audio/pcm_bluetooth.c	2008-04-20 07:35:01.000000000 +0200
@@ -462,7 +462,9 @@
 	}
 
 	data->transport = setconf_rsp->transport;
-	data->link_mtu = setconf_rsp->link_mtu;
+	if (data->link_mtu != setconf_rsp->link_mtu)
+		SNDERR("BT_SETCONFIGURATION link_mtu ignored: %d",
+					setconf_rsp->link_mtu);
 
 	return 0;
 }
@@ -1157,7 +1159,8 @@
 		SND_PCM_ACCESS_MMAP_INTERLEAVED
 	};
 	unsigned int format_list[] = {
-		SND_PCM_FORMAT_S16_LE
+		//SND_PCM_FORMAT_S16_LE
+		SND_PCM_FORMAT_A_LAW
 	};
 	int err;
 
@@ -1629,10 +1632,13 @@
 		data->io.callback = stream == SND_PCM_STREAM_PLAYBACK ?
 			&bluetooth_a2dp_playback :
 			&bluetooth_a2dp_capture;
-	else
+	else {
 		data->io.callback = stream == SND_PCM_STREAM_PLAYBACK ?
 			&bluetooth_hsp_playback :
 			&bluetooth_hsp_capture;
+		data->link_mtu = 48;
+		data->link_mtu = 24;
+	}
 
 	err = snd_pcm_ioplug_create(&data->io, name, stream, mode);
 	if (err < 0)
diff -ur bluez-utils-3.30/audio/unix.c /var/tmp/portage/net-wireless/bluez-utils-3.30/work/bluez-utils-3.30/audio/unix.c
--- bluez-utils-3.30/audio/unix.c	2008-04-03 01:01:44.000000000 +0200
+++ /var/tmp/portage/net-wireless/bluez-utils-3.30/work/bluez-utils-3.30/audio/unix.c	2008-04-20 06:12:25.000000000 +0200
@@ -285,6 +285,7 @@
 	rsp->transport  = BT_CAPABILITIES_TRANSPORT_SCO;
 	rsp->access_mode = client->access_mode;
 	rsp->link_mtu = 48;
+	rsp->link_mtu = 24;
 
 	client->data_fd = headset_get_sco_fd(dev);
 


this is my .asoundrc:

pcm.bluetooth_raw {
	type bluetooth
	device 00:02:78:29:3F:D4
	profile "voice"
}

pcm.bluetooth {
	type plug
	slave {
		pcm "bluetooth_raw"
	}
}

The patch is not ok if applied like this. My previous patch instead
should be applied as I sent it as it includes a fix for everyone. The
ideal I guess is to read the voice in the same way hciconfig does it,
and if the a-law bit or mu-law bit are set, the link_mtu should be
assumed 24 bytes instead of 48, and the alsa initialization should use
A_LAW/MU_LAW instead of S16_LE. I can't work on this until next
weekend at the earliest, so I hope somebody else will clean this up
sooner now that the problem is understood ;). I suspect asterisk
bluetooth supports also hardcodes 48 bytes and doesn't support
anything but voice 0x60, it'd be nice not to hardcode those things and
to be dynamic in function of the hciconfig setting, even better would
be to match the headset features and to autodetect it per-connection
instead of per-hci device.

My headset should work with most if not all recent cellphones, so this
also means cellphones prefers a-law/mu-law to S16_LE if supported by
the headset.

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone