Return-Path: Date: Mon, 21 Apr 2008 03:09:32 +0200 From: Andrea Arcangeli To: BlueZ users Message-ID: <20080421010932.GA9614@duo.random> References: <20080413163949.da11ab14.profbunny@gmx.de> <20080413222952.132a1aa6.profbunny@gmx.de> <20080414100543.GA9430@duo.random> MIME-Version: 1.0 In-Reply-To: <20080414100543.GA9430@duo.random> Subject: [Bluez-users] howto wep 500 Reply-To: BlueZ users List-Id: BlueZ users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Sender: bluez-users-bounces@lists.sourceforge.net Errors-To: bluez-users-bounces@lists.sourceforge.net 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 _______________________________________________ Bluez-users mailing list Bluez-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-users