From: Marcel Holtmann <marcel@holtmann.org>
To: bluez-devel@lists.sourceforge.net
Subject: Re: [Bluez-devel] usb/sco problems
Date: Mon, 18 Jul 2005 11:06:02 +0200 [thread overview]
Message-ID: <1121677562.22662.63.camel@pegasus> (raw)
In-Reply-To: <Pine.LNX.4.53.0507180927480.6913@antilope>
Hi Victor,
> I have a small app which routes back sco data received from a
> headset, so basically you supposed to hear yourself back in the headset.
> It works fine with the voice setting 0x0060, but when I switch to u-law
> 0x014c sound is starting to break out, if I run the program on arm using
> uart it works fine for both of the settings.
>
> Using hcidump shows a regular pattern of sco receives/sends (normally like
> 3 packets in, 3 packets out, which is probably the result of usb buffering
> for incoming packets), but if I look at the output of an air-sniffer, I
> see that the data sent back to the headset has very
> irregular time pattern (a lot of transmissions are missing), while the
> time pattern of incoming data from the headset is ok.
> So it looks like something goes wrong after the sco data is supplied to
> the hci_usb. I have this problems with 2 dongles I have (BC4 and
> Broadcom built-in in my laptop), so does not look as a dongle problem. Any
> idea what might be wrong?
>
> Well, I also have a app which does copying data received from a phone
> sco to a headset sco and back (2 sco channels open and app functions as a
> middle agent). This app is also working for arm via UART, but not on my
> laptop (and home pc) via usb. The question does any1 has a successful
> example of having 2 sco channel open (to different devices) at the same
> time?
for USB you need to set the correct alternate setting for the SCO ISOC
endpoint. This should be done automaticly, but at the moment this is a
static module parameter called "isoc". Look at the specification on how
to calculate its value depending on the number of SCO connections and if
they are 8-bit or 16-bit. The default value is 2, which means one SCO
connection with 16-bit (aka voice setting 0x0060).
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
prev parent reply other threads:[~2005-07-18 9:06 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-17 14:57 [2.6 patch] net/bluetooth/: cleanups Adrian Bunk
2005-07-17 15:58 ` Marcel Holtmann
2005-07-17 22:53 ` Adrian Bunk
2005-07-18 8:55 ` [Bluez-devel] usb/sco problems Victor Shcherbatyuk
2005-07-18 9:06 ` Marcel Holtmann [this message]
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=1121677562.22662.63.camel@pegasus \
--to=marcel@holtmann.org \
--cc=bluez-devel@lists.sourceforge.net \
/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.