Return-Path: Message-ID: <448077B0.3090509@bartol.udel.edu> Date: Fri, 02 Jun 2006 13:38:56 -0400 From: Rich Townsend MIME-Version: 1.0 To: BlueZ development References: <4469387E.5000203@bartol.udel.edu> <1148909788.31689.66.camel@localhost> In-Reply-To: <1148909788.31689.66.camel@localhost> Subject: Re: [Bluez-devel] SCO MTU problem on CSR-based Belkin F8T020/F8T007 Reply-To: BlueZ development List-Id: BlueZ development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Sender: bluez-devel-bounces@lists.sourceforge.net Errors-To: bluez-devel-bounces@lists.sourceforge.net Marcel Holtmann wrote: > Hi Rich, > > >>I've recently acquired a Belkin F8T020/F8T007 PCMCIA bluetooth interface >>(basically, a compact flash card in an adapter sleeve), and I'm trying to get >>this linked up to a Digiwave BH-2000 headset. >> >>Mostly, everything is functioning correctly; the interface provides a UART on >>/dev/ttyS3, which Bluez has no problem working with using the hci_uart driver. >>The problem, however, comes in getting the ALSA module, snd_bt_sco, to behave >>properly. I can get the headset to connect to my computer, and do things such as >>change the volume; but I've had no luck in getting any sound to play on the headset. >> >>After a little digging around, it turns out that no SCO packets are being >>transmitted by the interface. Closer investigation shows that the problem is >>with the outgoing MTU; the len value passed to sco_send_frame is invariably >>longer than the default SCO MTU of the interface (64), with the result that >>sco_send_frame aborts early with an EINVAL return value (which in turn is >>silently ignored). >> >>As a test fix, I upped the SCO MTU on the interface to 255, and now stuff >>actually gets transmitted -- and I can hear sound on the headset, albeit very >>distorted. >> >>So, it seems snd_bt_sco is disregarding the MTU settings of the interface. Why, >>I'm not sure; a quick look through the snd_bt_sco source code doesn't reveal >>anything obvious (in fact, it's not clear how the module picks up the MTU). I'd >>appreciate hearing suggestions about how I might go about fixing this. >> >>For the record: >> >>Kernel 2.6.16 (x86) >> >>hciconfig -a (after upping MTU so TX works): >> >>hci0: Type: UART >> BD Address: 00:02:72:81:23:27 ACL MTU: 192:8 SCO MTU: 255:8 >> UP RUNNING PSCAN ISCAN AUTH ENCRYPT >> RX bytes:5063515 acl:52 sco:30471 events:94 errors:0 >> TX bytes:4612824 acl:42 sco:0 commands:27604 errors:0 >> Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00 >> Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 >> Link policy: RSWITCH HOLD SNIFF PARK >> Link mode: SLAVE ACCEPT >> Name: 'BlueZ (0)' >> Class: 0x000100 >> Service Classes: Unspecified >> Device Class: Computer, Uncategorized >> HCI Ver: 1.1 (0x1) HCI Rev: 0x110 LMP Ver: 1.1 (0x1) LMP Subver: 0x110 >> Manufacturer: Cambridge Silicon Radio (10) >> >>hcitool info 00:13:8A:06:31:0E (the headset): >> >>Requesting information ... >> BD Address: 00:13:8A:06:31:0E >> Device Name: BH2000 >> LMP Version: 1.2 (0x2) LMP Subversion: 0x611 >> Manufacturer: Cambridge Silicon Radio (10) >> Features: 0xfc 0xfe 0x0f 0x00 0x08 0x08 0x00 0x00 >> >> >>

>> >> >> >>Big note: both devices are CSR, so this *ISN'T* the well-known MTU problem >>experienced by Broadcom chipsets. Smaller note: although the hciconfig output is >>after I upped the MTU and got (distorted) sound on the headset, the SCO TX count >>is still at zero. Hmmmm.... >> >>Let me know if you need more info... > > > run "hciconfig hci0 revision" as root and see if the SCO mapping is done > over PCM or HCI. OK, here's what I get: hci0: Type: UART BD Address: 00:02:72:81:23:27 ACL MTU: 192:8 SCO MTU: 64:8 HCI 14.3 Chip version: BlueCore02-External (ES2) Max key size: 56 bit SCO mapping: HCI As you can see, the mapping is over HCI, so it should work, right? cheers, Rich _______________________________________________ Bluez-devel mailing list Bluez-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-devel