|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
68.126.185.12
Is it theoretically possible? What parts of the computer affect USB performance, and jitter, if any?
Follow Ups:
If the DAC decides to play this data at the rate it receives it from the USB bus, the computer can have an effect on the timing of music playback, since it controls when each piece of data is sent over the USB bus.If the DAC uses a buffer for the incoming data, then plays from its buffer using its own time signal, it makes no difference what timing is used by the computer to send the data (assuming it is sending it fast enough for playback, and slow enough not to overfill the buffer, which is something the USB device should be able to control).
Here's an analogy...it's like giving pieces of paper, each with one musical note on it, to a guitar player. If the guitar player plays each note when he receives the paper, then there will be jitter if the notes are not received at exactly the right time. If he saves a few and then begins playing them such that there will always be a buffer of notes ahead of him, it doesn't really matter how irregularly they were received.
??????????
That's right. If the DAC decides to playback the data at the rate it is received, then the computer can be responsible for jitter.Otherwise, the timing of the data sent by the computer makes no difference.
As mentioned, there are no USB devices that I know of that buffer the incoming data and re-clock it. So they are allowing the computer to be responsible for timing, which can result in jitter.
Unfortunately your analogy is an unfulfilled dream in the audio USB world.
Well I didn't say anyone had actually done it, did I? Yeah, as I understand it, everyone is using the isochronous mode...not sure why, maybe because nobody has made a chip that supports asynchronous mode that DAC makers can easily drop into their DAC units.
A few words on USB audio formats:
all USB audio modes are isochronous, this means that the bandwidth for the audio data is reserved on the bus so resource allocation doesn't have to be renegotiated for every packet of data sent. Synchronous, adaptive and asynchronous are all isochronous modes, the host sends packets out at a regular rate (thats what isochronous means, constant time). For the first two the receiving end has to match the host's data rate, for asynchronous the device can tell the host to slow down or speed up to match the rate its using the data.In none of these cases does it work like an ethernet with handshaking on each packet where the receiver requests a packet when it needs one. When the pipe is setup the host and device negotiate a speed and the host starts spewing out packts, its up to the device to keep up. In asynchronous the device can tell the host to change the data rate on the fly, thats the only difference.
Note that there is no error correction or retry on bad data. There is a simple error detection mechanism sent, but no means to retry if there is an error, you can flash a light on the front pannel but thats about it. Someone calculated that for a system that is within the USB specs an error should occur an average of once every 4 months or so for a system running 24 hours a day. The spec writers did not think this was important enough to spend the extra bandwidth and messiness on error recovery methods for audio.
But you don't seem to understand the interaction between electronics and hardware mechanics and control systems - mechatronics can cure some hardware issues, not everthing according to a theoretical model.
If the data is buffered on the receiving end, the rate at which the data is sent from the computer (or whatever source) is not important.Now, I realize that the USB DAC that is doing this buffering of incoming data (if such a DAC were to exist) could introduce jitter on its own. But that would have nothing whatsoever to do with the computer that sent the data in the first place, the CD it what ripped from, the CD-ROM drive that was used to rip the drive, the hard drive the data was stored on, the brand of memory in the computer, the length of the USB cable, and so on. Removing all of those elements from the equation is the reason such a DAC is desirable in the first place. Unfortunately, such a DAC, and the computer driver software to support it, does not currently exist.
No one else has ponied up the dough to make a USB chipset that works better. Not even the larger monied companies like Apogee etc.The reason Pro audio companies don't put USB in their professional products (they do put it in some of their prosumer/consumer products) is that it doesn't meet quality standards of true pro gear especially jitter specs.
Just not a very profitable venture in a niche market, and way too many gotcha's.
You are correct, software is the big issue not hardware. A couple of chips support asynchronous mode in hardware, but they all require rewriting firmware to do so. I tried this with the 1020 and its incredibly difficult and very expensive (the programs to work with the code are not cheap). Then on top of that you need to write OS drivers for every OS you want to support, this is easy on Linux but not so on Windows! I used to write Windows drivers but thats something I don't ever want to have to do again!! I don't have any experience with Mac drivers.Large companies like creative or m-audio have the resources to do this, but don't operate in the markets that want it so they don't see any reason to spent the resources and the companies that DO operate in the right market don't have the resources, so its probably not going to happen any time soon.
I tried and gave up. I know of one other person that tried and has not been successful either.
Another option that is actually easier to implement is to scrap the USB audio spec and scrap the "it has to look like a sound card" requirement and write your own program that just sends files using bulk transfer modes, grab the data from the interface chip and clock it under control of a good local clock to a DAC. You in essence write your own high level audio transfer protocol using low level bulk transfer that already exists in the OS drivers and interface chips. Of course you also have to write the application program (or at least something like a foobar plugin) this would be far easier than implementing asynchronous isochronous mode.
Microsoft has implemented a clss driver for devices following the USB audio spec. At most the H/W manufacturer of such a device has to write a mini-port driver. Often the device just works with the generic Microsoft support.If your device uses bulk transfer, you have to write a full audio driver. That's much more work to write and test than a mini-port driver. However, when you write such a driver, the device looks like a normal audio device to Windows. (PCI soundcards require full drivers too.) Any application can write to it.
I wrote Windows drivers and kernel mods for quite a while. Such a project for a 2 channel device with NO H/W or Driver SUPPORT for gaming feaures would not be a large or risky project but you have to have a good programmer, good H/W developers and a commitment to debugging and testing. Drivers are often written while the H/W is being developed and/or debugged so that adds time and risk.In this case, the right approach is to define the interaction between driver and bulk transfer device first so that the driver can be mostly generic. Such a driver could open the door for implementing USB audio the right way.
How about letting the existing drivers send the data using the regular isochronous method, and buffering it locally on the device anyway (for later playback at locally-clocked speeds)?Granted, this just moves the software support into the firmware on the device (which is probably more of a pain to write than drivers), but at least you'd only need to get it right once (then the various platforms--Windows, Mac, Linux--could just continue using existing sound drivers that believe they are controlling the playback speed using the isochronous USB mode).
In a word "yes", you want more detail?First off USB DACs vary wildly in their implemetations, what effects one strongly may have little effect on others.
A little background that will help understand the following. MOST USB implementations use whats called adaptive mode which has a PLL that tracks the data rate coming over the bus, this means that the jitter of the recovered clock CAN be affected by whats happening on the interface. In adaptive mode the PLL is not directly connected to the datastream (as it is in S/PDIF) so exactly how its affected by the interface is not simple or straight forward. Rules of thumb and theories about S/PDIF jitter do not directly apply here because of the different implementation. There has been very little research into what effects on the bus cause what change in jitter for adaptive mode so its very tough to make predictions such as "this going on in the computer will cause this type of jitter in the recovered clock", we don't know right now. And to make it worse there are several VERY different implementations of adaptive mode which are going to respond differently to external stimulus. For example the TAS1020 and the PCM2706 handle adaptive mode compeltely differently and thus most likely have significantly different jitter responses. Then there are a few DACs that take the clock from the USB chip and run it through a much better PLL such as a VCXO based PLL, these will radically cut down on any jitter effects caused by the interface.
I can think of four main areas that can cause issues:
bus powered PS, many cheap USB DACs draw their power from the USB bus itself, this is a disaster waiting to happen for sonics. ANYTHING that goes on in the computer can wind up affecting this. An external supply for the DAC greatly reduces this.
Actual jitter on the USB bus. This can come from different places, power supply noise on the USB transmitter in the computer will cause jitter on the data, since this is inside the compuetr (one of the electrically noisiest environments on the planet) this can be pretty significant. Jitter in the clock signal fed to the USB transmitter (which is heavily effected by PS noise). An interesting source is the spread spectrum clocks used in most computers today. The frequencies of the oscillators used in most computers is deliberately varied in an attempt to "spread the noise" out over a larger spectrum and make it easier to pass FCC testing. This deliberate clock jitter will also effect the timing on the USB bus, even if its fed from its own stable clock source the jittery input data will still cause jitter on the output.
Noise on the BUS signals. Even if the signal launched from the computer has precise timing on its edges, any noise picked up by the bus wires will cause timing errors when the receiver tries to detect that edge. This can be effected by different amount of shielding on the cable, the environment the cable passes through, but most especially by those infamous power wires in the BUS. Even if your DAC is not powered by the BUS, those wires are still there in the USB cable running right next to the signal wires, no matter how hard you try there will still be some noise from the power wires picked up by the signal wires.
Not directly related to the computer per se, but the USB cable itself can have a significant effect on the signal. The length of the cable can make a significant difference on the noise and jitter of the signal at the receiving end. Even cable construction and materials can effect the jitter at the device end.
Figuring out what effects USB DACs is very much in its infancy right now, I don't think anybody can tell you doing such and such on the computer is going change the sound thusly for USB DACs in general. For a specific model with a specific computer with a specific environment you might be able to do some experiments and come up with a few correlations, but its going to be really tough to come up with genaralizations.
So in a nutshell: yep what goes on in the computer CAN effect jitter in the DAC, what causes what? who knows.
John S.
I have been saying this without having gone thru what you have done.I agree and THAT is why I query assertions that USB audio is far better. It's just different, and the differences are because of the lack of clarity in what is happening.
One big weakness for me is the general lack of highrez (24/96/192k) support.
Goto diyhifi.org and judge for yourself. USB is a cheap output device and is refreshed every 1mS. Why this should have no jitter problem is beyond me, especially since ripping to HD still requires reading from a cheap transport. Software does not cure hardware problems - an assumption that is made repeatedly here.
fmak - you are one of the very few USB non-believers. Why dont you just get a decent USB converter and try it out, or better yet get a demo to try out? It may change your thinking. At least then you would have some experience to share and not just supposition.
I have. And the fixed boxes are better!There are plenty of usb skeptics; they don't bother this this board because of all these assertions without any firm basis.
Your posts are the few that tries to relate to some of the facts. Most don't seem to understand computer engineering or real life programming!
"...ripping to HD still requires reading from a cheap transport."This statement makes it clear that you do not understand the basics of losslessly extracting the data from a CD. Your assumption that somehow a more expensive transport can read this data better is fundamentally flawed.
Before you continue on the computer audio path I suggest you come to grips with this basic statement:
A $10 CD-ROM drive can read the data from one of your music CDs as well as a $50,000 CD-ROM drive.
And your comment makes clear the blins faith that software can overcome hardware interfacial and other problems. If what you say is true, then all CDRoms extractions should sound the same. They don't!
So, you think computers often produce errors when reading CDs?You do realize that installing computer software (where one wrong bit can cause a crash) would be a bit difficult if this were true. That would really be a tough one for Microsoft, for example!
The simple fact is that the data on a CD contains checksums that allow the computer to GUARANTEE that the data has been read is accurate. With audio CDs paranoia about data integrity has been take even further with systems such as AccurateRip.
Software cannot overcome hardware problems. But it can verify that the data it got from the hardware is wrong, and re-try it as many times as is necessary (or say that the errors could not be overcome). This is why some rips take upwards of an hour with programs such as EAC. And this is also why a real-time $50,000 CD transport can NEVER, EVER (REALLY I MEAN NEVER) be as accurate as a computer with a $10 CD-ROM drive ripping the data using a program like EAC.
And I have. My usb set up is far more enjoyable than any of the previous 2 box, 1 box or even 5 box solutions (yes I'm afraid to say I had 5 boxes in my digital chain).Is it the computer? The dac? The usb interface? I have no idea and I don't care..for the first time in forever I'm ebjoying digital music.
If I listened to a scope jockey I'd still be lstening to my SAE monster amp with vanishingly low THD!
I was on the verge of giving up on enjoying digital music until I got a USB dac - now I'll probably never upgrade again - I know in the year since I got mine, the thought of upgrading has seemed laughable. I'm glad I don't listen to narrowly defined measurements that define but a single mechanical contributor to the overall sound produced - the easiest way to get to the bottom line is to listen. I'm sure the best turntables have wow and flutter, the best solid state amps still have distortion, and the best tube amps have more distortion. As with all technologies, there are good implementations and bad ones. What's a scope jockey (love that term) to do? The old fashioned way still works best, sit down and listen - that will get you to the bottom line pronto. Not that there's anything wrong with deep, intellectual, scientific debate far from it (although seeing the same debates week after week can become tiring) - but drawing conclusions without listening just ain't gonna work.
You just don't get it no matter how many times it is explained to you.Why not go somewhere else-please!
And you do? I am an engineer well versed with computer applications, mechanical engineering and acoustics. Are you qualified?
You still don't know what you are talking about. I hope you can earn a living.Listen to the equipment and then give us an opinion.
Oh, my foot!
I'll add one more thing to think about. You never contribute anything useful to this forum except negativity. If you dislike what we are doing here, why continue to show up? Are you that insecure that you need to feel superior to the other people trying to enjoy their hobby and music?Oh yes, you have an engineering degree. Perhaps it would be best if we just close this group down as most of us don't meet your intellectual standards.
According to the Wavelength Audio website, a USB based system should have less of a jitter problem than a normal cd player.Here is the info from the site:
Basically the DAC has a single digital USB input. USB unlike SPDIF is bidirectional and therefore has error correction and buffering on both sides. This happens automatically so the data on the disk is identical to what is going out all the time. Also since this interface is asynchronous the clocking problems associated with SPDIF go away. What happens is... On power up of the computer the 2 devices negotiate services. In this case the Cosecant tells the computer it can do 16 bit audio at 32K, 44.1K and 48K. Since the USB receiver only has to handle these 3 frequencies, the clocking to the separate DAC IC has almost no jitter. SPDIF actually has to be synched to the exact frequency of the transport (i.e. if the transport is working at say 44.0896K instead of 44.1K the dac has to sync to that frequency). Therefore the jitter problems of SPDIF almost go away using USB. So using USB we have a zero error protocol to link the computer to the DAC and very low jitter what else
Yes, jitter can be caused by the power in the USB cable if this is used for the USB convesion.Also, computer noise can affect the performance of the PLL in the converter. Depends on the design of the PLL and the loop filter.
If the computer power is not used and the PLL is a good one and the loop filter is done well, then the computer will have little to no effect.
This post is made possible by the generous support of people like you and our sponsors: