From: James Courtier-Dutton <James@superbug.demon.co.uk>
To: Steven Singer <steven.singer@csr.com>
Cc: BlueZ Mailing List <bluez-devel@lists.sourceforge.net>
Subject: Re: [Bluez-devel] sco / csr final notes
Date: Wed, 31 Mar 2004 20:10:28 +0100 [thread overview]
Message-ID: <406B17A4.8000607@superbug.demon.co.uk> (raw)
In-Reply-To: <406AF150.8080105@csr.com>
Steven Singer wrote:
> Simon Vogl wrote:
>
>>Steven Singer wrote:
>>
>>>Is the problem that the link spontaneously changes from correct to noisy
>>>in the middle of a link, or is it that when you start up a link it's
>>>either OK for the durection of the link, or noisy for the duration of
>>>the link and then when you tear it down and start a fresh link, the next
>>>one is, independently, correct our noisy?
>>>
>>>If it's the latter case, is the first link after a full reset (BCCMD
>>>reset or power cycle - not merely an HCI reset) ever noisy?
>>>
>>
>>the latter is the case. Whenever a fresh sco link starts, I have a 50% chance of
>>getting the wrong byte order..
>
>
> Assuming it never happens for the first link, then it might be known issue
> H16.169 (aka. B.104). This is present in 16.4 firmware and is fixed in
> 16.14. The following is the documentation of this issue from the 16.14
> release note (I've marked the relevant section with >>>chevrons<<<):
>
> ------------------------------------------------------------------------
> Appendix D – Issues Addressed Relative to HCI 16.4
>
> [...]
>
> ID: B.104, H16.169
> Severity: High
> Description:
>
> If a system routes HCI SCO channels over USB, there is a high
> probability that if two SCO channels are opened, and then one of them is
> closed, then the firmware will crash. This problem has not been seen if
> only one SCO channel is routed over USB. There is a related, but
> technically independent, problem. >>>If a USB SCO link is closed, and
> then a new USB SCO link is opened, it is possible for the second link’s
> from-air audio to be badly distorted.<<<
>
> The audio distortion problem occurs only where both SCO links use 16-bit
> samples. The distortion occurs where the host does not collect all of
> the bytes from the last HCI SCO packet of the first SCO link. The second
> SCO link reuses the first link’s endpoint, and the link’s data
> incorrectly starts with the first link’s few uncollected bytes. >>>This
> can be an odd number of bytes, misaligning all subsequent 16-bit samples
> by one byte.<<<
>
> The same audio distortion misalignment can result from a race hazard
> within the chip, even if the host takes all of the link’s trailing
> bytes when closing the SCO link. In practice, the race hazard is the
> primary cause of this problem arising. The distortion issue is similar
> to issue H13.154, but that issue concerned from-host SCO USB traffic.
>
> (HCI builds’ release notes have never claimed support for SCO over USB,
> mainly because of the lack of suitable test equipment, so it is arguable
> whether this issue should be categorised as being of “high” importance.)
>
> Remedy
> Both problems have been substantially improved in HCI 16.14. This avoids
> the issue that causes the chip to crash. The same defensive code also
> avoids the audio distortion problem.
> ------------------------------------------------------------------------
>
> I think this confirms your observations. The error is a missing byte and
> not an endian-ness switch. Upgrading your firmware should fix the
> problem, otherwise, swallowing a byte when you notice the problem should
> also ressurect the audio quality. Alternatively, you could always switch
> to 8 bit samples.
>
> Release notes are available on the CSR support web site if you have
> suitable access permissions.
>
> - Steven
Just out of interest, how does one upgrade the firmware on a USB device
using a CSR chip ?
I have this device: -
bash-2.05b# hciconfig hci0 version
hci0: Type: USB
BD Address: 00:A0:96:1F:42:BF ACL MTU: 192:8 SCO MTU: 64:8
HCI Ver: 1.1 (0x1) HCI Rev: 0x135 LMP Ver: 1.1 (0x1) LMP
Subver: 0x135
Manufacturer: Cambridge Silicon Radio (10)
bash-2.05b# hciconfig hci0 revision
hci0: Type: USB
BD Address: 00:A0:96:1F:42:BF ACL MTU: 192:8 SCO MTU: 64:8
HCI 13.10
Chip version: BlueCore01b
Max key size: 56 bit
SCO mapping: HCI
Cheers
James
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
next prev parent reply other threads:[~2004-03-31 19:10 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-31 10:32 [Bluez-devel] sco / csr final notes Simon Vogl
2004-03-31 10:59 ` Marcel Holtmann
2004-03-31 11:48 ` Simon Vogl
2004-03-31 15:09 ` Steven Singer
2004-03-31 15:13 ` Simon Vogl
2004-03-31 16:26 ` Steven Singer
2004-03-31 19:10 ` James Courtier-Dutton [this message]
2004-03-31 19:36 ` Marcel Holtmann
2004-03-31 20:18 ` James Courtier-Dutton
2004-03-31 20:29 ` Marcel Holtmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=406B17A4.8000607@superbug.demon.co.uk \
--to=james@superbug.demon.co.uk \
--cc=bluez-devel@lists.sourceforge.net \
--cc=steven.singer@csr.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.