From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <cyrus@holtmann.org>
MIME-Version: 1.0
In-Reply-To: <1660E2CC4AF24655A1FFE788570A34FF@mapleworks.com>
References: <1660E2CC4AF24655A1FFE788570A34FF@mapleworks.com>
From: Nick Pelly <npelly@google.com>
Date: Mon, 15 Mar 2010 14:35:13 -0700
Message-ID: <35c90d961003151435i6dc2a096j300198decb4844e6@mail.gmail.com>
Subject: Re: A strange compatible problem for eSCO audio with CSR USB
	Bluetooth dongle
To: Cooper Xu <cooper.xu@mapleworks.com>
Cc: linux-bluetooth@vger.kernel.org
Content-Type: text/plain; charset=ISO-8859-1
Sender: linux-bluetooth-owner@vger.kernel.org
List-ID: <linux-bluetooth.vger.kernel.org>

On Sun, Mar 14, 2010 at 4:01 PM, Cooper Xu <cooper.xu@mapleworks.com> wrote:
> Hi,
>
>
> We have a strange compatible problem with Bluez for eSCO audio.
>
> We develope an embedded application based on Bluez library that can play the
> role of HF and it uses a generic CSR USB Bluetooth dongle. The application
> worked well for most cell phones (iPhone, Blackberry etc). But when we tried
> it with an Android phone (Motorola Droid), we found one way voice problem.
> The Android phone side can not hear the voice.
>
> We know that Android phone also uses the Bluez library. So we tried to pair
> our application with another Linux with Bluez library with another CSR USB
> Bluetooth dongle. We used "hcidump" to capture the SCO packets in that
> system. We received a lot of SCO packets, but the content of packets is all
> zero. However from another end of SCO connection, we actually sent a lot
> non-zero contents.
>
> To simply our debug, we then used the "scotest" program from the Bluez 4.65
> source and used one system as client and another as server. From the hcidump
> output, we still saw the content of packets is all zero. However when we
> changed one USB dongle to another USB dongle with the Broadcom chipset, we
> can receive some non-zero data. In both case, we didn't see Bluez kernel
> error message.
>
> The Linux kernel for the system we used for test is 2.6.30.  The attachment
> is the SCO packet we captured for receiving side. The following is the
> information of Bluetooth USB dongle we use:
>
>
>        hciconfig -a
>
>        hci0:   Type: USB
>
>        BD Address: 00:11:F6:0B:CA:EE ACL MTU: 310:10 SCO MTU: 64:8
>        UP RUNNING PSCAN AUTH ENCRYPT
>        RX bytes:2081370 acl:185 sco:17775 events:9695 errors:0
>        TX bytes:252089 acl:164 sco:3002 commands:4693 errors:0
>        Features: 0xff 0xff 0x8f 0xfe 0x9b 0xf9 0x00 0x80
>        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
>        Link policy: RSWITCH HOLD SNIFF PARK
>        Link mode: SLAVE ACCEPT
>        Name: 'test'
>        Class: 0x000408
>        Service Classes: Unspecified
>        Device Class: Audio/Video, Hands-free
>        HCI Ver: 2.0 (0x3) HCI Rev: 0xc5c LMP Ver: 2.0 (0x3) LMP Subver:
> 0xc5c
>        Manufacturer: Cambridge Silicon Radio (10)
>
>
>
>        hciconfig hci0 revision:
>
>        hci0:   Type: USB
>
>          BD Address: 00:11:F6:0B:CA:EE ACL MTU: 310:10 SCO MTU: 64:8
>          Unified 21e
>          Chip version: BlueCore4-ROM
>          Max key size: 128 bit
>          SCO mapping:  HCI
>
>
> This audio problem seems only happen if both ends use Bluez library. If one
> side uses a different Bluetooth library, this issue will not appear. What
> can be the cause of this? I am very confused.

I wonder if this is some eSCO packet type incompatibility between
chipsets. Try setting /sys/module/sco/parameters/disable_esco to 1 to
see if this resolves the issue.

Nick