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: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20050717145709.GI3613@stusta.de>
[not found] ` <1121615883.22662.38.camel@pegasus>
[not found] ` <20050717225345.GI3753@stusta.de>
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox