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


-------------------------------------------------------
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