|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
69.204.34.167
In Reply to: RE: " USB REGEN " by UpTone Audio ... any opinions ? posted by Thorsten on May 23, 2015 at 08:18:56
Hi T,
'Good luck. Ethernet is as bad, or worse. It has problems a little different from USB,the principle is the same.'
Do you mean the quality of the audio is bad or do you refer to dropouts?
Thanks,
Serge
Follow Ups:
Hi,
The Issue that has been made prominent in the context of the Gizmo being discussed is what I would call "frame noise". In any serial transmission system Data is packed into some form frame with distinct "boundary markers".
In USB 2 the main frame rate is 1mS (1kHz) which for High Speed is subdivided into 8 microframes each 125uS long with space (including frame markers and other overheads) for up to 60kb worth of data.
Usually not the whole 60k is used and often it is shared between multiple devices - each of which may have a "packet" of data. The theoretical limit is 13 bulk packets per microframe. This is not achievable with current host controllers, which can receive 10 bulk
packets/microframe or send 8 bulk packets/microframe.
So we have frame noise at 1kHz and 8kHz and Packet noise at theoretically 13 * 8kHz (104kHz) but in practice 64kHz (8 Microframes with 8 bulk packets) or less if using isochronous streaming (most USB audio).
Now the processing in frames and microframes may cause a cyclic load on the supply and if much error correction etc. is needed the load may increase. Such cyclic load may modulate the power-supply and cause problems if for example it is allowed to modulate audio clocks.
Perhaps surprisingly (or not) the mechanism is almost entirely analogous (or parallel) to the one in CD Transports where despite 100% error free reading of data sonic differences are observed between clean and dirty CD's, with the application of CD-mats etc. et al.
Incidentally, the varying PSU load (and the resultant noise) due to different frame fill factor with data packets and different data in packets is what I would class as the second kind of "packet noise" and it is semi-random but data related in nature, so in some ways more pernicious and harder to treat (again, similar issues apply for example to SPDIF) than the 1kHz and 8kHz frame noise which competent power supply design should control well (the emphasis being competent and should).
Is Ethernet (or WiFi, or MADI or anything else) free from framed/packetised processing? Nope, like any serial system this is how it works so it faces the same issues, just at different frequencies.
Most "coockie cutter" USB (and ethernet and other) Circuitry treats the clock as bad as old style low end CD-Players (powersupplies shared with transport, physical decoding layer and microprocessors, so noisy and modulated by many factors).
Frame noise, packet noise and other noise sources on the USB Power line can impact the clock and thus the audio even if the data is 100% correct. Pretty much any of the "turnkey" USB Solutions is very bad in this respect. I know not one commercial off the shelf module or Chip Manufacturers reference design that is better than "absolutely terrible" (I do not know all of them, only most) in this respect.
Any self respecting high end audio designer of course would look at such designs and fix the inherent problems in the reference designs and not use third part modules of questionable design. Looking inside much commercial gear makes me ask if there is a lack of self respect among high end audio designers or a lack of high end audio designers who understand digital and USB sufficiently well.
What is the bottom line?
As long as the system is correctly designed to avoid cross-contamination of clocks (and grounds/power supplies etc.) and as long as the cable length is kept reasonable within the design limits of the systems and as long as appropriate quality and electrical specification cables are used, non of these problems (degraded Signal Integrity, Frame/Packet noise induced jitter etc.) should be observable.
If these problems are observable they indicate a fundamental design flaw. Which is not to say that they are not observable on much of the gear/cables out there.
Ciao T
At 20 bits, you are on the verge of dynamic range covering fly-farts-at-20-feet to untolerable pain. Really, what more could we need?
interesting explanation of usb
why call it a gizmo ? I believe it's got a name ? Is it any different to your gizmos ? Best to stick to facts.
http://mqnplayer.blogspot.co.uk/
Hi,
> why call it a gizmo ?
I could have used Widget instead. The aim was to not directly name a specific product, but rather cater to the fundamentals of the technology involved.
I have no problems with anyone calling my stuff "Gizmo", as long as they append "ueberkool" in front (joke)... :P
> interesting explanation of usb
You can amuse yourself with the gory details at www.usb.org
Ciao T
At 20 bits, you are on the verge of dynamic range covering fly-farts-at-20-feet to untolerable pain. Really, what more could we need?
One difference between USB and Ethernet is that USB uses bit stuffing to frame the packets. This means that the time on media varies according to the data being set. When USB carries audio data, this means that the power supply load will vary according to the audio signal being transmitted, adding a unique mechanism for noise modulation.
A second difference between USB and Ethernet is the poor error detection capabilities of USB, with the use of a 16 bit CRC vs. Ethernet's 32 bit CRC. The situation is made worse with USB due to the use of bit stuffing. In the event of marginal transmitters, cables and receivers, there will be a radically higher chance of corrupted packets arriving. In some cases there can be systemic problems as well. Note that a single bit error will misframe subsequent audio signals and may produce loud error bursts. A single bit error over Ethernet will only corrupt a single PCM sample, which at worst will be heard as a click. If USB is used to carry DSD via the DoP kluge, then there is a further failure mode associated with missynchronization generated by a single bit error.
I have hated the USB technology since its very beginning, because of its use of bit-stuffing for packet framing, a terrible idea dating back to the the mid-1970's when logic circuits were horrendously expensive. There are real problems with this coding (based on IBM's SDLC technology) that make it inappropriate to be used in noisy environments where there might be questionable signal integrity. The use of boutique USB cables that do not meet specifications is completely absurd given this weak design.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
Post a Followup:
FAQ |
Post a Message! |
Forgot Password? |
|
||||||||||||||
|
This post is made possible by the generous support of people like you and our sponsors: