|
Home
/ FAQ
/ News Classifieds / Events |
Audio Asylum Thread Printer |
Get a view of an entire thread on one page |
86.121.193.18
In Reply to: RE: Guys remember what the cable does and why they make a difference posted by Gordon Rankin on February 18, 2008 at 08:37:08
One question.
I seem to remember reading that all USB packets, including the synchronous ones, have a header before the payload. Also, even if the bandwidth is specifically reserved for them by the host, they are still multiplexed with other packets if other devices are attached (say a keyboard).
But even if the audio device is the only one on the bus, how does the presence of the headers and of the temporal gaps between consecutive packets affect the audio quality? Does the DAC stream the data in real time as it arrives? No buffering whatsoever (not even 100 bits)? This would require extraordinary precission from the host device since it would have to put the packets on the wire at exactly the right time. Am I missing something?
Adal,
All devices on the USB link are sent packets. Each device specifies what is called MaxPacketSize for each endpoint.
In audio using ISO packeting the amount of data sent is specified by the SOF packet. You can specify this from I think 1ms to 32ms. But in audio we do as most do and set this to the maximum which is 1ms.
For 16 bits you need 4 bytes per sample (stereo) and 24 bits you need 6 bytes.
If we are doing 44.1/16 at 1ms increments we need 176.4 bytes per SOF packet. Since this cannot be done all OS's send 176 bytes 9 times and then 180 bytes ounce for a total of 1764 bytes over 10ms.
If we run 24/96 then we need 6*96= 576 bytes per 1ms SOF.
The PCM27xx series controllers have fixed buffer sizes of 2x48*4=384.
With the TAS1020/TUSB3200 you can specify the buffer size to what ever you want and control the DMA actually everything. So you can make the buffer allot larger and assure the lack of pops and clicks if there are errors in the bus.
The USB controllers only look at what their USB_ID is. They disregard all other communication seen on the link. With many computers and hubs the device will only see what it is suppose too.
Thanks
Gordon
J. Gordon Rankin
You got it. There is very little buffering in the typical USB interface. Gordons has a bit more than typical because he does a hand-shake and presumably gets it in bursts.
The PLL is locked on all the bits on the USB wire or only on the payload information? If only on the payload, it is stopped in the interval between consecutive packets?
I believe he still uses isochronous, only with async endpoint to adjust source rate, so PLL still needed to lock on bus. Plenty of ways for jitter from the PLL clocks to get to the audio clock circuits, even when the sample clock is derived from a local oscillator. No huge surprise there. Still looks like a nice, simple design though.