Hi all,
it seems like this is the answer to sco quality problems - I see lots of
packets arriving on
a different channel, but patched to a size of 48:
< HCI Command: Add SCO Connection(0x01|0x0007) plen 4
> HCI Event: Command Status(0x0f) plen 4
> HCI Event: Max Slots Change(0x1b) plen 3
> ACL data: handle 0x0029 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 1 scid 0x0070
< ACL data: handle 0x0029 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0041 scid 0x0070 result 0 status 0
> HCI Event: Number of Completed Packets(0x13) plen 5
> HCI Event: Connect Complete(0x03) plen 11
< SCO data: handle 0x002c dlen 48
> SCO data: handle 0x0035 dlen 48
> SCO data: handle 0x002c dlen 48
> SCO data: handle 0x002c dlen 48
> SCO data: handle 0x002c dlen 48
> ACL data: handle 0x0029 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x0041 flags 0x0000 clen 0
< ACL data: handle 0x0029 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0070 flags 0x0000 result 0 clen 0
< ACL data: handle 0x0029 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x0070 flags 0x0000 clen 0
< SCO data: handle 0x002c dlen 48
< SCO data: handle 0x002c dlen 48
> HCI Event: Mode Change(0x14) plen 6
> HCI Event: Mode Change(0x14) plen 6
> HCI Event: Connect Request(0x04) plen 10
< HCI Command: Accept Connection Request(0x01|0x0009) plen 7
> HCI Event: Command Status(0x0f) plen 4
> HCI Event: Connect Complete(0x03) plen 11
< HCI Command: Change Connection Packet Type(0x01|0x000f) plen 4
< SCO data: handle 0x002c dlen 48
> HCI Event: Max Slots Change(0x1b) plen 3
> HCI Event: Command Status(0x0f) plen 4
> SCO data: handle 0x002e dlen 48
> SCO data: handle 0x002c dlen 48
> SCO data: handle 0x002c dlen 48
< SCO data: handle 0x002c dlen 48
< SCO data: handle 0x002c dlen 48
> SCO data: handle 0x002c dlen 48
It seems to me like the alternate handle id is created by a shift and or
operation (id | (id>>1))...
Can anyone knowing the usb driver better than me comment on this?
thx
Simon
Hi all.
After installing bluez on the DevBoard, I do "hciconfig -a hci0 up" and t=
hen
"hcitool scan"
and the scan find my other BT-Devices !!
(But only one time !? )
When I do "hcitool scan" again, the system freez, too
and my terminal program prints hundred of row's, like that:
-------------------------------------------------------------------------=
---
-------------
....
Warning: kfree_skb on hard IRQ c008e1bc
Scheduling in interrupt
kernel BUG at sched.c:564!
Scheduling in interrupt
kernel BUG at sched.c:564!
Scheduling in interrupt
kernel BUG at sched.c:564!
Warning: kfree_skb on hard IRQ c008e1bc
Warning: kfree_skb on hard IRQ c008e1bc
Warning: kfree_skb on hard IRQ c008e1bc
Warning: kfree_skb on hard IRQ c008e1bc
Warning: kfree_skb on hard IRQ c008e1bc
Warning: kfree_skb on hard IRQ c008e1bc
Warning: kfree_skb on hard IRQ c008e1bc
Warning: kfree_skb on hard IRQ c008e1bc
Warning: kfree_skb on hard IRQ c008e1bc
Warning: kfree_skb on hard IRQ c008e1bc
Warning: kfree_skb on hard IRQ c008e1bc
Scheduling in interrupt
...
Scheduling in interrupt
kernel BUG at sched.c:564!
kernel BUG at slab.c:971!
kernel BUG at slab.c:971!
Scheduling in interrupt
kernel BUG at sched.c:564!
Scheduling in interrupt
kernel BUG at sched.c:564!
Scheduling in interrupt
kernel BUG at sched.c:564!
Warning: kfree_skb on hard IRQ c008e1bc
Scheduling in interrupt
kernel BUG at sched.c:564!
Unable to handle kernel access at virtual address 355ee000
Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing
Oops: bitten by watchdog
IRP: c0007f64 SRP: c0007f18 DCCR: 00000424 USP: 9ffff1d8 MOF: 00000000
r0: c01080e4 r1: c00ed150 r2: c012e4c8 r3: c0ce4000
r4: 9ffff210 r5: 00000001 r6: 9ffffe1c r7: 00000000
r8: 00000002 r9: 00000000 r10: 00000000 r11: 00000000
r12: 00000000 r13: 00000000 oR10: 00000000
R_MMU_CAUSE: 355ee809
Process klogd (pid: 118, stackpage=3Dc0ce4000)
Stack from 9ffff1d8:
Failing address 0x9ffff1d8
Call Trace: Failing address 0x9ffff1d8
Stack from c0ce5df8:
c0008532 c0ce5e74 c005b912 c005ba70 00000000 00000000 9ffff210
c0ce4000
c012e4c8 c00ed150 c0ce5e30 c005baf0 c01080e4 c005b7b4 00000000
00000000
00000000 00000000 00000000 00000000 00000000 00000002 00000000
9ffffe1c
Call Trace: [<c0008532>] [<c005b912>] [<c005ba70>] [<c005baf0>] [<c005b7b=
4>]
[<c0007f18>] [<c0007f64>]
[<c0008532>] [<c0007f18>] [<c0008532>] [<c00093a6>] [<c0008532>]
[<c005de42>] [<c0089d8a>] [<c0089f2c>]
[<c00200d8>] [<c005dbf0>] [<c005b72a>] [<c005b670>]
Code: f1 20 7a 86 3f bd 70 aa 05 c0 b0 25 (ff) e0 0f 05 fc e1 7e be 84 e2=
fe
0b
-------------------------------------------------------------------------=
---
-------------------------------------------
"hcitool dev", "hcitool inq" and "hcitool name bdaddr" works fine.
The effect of "hcitool info bdaddr" is a kernel panic !
I use a CSR-BT-Module, which is connected via USB, too.
Any Ideas?
Regards
Tobias Sprafke
Mobile: +49 (0) 177 64 32 313
Fon: +49 (0) 208 75 10 123
E-Mail: [email protected]
Have a lot of fun ... :-)
-----Urspr=FCngliche Nachricht-----
Von: [email protected]
[mailto:[email protected]]Im Auftrag von Eric
Chapman
Gesendet: Dienstag, 9. M=E4rz 2004 11:51
Cc: BlueZ Mailing List
Betreff: [Bluez-devel] USB Device hangs
Hi List,
I am currently using a Axis Developer Board (Embedded Linux), for which
I have cross-compiled parts of BlueZ. I am using 2 Bluettooth dongles,
one serial and on USB. Both have a CSR BC02 chip and are rev. 16.4.
I can "hciconfig up" and "down" them, inquire via "hcitool inq". But as
soon as I do a "hcitool scan" or a "l2ping" using the USB dongle, the
whole box freezes up. With the serial one (which I have to activate
first using "hciattach") everything works just fine. Unfortunately I
need the USB for matters of speed.
Anyone got a hint where to start lookin, or how to maybe get some
debugging info out of hcitool (for ex.) before it crashes?
Eric
--
Eric Chapman
-----------------
Lehrstuhl f=FCr Nachrichtentechnik
Universit=E4t des Saarlandes
Postfach 15 11 50
D-66041 Saarbr=FCcken
Tel: +49 681 302 3975
Fax: +49 681 302 3972
Web: http://www.lnt.uni-saarland.de
-------------------------------------------------------
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_id638&op=CCk
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi List,
I am currently using a Axis Developer Board (Embedded Linux), for which=20
I have cross-compiled parts of BlueZ. I am using 2 Bluettooth dongles,=20
one serial and on USB. Both have a CSR BC02 chip and are rev. 16.4.
I can "hciconfig up" and "down" them, inquire via "hcitool inq". But as=20
soon as I do a "hcitool scan" or a "l2ping" using the USB dongle, the=20
whole box freezes up. With the serial one (which I have to activate=20
first using "hciattach") everything works just fine. Unfortunately I=20
need the USB for matters of speed.
Anyone got a hint where to start lookin, or how to maybe get some=20
debugging info out of hcitool (for ex.) before it crashes?
Eric
--=20
Eric Chapman
-----------------
Lehrstuhl f=FCr Nachrichtentechnik
Universit=E4t des Saarlandes
Postfach 15 11 50
D-66041 Saarbr=FCcken
Tel: +49 681 302 3975
Fax: +49 681 302 3972
Web: http://www.lnt.uni-saarland.de
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi James,
no problem, I can test whatever you like (except that I don't own a BT=20
analyser).
ad 1) is there some debug output I can enable in the, say, hci_usb=20
driver? Where should I add code there?
ad 2) noise is quite normal, I think, but it should not lead to the=20
'inverted stream' problem: If the header itself
is alright, there might be noise in the data, but not a lost byte....
Give me a shovel, I start digging ;)
Simon
James Courtier-Dutton wrote:
> This problem might be related to how we deal with SCO in the bluez=20
> driver.
> Basically, we receive an URB with 10 usb frames it it, equivalent to=20
> 10ms.
> 3 usb frames make up a single SCO frame for the headset profile.
> We just assume that the first usb frame we get is the beginning of a=20
> SCO frame. We then just work on from there.
> First frame is header, get length from that header, grab the rest of=20
> the SCO frame based on header length.
> I have not determined in which situations this assumption is wrong.
> Here are some ideas, but I need to prove them right or wrong.
> 1) missed interrupt, so an urb gets lost.
> 2) air radio noise causing some of the HCI SCO data to be lost. I have=20
> been told that what happens on the air radio will not effect the=20
> contents of HCI SCO packets, as the CSR chip should fill in lost=20
> samples with predicted samples.
>
> The problem is that there is no CRC check in HCI SCO frames, so=20
> detecting whether some usb frame is the SCO header or not is difficult.
>
> Any suggestions?
>
> Cheers
> James
>
>
> Dr. Simon Vogl wrote:
>
>> Hi all,
>> it seems like this is the answer to sco quality problems - I see lots=20
>> of packets arriving on
>> a different channel, but patched to a size of 48:
>>
>> < HCI Command: Add SCO Connection(0x01|0x0007) plen 4
>> > HCI Event: Command Status(0x0f) plen 4
>> > HCI Event: Max Slots Change(0x1b) plen 3
>> > ACL data: handle 0x0029 flags 0x02 dlen 12
>> L2CAP(s): Connect req: psm 1 scid 0x0070
>> < ACL data: handle 0x0029 flags 0x02 dlen 16
>> L2CAP(s): Connect rsp: dcid 0x0041 scid 0x0070 result 0 status 0
>> > HCI Event: Number of Completed Packets(0x13) plen 5
>> > HCI Event: Connect Complete(0x03) plen 11
>> < SCO data: handle 0x002c dlen 48
>> > SCO data: handle 0x0035 dlen 48
>> > SCO data: handle 0x002c dlen 48
>> > SCO data: handle 0x002c dlen 48
>> > SCO data: handle 0x002c dlen 48
>> > ACL data: handle 0x0029 flags 0x02 dlen 12
>> L2CAP(s): Config req: dcid 0x0041 flags 0x0000 clen 0
>> < ACL data: handle 0x0029 flags 0x02 dlen 14
>> L2CAP(s): Config rsp: scid 0x0070 flags 0x0000 result 0 clen 0
>> < ACL data: handle 0x0029 flags 0x02 dlen 12
>> L2CAP(s): Config req: dcid 0x0070 flags 0x0000 clen 0
>> < SCO data: handle 0x002c dlen 48
>> < SCO data: handle 0x002c dlen 48
>>
>>
>> > HCI Event: Mode Change(0x14) plen 6
>> > HCI Event: Mode Change(0x14) plen 6
>> > HCI Event: Connect Request(0x04) plen 10
>> < HCI Command: Accept Connection Request(0x01|0x0009) plen 7
>> > HCI Event: Command Status(0x0f) plen 4
>> > HCI Event: Connect Complete(0x03) plen 11
>> < HCI Command: Change Connection Packet Type(0x01|0x000f) plen 4
>> < SCO data: handle 0x002c dlen 48
>> > HCI Event: Max Slots Change(0x1b) plen 3
>> > HCI Event: Command Status(0x0f) plen 4
>> > SCO data: handle 0x002e dlen 48
>> > SCO data: handle 0x002c dlen 48
>> > SCO data: handle 0x002c dlen 48
>> < SCO data: handle 0x002c dlen 48
>> < SCO data: handle 0x002c dlen 48
>> > SCO data: handle 0x002c dlen 48
>>
>> It seems to me like the alternate handle id is created by a shift and=20
>> or operation (id | (id>>1))...
>> Can anyone knowing the usb driver better than me comment on this?
>> thx
>> Simon
>>
>>
>> ----------------------------------------------------------------------=
--
>>
>> Subject:
>> Re: [Bluez-devel] sco links
>> From:
>> Carl Orsborn <[email protected]>
>> Date:
>> Wed, 03 Mar 2004 16:10:14 +0000
>> To:
>> Simon Vogl <[email protected]>
>>
>> To:
>> Simon Vogl <[email protected]>
>>
>> Return-Path:
>> <[email protected]>
>> Received:
>> from mail1.edvz.uni-linz.ac.at (mail1.edvz.uni-linz.ac.at=20
>> [140.78.3.68]) by zeus.soft.uni-linz.ac.at (8.11.7p1+Sun/8.11.1) with=20
>> ESMTP id i23G8qj05391 for <[email protected]>; Wed, 3 Mar 2004=20
>> 17:08:52 +0100 (MET)
>> Received:
>> from mailsweeperjp.CSR.COM ([202.214.225.228]) by=20
>> mail1.edvz.uni-linz.ac.at (8.12.10/8.12.9) with ESMTP id=20
>> i23G8kRR043780 for <[email protected]>; Wed, 3 Mar 2004=20
>> 17:08:48 +0100 (CET) (envelope-from [email protected])
>> Received:
>> from exchangejp.csr.com (unverified) by mailsweeperjp.CSR.COM=20
>> (Content Technologies SMTPRS 4.3.1) with ESMTP id=20
>> <[email protected]> for=20
>> <[email protected]>; Thu, 4 Mar 2004 01:10:55 +0900
>> Received:
>> from EXCHANGE02.csr.com ([192.168.137.45]) by exchangejp.csr.com with=20
>> Microsoft SMTPSVC (5.0.2195.6713); Wed, 3 Mar 2004 16:10:22 +0000
>> Received:
>> from csr.com ([192.168.143.41]) by EXCHANGE02.csr.com with Microsoft=20
>> SMTPSVC (5.0.2195.5329); Wed, 3 Mar 2004 16:10:14 +0000
>> Message-ID:
>> <[email protected]>
>> User-Agent:
>> Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4)=20
>> Gecko/20030624 Netscape/7.1 (ax)
>> X-Accept-Language:
>> en-us, en
>> MIME-Version:
>> 1.0
>> References:
>> <[email protected]>
>> In-Reply-To:
>> <[email protected]>
>> Content-Type:
>> text/plain; charset=3Dus-ascii; format=3Dflowed
>> Content-Transfer-Encoding:
>> 7bit
>> X-OriginalArrivalTime:
>> 03 Mar 2004 16:10:14.0469 (UTC) FILETIME=3D[03158750:01C4013A]
>>
>>
>> Hi, Simon.
>>
>> Not my normal domain, but the normal cause of misaligning by
>> 1 byte is that USB uses an isochronous (i.e., unreliable) channel
>> for SCO, and one can send an odd number of bytes in a USB packet,
>> so losing a packet leads to the offset. Audio samples are normally
>> 16-bit numbers over HCI.
>>
>> In the CSR firmware we have to recognise the situation (by looking
>> for SCO HCI headers) and we nudge the stream index by 1 if needed.
>> (Old versions of CSR firmware don't have this fix.)
>>
>> I recall seeing a report that someone had coded this trick in
>> a USB host driver, possibly in a commercial stack.
>>
>> Just a guess.
>>
>> Carl
>>
>> Simon Vogl wrote:
>>
>>> hi,
>>> can anyone help me with my sco link? in about 50% of cases, the=20
>>> audio data
>>> has an offset of one byte, resulting in terrible noise. I think I saw=
a
>>> flag in a packet header somewhere that indicates the number of bytes=20
>>> to skip
>>> until the audio data starts -- I looked through the bt specs several=20
>>> times now
>>> but can't find it again. Anyone has a clue for this?
>>> Simon
>>>
>>
>>
--=20
_______________________________________________________________________
Dr. Simon Vogl
Institut f=FCr Pervasive Computing, Johannes Kepler Universit=E4t Linz
Altenberger Stra=DFe 69, A-4040 Linz, Austria
Tel: +43 732 2468-8517, Fax: +43 732 2468-8426
mailto: [email protected], http://www.soft.uni-linz.ac.at/
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
This problem might be related to how we deal with SCO in the bluez driver.
Basically, we receive an URB with 10 usb frames it it, equivalent to 10ms.
3 usb frames make up a single SCO frame for the headset profile.
We just assume that the first usb frame we get is the beginning of a SCO
frame. We then just work on from there.
First frame is header, get length from that header, grab the rest of the
SCO frame based on header length.
I have not determined in which situations this assumption is wrong.
Here are some ideas, but I need to prove them right or wrong.
1) missed interrupt, so an urb gets lost.
2) air radio noise causing some of the HCI SCO data to be lost. I have
been told that what happens on the air radio will not effect the
contents of HCI SCO packets, as the CSR chip should fill in lost samples
with predicted samples.
The problem is that there is no CRC check in HCI SCO frames, so
detecting whether some usb frame is the SCO header or not is difficult.
Any suggestions?
Cheers
James
Dr. Simon Vogl wrote:
> Hi all,
> it seems like this is the answer to sco quality problems - I see lots of
> packets arriving on
> a different channel, but patched to a size of 48:
>
> < HCI Command: Add SCO Connection(0x01|0x0007) plen 4
> > HCI Event: Command Status(0x0f) plen 4
> > HCI Event: Max Slots Change(0x1b) plen 3
> > ACL data: handle 0x0029 flags 0x02 dlen 12
> L2CAP(s): Connect req: psm 1 scid 0x0070
> < ACL data: handle 0x0029 flags 0x02 dlen 16
> L2CAP(s): Connect rsp: dcid 0x0041 scid 0x0070 result 0 status 0
> > HCI Event: Number of Completed Packets(0x13) plen 5
> > HCI Event: Connect Complete(0x03) plen 11
> < SCO data: handle 0x002c dlen 48
> > SCO data: handle 0x0035 dlen 48
> > SCO data: handle 0x002c dlen 48
> > SCO data: handle 0x002c dlen 48
> > SCO data: handle 0x002c dlen 48
> > ACL data: handle 0x0029 flags 0x02 dlen 12
> L2CAP(s): Config req: dcid 0x0041 flags 0x0000 clen 0
> < ACL data: handle 0x0029 flags 0x02 dlen 14
> L2CAP(s): Config rsp: scid 0x0070 flags 0x0000 result 0 clen 0
> < ACL data: handle 0x0029 flags 0x02 dlen 12
> L2CAP(s): Config req: dcid 0x0070 flags 0x0000 clen 0
> < SCO data: handle 0x002c dlen 48
> < SCO data: handle 0x002c dlen 48
>
>
> > HCI Event: Mode Change(0x14) plen 6
> > HCI Event: Mode Change(0x14) plen 6
> > HCI Event: Connect Request(0x04) plen 10
> < HCI Command: Accept Connection Request(0x01|0x0009) plen 7
> > HCI Event: Command Status(0x0f) plen 4
> > HCI Event: Connect Complete(0x03) plen 11
> < HCI Command: Change Connection Packet Type(0x01|0x000f) plen 4
> < SCO data: handle 0x002c dlen 48
> > HCI Event: Max Slots Change(0x1b) plen 3
> > HCI Event: Command Status(0x0f) plen 4
> > SCO data: handle 0x002e dlen 48
> > SCO data: handle 0x002c dlen 48
> > SCO data: handle 0x002c dlen 48
> < SCO data: handle 0x002c dlen 48
> < SCO data: handle 0x002c dlen 48
> > SCO data: handle 0x002c dlen 48
>
> It seems to me like the alternate handle id is created by a shift and or
> operation (id | (id>>1))...
> Can anyone knowing the usb driver better than me comment on this?
> thx
> Simon
>
>
> ------------------------------------------------------------------------
>
> Subject:
> Re: [Bluez-devel] sco links
> From:
> Carl Orsborn <[email protected]>
> Date:
> Wed, 03 Mar 2004 16:10:14 +0000
> To:
> Simon Vogl <[email protected]>
>
> To:
> Simon Vogl <[email protected]>
>
> Return-Path:
> <[email protected]>
> Received:
> from mail1.edvz.uni-linz.ac.at (mail1.edvz.uni-linz.ac.at [140.78.3.68])
> by zeus.soft.uni-linz.ac.at (8.11.7p1+Sun/8.11.1) with ESMTP id
> i23G8qj05391 for <[email protected]>; Wed, 3 Mar 2004 17:08:52
> +0100 (MET)
> Received:
> from mailsweeperjp.CSR.COM ([202.214.225.228]) by
> mail1.edvz.uni-linz.ac.at (8.12.10/8.12.9) with ESMTP id i23G8kRR043780
> for <[email protected]>; Wed, 3 Mar 2004 17:08:48 +0100 (CET)
> (envelope-from [email protected])
> Received:
> from exchangejp.csr.com (unverified) by mailsweeperjp.CSR.COM (Content
> Technologies SMTPRS 4.3.1) with ESMTP id
> <[email protected]> for
> <[email protected]>; Thu, 4 Mar 2004 01:10:55 +0900
> Received:
> from EXCHANGE02.csr.com ([192.168.137.45]) by exchangejp.csr.com with
> Microsoft SMTPSVC (5.0.2195.6713); Wed, 3 Mar 2004 16:10:22 +0000
> Received:
> from csr.com ([192.168.143.41]) by EXCHANGE02.csr.com with Microsoft
> SMTPSVC (5.0.2195.5329); Wed, 3 Mar 2004 16:10:14 +0000
> Message-ID:
> <[email protected]>
> User-Agent:
> Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
> Netscape/7.1 (ax)
> X-Accept-Language:
> en-us, en
> MIME-Version:
> 1.0
> References:
> <[email protected]>
> In-Reply-To:
> <[email protected]>
> Content-Type:
> text/plain; charset=us-ascii; format=flowed
> Content-Transfer-Encoding:
> 7bit
> X-OriginalArrivalTime:
> 03 Mar 2004 16:10:14.0469 (UTC) FILETIME=[03158750:01C4013A]
>
>
> Hi, Simon.
>
> Not my normal domain, but the normal cause of misaligning by
> 1 byte is that USB uses an isochronous (i.e., unreliable) channel
> for SCO, and one can send an odd number of bytes in a USB packet,
> so losing a packet leads to the offset. Audio samples are normally
> 16-bit numbers over HCI.
>
> In the CSR firmware we have to recognise the situation (by looking
> for SCO HCI headers) and we nudge the stream index by 1 if needed.
> (Old versions of CSR firmware don't have this fix.)
>
> I recall seeing a report that someone had coded this trick in
> a USB host driver, possibly in a commercial stack.
>
> Just a guess.
>
> Carl
>
> Simon Vogl wrote:
>
>> hi,
>> can anyone help me with my sco link? in about 50% of cases, the audio
>> data
>> has an offset of one byte, resulting in terrible noise. I think I saw a
>> flag in a packet header somewhere that indicates the number of bytes
>> to skip
>> until the audio data starts -- I looked through the bt specs several
>> times now
>> but can't find it again. Anyone has a clue for this?
>> Simon
>>
>
>
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel