|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
24.6.177.51
In Reply to: RE: PC + Asynchronous USB DAC Question posted by needtubes on December 29, 2011 at 15:55:27
Asynchronous USB is not a guarantee that a DAC is immune to all outside influences. What it does is give the possibility of better immunity IF the implementation is done very well. As others have mentioned the quality of that implementation varies greatly from DAC to DAC. Some designers think that since they are async they don't have to work as hard on the design.
Even if the implementation is done very well there is STILL possibilities for outside world to influence what is happening in the DAC. I wrote a detailed post on this a while back (you can track it down if you want the details). Basically it comes down to what I call first order and second order effects. The first order are thing that add gross levels of jitter and noise such as PLLs, frequency sysnthesizers etc. These are the things that async mode is supposed to get rid of. But that is not all there is to it. The second order effects are caused by noise on the groundplane and powersupply system in the DAC. These are still significantly affected by the input signal. When a USB receiver receives a packet the decoders generates a lot of noise on the groundplane, this noise can increase jitter at the DAC chip. Thus the timing of the packet from the computer IS going to affect the jitter at the DAC chip. Thus all kinds of things related to the timing of the packets can affect the jitter at the DAC chip.
A few designers understand this and have taken steps to minimize this, but many DAC designers do not know about this and have not done anything to minimize its affects. To my knowledge nobody has yet come up with a DAC that is fully immune to these affects. Some DACs are very sensitive to it and others are much less sensitive, its going to be very design specific.
An interesting example is the HRT music streamerII, it IS asynchronous USB, but it is still very sensitive to what happens in the computer. On the SAME COMPUTER I can make simple changes to OS scheduling parameters and get a huge difference in the sound. At one end of the scale its dull, lifeless, no depth at all, at the other end of the scale it is wonderfully alive, dynamic, huge depth etc. And all this by just changing a few numbers, NO change in hardware at all.
There are other DACs that sound very good no matter what settings you use, but there is still a difference, its just that at its best its not all that much better than the worst. With everything out there you will be able to get improvements with tweaks to the computer, its just that with some the range is much greater than others.
Another aspect to this is that what optimizes a computer for best results for a USB DAC is not necessarily the best for an S/PDIF DAC or an internal soundcard. So a specific recipe such as from CICS may not be the most optimal for a USB DAC.
Everything I have come across shows that you get best results with a dedicated computer that you can tweak for audio purposes, you will have to make compromises if you want to support other activities.
John S.
Follow Ups:
John -
Thanks for a very interesting and well thought out post.
And, details of any specific tweaks that you found effective for the Music Streamer II would be of great interest !
PS Two new HRT products come out next week at CES...
You can track it down if you want the details . . .
See link for John's notes.
So a specific recipe such as from CICS may not be the most optimal for a USB DAC.
Except of course where cics's "recipe" consists of general (and, trust me, carefully evaluated) suggestions for getting the best out of USB DACs. See link, step 7.
http://www.cicsmemoryplayer.com/index.php?n=CMP.10Soundcard
cics' suggestions for USB DACs seem to clearly not be addressing asynchronous USB DACs - some are unnecessary for async, particularly the one he cites as the most effective tweak. I suspect that the list is from 3-4 years ago, before most asynchronous DACs came to market.
Speaking of which, is there a known status to a) the cmp2 project and b) cics' involvement, as there apparently has been no formal activity since over a year ago... but perhaps I missed something.
cics' suggestions for USB DACs seem to clearly not be addressing asynchronous USB DACsJust for the record, cics did not write that section, I did. (Many of the suggestions on the web site came from others; cics never claimed they were his.) His choice of output device was the digital section of the Juli@ PCI card; he was not, and presumably still isn't, a fan of USB for audio and so had little experience of it.
Some took the view that a cMP2 system has to use the Juli@ - this is not so. My notes were suggestions (no more) as to how the approach might be extended to low-end USB devices. Ironically, the notion of "tuning" the USB arose in the light of comments from Gordon Rankin who, as you know, was probably the first to develop an asynch USB protocol. (He was referring to USB ports on a Mac.)
some are unnecessary for async, particularly the one he cites as the most effective tweak.
It's been a while but I don't recall ranking any suggestion as "the most effective". Can you jog my memory? I don't see how any of the tips could harm an asynch setup though they may well, of course, be less pertinent in some systems. Which ones had you in mind?
is there a known status to a) the cmp2 project and b) cics' involvement
By choice, cics has not been involved in the project for the best part of two years. It continues IMHO to progress but never had any "formal" status except in the eyes of detractors.
It's always been a hobbyist project though, in my view at least, one that largely predated and typically leaves commercial rivals far behind for builders prepared to put in a bit of work.
Edits: 01/05/12
Ryelands wrote:
"By choice, cics has not been involved in the project for the best part of two years. It continues IMHO to progress but never had any "formal" status except in the eyes of detractors. "
Well, it has a very formal web site:
http://www.cicsmemoryplayer.com/index.php
which states:
"These free open source projects are briefly described below"
I don't consider "formal" to be negative, especially when there are significant number of people spending money and time creating their own cmp2 system.
So it sounds like "cics" turned over access to the web site to other people - who else is currently involved with adding material ?
Well, it has a very formal web site:
If folk like to describe the site as "formal", that's fine by me: several years ago now, I edited much of the material on it though I had no input into the design.
As anyone who knows what editors do can confirm, they do not of necessity approve (or disapprove) every point, claim or whatever that an author makes. Once I passed the edited copy over to cics, my involvement ended. Some time later, it appeared at the location you cite. Bar a couple of minor updates some time back, little or no material has been added since.
So it sounds like "cics" turned over access to the web site to other people
I'm not sure where you get that idea from. Beyond restoring the site a year or so ago when it got hacked and wiped out, cics has had no involvement for the period I mentioned. To my knowledge, no one has been delegated to its maintenance since though some recent "post cics" notes have, I believe, been placed (in English) on an Italian-language web site. How formal they are, I cannot say.
HTH
When talking about that website, I do not think information on this page is correct
http://www.cicsmemoryplayer.com/index.php?n=CPlay.ASIOLatency
Various latency has no impact on PCI data bursts, the buffer mentioned is not a buffer of the soundcard, but a region of RAM dedicated to DMA for the card. The PCI DMA activity is independent of size of this region, a PCI card keeps fetching data continuously into its small fixed buffer regardless of how often it wraps up reading the memory region.
Specifically for the mentioned Juli:
http://alsa.cybermirror.org/manuals/icensemble/Envy24HT091DS.pdf , page 4-18.
Upon finishing reading a part of the region an interrupt is thrown, but this can be tuned to just a few a second. Such setup will not create more noise than thousands of interrupts a second as with the recommended minimum latency. Plus IRQs are not the data burtst the page talks about. In fact it does not mention IRQs (being the major issue) at all.
I think you are right, it looks like about 10 interrupts a second per channel are needed at 192/24 to account for the 16 bit counters. Too bad these aren't 32 bits counters, but even at 10 Hz one is into the frequency range common to tape jitter, i.e. the ear is not terribly sensitive.
The presumption that smaller buffers are better may have been appropriate in the case of SPDIF connection to a DAC. Here the idea was to put the jitter frequency above the PLL cutoff, so that the DAC would reject jitter caused at the interrupt frequency. This assumption would appear to be completely inapplicable in DACs that are locally clocked, whether SPDIF with clock coming from DAC or async USB.
I never placed much credence in cics's explanations of jitter as the justification for his approach, once it was clear that he thought it was better to clock the DAC from the computer and design the software to optimize this case. It is clear that the best optimization of software is going to be different in the two cases: computer clocked or DAC clocked. There is no reason why computer clocked should ever sound better than DAC clocked unless the clock circuitry in the local clocked mode is poorly designed. So to me the entire premise of the optimization was faulty. Basically, a case of optimizing the deck chairs on the Titanic.
No real progress will be made so long as the DAC (and reclocker) manufacturers do not accept full responsibility for any effect of transport jitter on analog sound quality. It is simply impossible to "optimize" across the immense complexity in a computer system coupled with unknown behavior on the part of an attached DAC. There are two simple interfaces that can be used, I2S or SPDIF, and both of these can be clocked at the DAC. This is the place to build in isolation, not inside a computer system with billions of transistors.
Of course there will always be audiophiles who will note that the latest versions of software are better, indeed significantly better, than previous versions. This has been going on with several product families on different O/S systems for long enough now that most of these claims would appear to lack all credibility. If this were really true the posters would have evaporated into "sonic nirvana" never to be heard from again. Most likely, what is going on is that a sequence of changes that are audibly different are seen as continual "improvement". This is a known property of human psychology, i.e. loops are possible: A is better than B, B is better than C and C is better than A, etc...
IMO, rather than futile worry about irrelevant minutia one would be better to (a)either design and build a system that works if one has the talent, resources and inclination, or (b)enjoy one's music on any of many good playback systems.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
Dear Tony,
I donīt think youīre entirely fair to cics approach here....
When cics & co. started the project (2007)there was a only very few (pro-gear) DACīs that could run async mode over USB or FireWire.
I think there were consideration for certain cost point and some practicallity issues when the cMP system were laid out for the Juli@ card.
I have helped a few people setting up cMP with different soundcards and Iīm using async FireWire myself, and there is no doubt in my ears, that various optimizations have quite different effects.
When running my system with a Lynx two-B via internal D/A, almost every step of the "cics receipe" has had positive gains in quality.
The same has been the case with the Juli@ and cards from RME running digital out (S/PDIF / Toslink).
A number of cMP users here in Germany have experienced that the point where cMP REALLY excels, is in combination with relative modest (inexpensive) DACs. It clearly shows, that when DACs are fed with very pure (low in jitter) data, the result can become incredible high fidelity.
We have seriously been surprised how well cMP works on a number of resonably priced DACs
-and thatīs a very useful point to many.
It is of course resonable to expect a 2-3000 USD DAC to reject a significant amount of jitter, but not everyone can to spend this amount of cash.
I may add that changing the Lynx Two-B in favour of external Lynx Aurora via async FireWire was a huge step up (albeit almost same technology), but the difference between cMP2 and ordinary Win XP was only marginal.
How much of this is explained by the Auroraīs PLL tech or merely because the clocking is async is hard to say.
Nevertheless : cMP2 optimization does make a huge difference on less than state-of-the-art DACs connected over S/PDIF !
kind regards
cMP2 Computer w/digital crossovers & FIR filters > Lynx Aurora 8 FireWire /192kHz all channels. 2x AcousticReality Ref. 202 & 2x AcousticReality Ref. 601īs ICEpower. Magnepan MG3.3R beechwood frames & custom stands. Miller chokes
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: