[Bluez-users] Headset Noise Half the Time -- How to Apply This Fix??

["Alex S. Brown, PMP IPMA-C" <alex@rlprj.com>]

I am using a Motorola H700 headset with Ubuntu 8.04 (Bluez 3.26ubuntu6),
and I am seeing the exact same symptoms as Andrea did in her April post
(see below). About half the time, the headset connects properly. The
other half the time either the microphone or the speakers are filled
with noise. It is not like normal interference; it sounds like the
computer is misinterpreting the audio codec.

I would like to apply Andrea's fix, but I have no idea how to do it. Her
solution is posted under this link, and I also quoted it below:
<http://sourceforge.net/mailarchive/message.php?msg_id=20080414100543.GA9430%40duo.random>

Here are my questions:
1. Has this fix somehow been incorporated into the latest build? (I
cannot find detailed release notes to tell one way or the other)
2. If not, should I go to the latest released version, and then add
Andrea's fixes according to the diff, then rebuild? Should I go back to
the 3.30 version that she mentions instead?
3. Is anyone else seeing this same problem? Is there a better solution?

I really had trouble following the thread. I see notes like "the patch
is not OK if applied like this" and recommendations to use "my previous
patch instead".

Sorry if I am asking too basic a question. I know something about
utilities like diff, but I am really uncertain about applying a patch
like this one. I am just not sure about what actually worked and what
did not from reading the previous post.

Thanks,
Alex


> [Bluez-users] howto wep 500
> From: Andrea Arcangeli <andrea@cp...> - 2008-04-21 01:09
> 
> 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. 

-- 
Alex S. Brown, PMP, IPMA-C
Owner, President and CEO (Chief Everything Officer)
Real-Life Projects, Inc.
When you don't have time to waste...

alex@rlprj.com
http://www.rlprj.com
+1 908 428 2048

My articles: http://www.alexsbrown.com

Network with me at
OpenBC/XING: https://www.xing.com/profile/AlexS_Brown
LinkedIn: http://www.linkedin.com/in/alexsbrown
Facebook: http://www.facebook.com/people/Alex_S_Brown/575587928

Want to learn more?
Sign up for my free newsletter at
http://www.alexsbrown.com/newsletter.html
Take one of my on-line classes at
http://www.rlprj.com/onlinetraining.html


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users