[Bluez-users] SCO syncronization taking down USB dongle

[Bluez-users] SCO syncronization taking down USB dongle

[Gareth Bradley]

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

Hello. I am currently writing code for voice connections using a Motorla
HS850 headset and the BlueZ stack on a Intrinsyc Cerf 255PXA board (a small
form mobile PC). I can currently make successful SCO connections to the
headset, but they sometimes crash, and take the whole USB dongle with it.
(Running 'hciconfig hci0 up' fixes it).

Here is the crash printout:
usb.c: USB disconnect on device 2
Receive failed: Broken pipe
hub.c: USB new device connect on bus1/2, assigned device number 3

I have a stream of incoming voice (from a Windows PDA) which is buffered. I
read from the SCO connection stream (and consistently get 48 byte packets),
and write in an amount from the receive buffer into the headset. This coice
connection works fine.

I've tried using FD_ZERO, FD_SET and FD_ISSET before all read and writes,
but still to no avail. I am able to get it to crash within a minute if I
deliberately write data chunks slightly out with the amount read from the
device (read 48, then write 47, or 46, or 49...).

I notice that flow (and error) control appear on the Todo list, but is there
some way to guard against the whole dongle being taken down?

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

Re: [Bluez-users] SCO syncronization taking down USB dongle

[Marcel Holtmann]

Hi Gareth,

> Hello. I am currently writing code for voice connections using a
> Motorla HS850 headset and the BlueZ stack on a Intrinsyc Cerf 255PXA
> board (a small form mobile PC). I can currently make successful SCO
> connections to the headset, but they sometimes crash, and take the
> whole USB dongle with it. (Running 'hciconfig hci0 up' fixes it).
> 
> Here is the crash printout:
> usb.c: USB disconnect on device 2
> Receive failed: Broken pipe
> hub.c: USB new device connect on bus1/2, assigned device number 3

the dongle gets disconnected from the USB bus. What kind of dongle is
this? Maybe you need to get yourself a better one, because a disconnect
from the USB is nothing we can really work around.

> I notice that flow (and error) control appear on the Todo list, but is
> there some way to guard against the whole dongle being taken down?

It only protects the host stack and not the dongle. The flow control
towards the HCI of the dongle is always used.

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] SCO syncronization taking down USB dongle

[Gareth Bradley]

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

Thank you for your reply Marcel.

the dongle gets disconnected from the USB bus. What kind of dongle is
> this? Maybe you need to get yourself a better one, because a disconnect
> from the USB is nothing we can really work around.


I am unsure of the dongle's actual manufacturer, as it's just a DSE (our
Radio Shack equivilant) rebrand. I have since tried it with a Stollman
dongle, and am able to get the same result (crash).

I am able to get the USB crash with a test program, pasted below. The 'rlen
-= 1;' line is added to crash it. I am currently unable to test if this will
also crash on other platforms, such as on a PC or PDA. Should this be able
to take down the dongle?

The actual project runs with the number of bytes written to the headset
being regulated by the number read from the headset (though the sound is
from an external source, not straight back into the headset, like in the
example). Is this the correct way to regulate SCO data?

        while(1){
            FD_ZERO(&rfds);
            FD_SET(serial_fd, &rfds);
            FD_SET(sd, &rfds);

            timeout.tv_sec = 0;
            timeout.tv_usec = 10000;

            if((sel = select(maxfd + 1, &rfds, NULL, NULL, &timeout)) > 0) {
                if(FD_ISSET(serial_fd, &rfds)){
                    memset(soundbuf, 0, sizeof(soundbuf));
                    rlen = read(serial_fd, soundbuf, sizeof(soundbuf));
                    if(rlen > 0){
                        wlen = write(serial_fd, "\r\nOK\r\n", 4);
                    }
                }

                if (FD_ISSET(sd, &rfds)) {
                    memset(soundbuf, 0, sizeof(soundbuf));
                    rlen = read(sd, soundbuf, sizeof(soundbuf));

                    rlen -= 1; // This line is able to enduce the crash
                    wlen = 0;
                    p = soundbuf;
                    while(rlen > sco_mtu){
                        wlen += write(sd, p, sco_mtu);
                        rlen -= sco_mtu;
                        p += sco_mtu;
                     }
                wlen += write(sd, p, rlen);

                }
            }
        }

> I notice that flow (and error) control appear on the Todo list, but is
> > there some way to guard against the whole dongle being taken down?
>
> It only protects the host stack and not the dongle. The flow control
> towards the HCI of the dongle is always used.


Thanks again for your input.

gjb.

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