Re: [Bluez-devel] snd-bt-sco development teamup...

[Carl Orsborn <cjo@csr.com>]

I know nothing of snd-bt-sco or alsa, so some of my comments
below will doubtless expose my ignorance, but I know something
of how CSR devices handle SCO traffic (or, at least, how
they're *supposed* to handle SCO traffic).

I can't find anything in this thread that reveals whether you're
trying to send SCO traffic over USB or UART.  The data handling
for the two cases have subtle differences.

Over USB, there's an isochronous connection - the bus provides
capacity for 8 ksamples/second in each direction.  If a CSR
device somehow fails to receive SCO traffic from air it fills
the embarrassing gap in the USB to-host flow with dummy
data.  Thus, the host continues to receive 8 ksamples/second.

Over UART, the same compensation mechanism applies - the CSR
device makes up data for any from-air gaps.  This allows the
host to match its tx sample rate to the connection's rx
sample rate, and so removes the need for the host to maintain
an accurate 8 kHz clock.

The Bluetooth device has a pair of *small* ring buffers for each
SCO connection - one for each direction.  They are small to
keep audio latency low; manufacturers of audio devices insist
on low latency.  Keeping latency low for audio traffic flowing
over HCI (USB or UART) is hard.  Most of our customers route
SCO traffic over the Bluetooth device's separate audio interface
(PCM port), bypassing the HCI transport.

As I noted above, the USB/SCO path is isochronous.  This means
packets can be lost silently.  If the path is carrying 16-bit
samples (the normal case), and if a USB packet can hold an
odd number of bytes, this can lead to a 1 byte offset in
the audio stream.  This sounds ghastly.  We fixed this in the
Bluetooth device's firmware ages ago - spotting the loss of
sync by looking for SCO packet headers.  However, many host
USB device drivers can still suffer this problem.

Much of this is discussed in CSR's "HCI Implementation" document,
bcore-me-026, though this is normally only made available to
CSR's (direct) customers.

Regards,

Carl

Jonathan Paisley wrote:

> On Tue, 10 Aug 2004 1:53pm +0100, James Courtier-Dutton wrote:
> 
>> 4) SCO then waits until SCO has finished (2), and only then takes X 
>> samples from the ring buffer, creates a SCO packet, and sends it to 
>> the hardware...then repeats.
>> 5) Add a SCO api call, so that the higher level module can find out 
>> how much of the SCO packet has been output, and thus return accurate 
>> hardware pointer values.
> 
> 
> Is this additional api call necessary? Suppose packets are about 24 
> bytes (that's what I remember them to be). So the suggestion is to have 
> two of these in flight at a time. Given 8000 Hz sampling rate (equating 
> to 8000 or 16000 bytes per second if using 8bit or 16bit PCM, 
> respectively), those 24 bytes correspond to between 1.5 and 3ms.
> 
> In summary: isn't it sufficient to just keep track of what packets have 
> been sent? This gives 3ms accuracy.
> 
> Thanks.




**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited. 
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************



-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel