[Bluez-devel] SCO USB isoc transfer

[Bluez-devel] SCO USB isoc transfer

[Tomasz Urbanowicz]

[-- Attachment #1: Type: text/plain, Size: 2271 bytes --]

Hi,
 I have a little question regarding sco packets transfer over usb.
To learn about bluetooth I've developed my own stack fragment that works
with usb devices.
Now I'm working on enabling SCO transfer which takes place over isochronous
endpoints in
the usb device. Now to the point. After establishing the SCO connection when
I read from
the device isoc endpoint I've noticed that the data that is returned
sometimes starts
with the SCO header and sometimes it doesn't.When it doesn't the first SCO
Header appears somewhere later in the data.
For example when I read some number of bytes from isoc endpoint my result
buffer might start like this :
 *)
2C 00 30 22 10 22 10 22 10 22 10 22 10 22 10 22 10
22 10 22 10 22 10 22 10 22 10 22 10 22 10 22 10 22
...
...
Here the 2C0030 is the correct SCO packet header, so the result buffer right
from the beginning starts with the SCO packet.
But it's not always like that. Somtimes the result buffer will start with
some garbage data, and the proper SCO header appears somewhere later in that
buffer. For example :
 **)
22 10 22 10 22 10 22 10 22 10 22 10 22 10 22 10 22
10 22 10 22 10 22 10 22 10 22 10 22 10 22 10 22 10
2C 00 30 22 10 22 10 22 10 22 10 22 10 22 10 22 10
 Here first 34 bytes are not preceeded with the SCO Header. A properly
structured packet starts at the 3rd line here with 2C 00 30.
 When I reviewed the BlueZ code for usb driver I found that __recv_frame()
function basicly assumes that the very first 3 bytes that the isochronous
endpoint will send to us will be a SCO Header. So it assumes that it is
always dealing with case *) Am I right ?
 So my question boils down to this. When I start reading from the usb isoc
endpoint how do I determine the begining of the SCO data ? Should I assume
that the data will start with the proper SCO packet ? Or should I be
prepared that there might be some garbage data at the beginning of the
buffer, which would require me to search for the first proper SCO packet
that starts the stream.
 I know this has nothing to do with BlueZ, but I couldn't think of any other
place to post my question so I hope someone (Max ? maybe Marcell ?) will
help me to understand that issue. I'll appreciate it a lot.
 thanks,
Tomasz

[-- Attachment #2: Type: text/html, Size: 2745 bytes --]

Re: [Bluez-devel] SCO USB isoc transfer

[Steven Singer]

Tomasz Urbanowicz wrote:
> Now I'm working on enabling SCO transfer which takes place over isochronous endpoints in
> the usb device. Now to the point. After establishing the SCO connection when I read from
> the device isoc endpoint I've noticed that the data that is returned sometimes starts
> with the SCO header and sometimes it doesn't.When it doesn't the first SCO
> Header appears somewhere later in the data.

This is a fundamental problem with SCO over USB.

One HCI SCO packet is broken into three USB packet. Only the first of
these packets has a header.

Unfortuantely, the USB isochronous stream is not reliable and packets
can get lost. This means that the header may not be where you expect
them.

For a single SCO link with 16 bit data, the Bluetooth spec recommends
that the data be packed into HCI packets containing 48 payload bytes
(24 samples). The three byte HCI header brings the total PDU size up to
51 bytes. This is then split into three 17 byte packets which are sent
on successive milliseconds.

The first packet contains the three byte header and 14 bytes of payload.
The last two contain 17 bytes of payload.

You will need generic resynchronisation code that detects that a header
was not received where it was expected and then reads individual USB
packets until it finds one that starts with a header.

If you wanted to be really robust, you'd look for a USB packet with a
header followed by two without as, in theory, the header sequence could
appear in the sample stream.

In practice, if you just take the next packet with a header then if you
did accidentally match in the packet stream, you'll probably find the
next header isn't where you expected (as it's unlikely that the three
bytes 48 bytes further along the data stream also match the header).
You can then try and resynchronise again and keep trying until you get
the right match (which should never take more than 3 attempts).

> But it's not always like that. Somtimes the result buffer will start with
> some garbage data, and the proper SCO header appears somewhere later in that
> buffer. For example :
>  **)
> 22 10 22 10 22 10 22 10 22 10 22 10 22 10 22 10 22
> 10 22 10 22 10 22 10 22 10 22 10 22 10 22 10 22 10
> 2C 00 30 22 10 22 10 22 10 22 10 22 10 22 10 22 10
>  Here first 34 bytes are not preceeded with the SCO Header. A properly
> structured packet starts at the 3rd line here with 2C 00 30.

34 bytes is 2 x 17 bytes which means you started reading from the second
packet of the three making up the full HCI packet.

	- Steven
-- 


This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] SCO USB isoc transfer

[Tomasz Urbanowicz]

[-- Attachment #1: Type: text/plain, Size: 4320 bytes --]

Thanks Steven for your prompt and complete reply.
 I've noticed that one SCO packet consists of three 17 bytes long USB
packets, and now I also understand that USB isoc packets might get lost and
resynchronization policy is required. I have two doubts left though.
 1) Does BlueZ employ a resynchronization scheme similar to the one you
mentioned ? From what I found out from reading BlueZ usb driver code it
seems that it assumes that SCO header is always there where it's supposed to
be.
The __recv_frame() function which is called for each usb isoc packet that
comes from the device, builds up the SCO packet. It looks like it doesn't
really care that the SCO header might not be there. Correct me if I'm wrong.
 2) Isn't it odd that in my driver it's only the very first SCO packet that
comes from the device that is incomplete, missing either 17(one usb packet)
or 34 (two usb packets) starting bytes ? Packets that follow in the stream
seem to be OK.
 thanks,
Tomasz


 On 10/21/05, Steven Singer <steven.singer@csr.com> wrote:
>
> Tomasz Urbanowicz wrote:
> > Now I'm working on enabling SCO transfer which takes place over
> isochronous endpoints in
> > the usb device. Now to the point. After establishing the SCO connection
> when I read from
> > the device isoc endpoint I've noticed that the data that is returned
> sometimes starts
> > with the SCO header and sometimes it doesn't.When it doesn't the first
> SCO
> > Header appears somewhere later in the data.
>
> This is a fundamental problem with SCO over USB.
>
> One HCI SCO packet is broken into three USB packet. Only the first of
> these packets has a header.
>
> Unfortuantely, the USB isochronous stream is not reliable and packets
> can get lost. This means that the header may not be where you expect
> them.
>
> For a single SCO link with 16 bit data, the Bluetooth spec recommends
> that the data be packed into HCI packets containing 48 payload bytes
> (24 samples). The three byte HCI header brings the total PDU size up to
> 51 bytes. This is then split into three 17 byte packets which are sent
> on successive milliseconds.
>
> The first packet contains the three byte header and 14 bytes of payload.
> The last two contain 17 bytes of payload.
>
> You will need generic resynchronisation code that detects that a header
> was not received where it was expected and then reads individual USB
> packets until it finds one that starts with a header.
>
> If you wanted to be really robust, you'd look for a USB packet with a
> header followed by two without as, in theory, the header sequence could
> appear in the sample stream.
>
> In practice, if you just take the next packet with a header then if you
> did accidentally match in the packet stream, you'll probably find the
> next header isn't where you expected (as it's unlikely that the three
> bytes 48 bytes further along the data stream also match the header).
> You can then try and resynchronise again and keep trying until you get
> the right match (which should never take more than 3 attempts).
>
> > But it's not always like that. Somtimes the result buffer will start
> with
> > some garbage data, and the proper SCO header appears somewhere later in
> that
> > buffer. For example :
> > **)
> > 22 10 22 10 22 10 22 10 22 10 22 10 22 10 22 10 22
> > 10 22 10 22 10 22 10 22 10 22 10 22 10 22 10 22 10
> > 2C 00 30 22 10 22 10 22 10 22 10 22 10 22 10 22 10
> > Here first 34 bytes are not preceeded with the SCO Header. A properly
> > structured packet starts at the 3rd line here with 2C 00 30.
>
> 34 bytes is 2 x 17 bytes which means you started reading from the second
> packet of the three making up the full HCI packet.
>
> - Steven
> --
>
>
> This message has been scanned for viruses by BlackSpider MailControl -
> www.blackspider.com <http://www.blackspider.com>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>

[-- Attachment #2: Type: text/html, Size: 5175 bytes --]