 
|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
|
|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
74.171.207.68
I'll first get right to the question...
If one uses an asynchronous USB DAC, how important is the PC to sound quality? Can one "skimp" a little instead of going to a full-on CMP type machine?
In my situation, I use a Wyred 4 Sound DAC2 with an HTPC that I built about a year ago for movies and high-resolution audio. The machine uses an AMD Athlon II dual core on an Asus motherboard with the integrated HD4200 graphics, several hard drives, all powered by an OCZ 550W power supply. Is this "good enough" for use with the DAC2, or should I invest in a standalone audio PC?
Thanks all
Follow Ups:
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.
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
Hey needtubes,
There is a lot of confusion about what asynchronous drive mode is about, and I don´t claim to give you a last word on this, but look at it this way :
when a USB DAC is running asynchronous mode it runns it clocking on its own (reference-)clock.
In this way the DAC should only capture/request the data that is the music file from the computer.
Irrelevant how jittered this data is drawn from the computers software, an asynchronous connection should asure that this data will be processed and clocked at the best the DAC´s internal clock can do.
In such synchonisation the DAC is the "master" and the computer/software just follows suit; i.e. delivers the file data.
In other transfer modes (adaptive USB; S/PDIF) the computer "is sending" data with potential jittery clock sigfnals, and this jitter have to be removed by more or less effective PLL´s (jitter-reduction circuits).
Especially in the later typoe of transfer mode, it makes sense to configure the computer so, that it delivers a pure, un-interrupted stream of data. That´s some of the idea behind the cMP concept.
When the DAC however is designed as asynchronous, it should not be affected by any jitter from the computer.
A twist on this, is that cPlay (of cMP fame)is designed as true ASIO software, and, albeit that it works with the asio4all driver, it can not run as a fully asynchronous system unless the USB DAC comes with a bespoke ASIO driver that allows the DAC to synchronize/communicate the clocking with cPlay.
With the appropriate ASIO driver, cPlay can such become an integrated part of the DAC´s own DSP.
In such way cPlay "hangs on"(is slaved) as pure data delivery, and nothing is clocked or synchronized before data reaches the D/A concerter.
In this case, the data timming issue (jitter) becomes almost irrelevant.
Only few DACs come with propritary driver software (even asynchronous ones) and I presume that this is caused by the substantial cost of developing such software, and that most consumer DACs will be hooked up to streaming clients anyway. These are not quite as prone to jitter as computers are, and not designed for installing communication (protocoll) software anyway.
hope it clears this subject a bit....
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
The problem with this statement is that the interface between the computer and the DAC is the same regardless of which isochronous mode you use, be it adaptive or asynchronous. The DAC still must use PLL circuits to capture the USB data since there is no clock. Asynchronous mode just provides a feedback path from the DAC to the computer to adjust the source data rate. It doesn't guarantee any better performance. That has to come about from good engineering on the DAC side in order to keep all the jitter in the interface circuit clocks out of the audio clocks (and data as well), which isn't a simple task. It is easier with asynchronous mode because one then has the option to use a high quality local clocks in the DAC (you need more than one clock to cover the various sample rates if using fixed frequency oscillators), but that isn't what everyone does.
Hey slider,
you wrote :
"That has to come about from good engineering on the DAC side in order to keep all the jitter in the interface circuit clocks out of the audio clocks (and data as well)...."
-that´exactly my point.
With soft- and hardware working in tandem, the interface circuit uses only one point of clocking (the one at the converter).
Where a streaming client/network player has no possibility of installing a dedicated driver software, a computer can be configured to use a tailored driver protocol which allows the player software to be slaved to the external clock only.
In such configuration an asynchronous interface is a requirement.
Needless to say that the precision and quality of the entire circuit then is determined by this clock.
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
One can use the default Windows USB driver for asynchronous operation and still use applications, such as cPlay, that require ASIO interfaces. One just uses a shim program such as ASIO4all that will allow the application to access the Windows async USB driver.
With one more software component there will be additional ways to misconfigure the audio stack and thereby get inferior sound. However, if each portion is set up correctly the results can be bit-perfect. Whether this approach will sound better than an alternative software approach that eschews the async USB capability will depend on the particular system and will have to be ascertained by listening.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
Hi Play-mate and needtubes,
I think in general you are right. I used JRiver in ASIO mode quite happily for quite a while. And I thought the same as you - jitter is down to low levels as the DAC does the work on clocking its signal. So all is "well with the world". The journey is over :)
The thing is, I have found that "everything" matters. After you listen to your setup for a while, especially if you have a PC, you can "play". Try things... Try cPlay. Try Jplay. Try JRiver (with ASIO and WASAPI). Try a laptop. Try linux. Try Apple (if you can afford it). Try an audio "appliance".
Here's what I have heard so far...
-> JPlay rules. I have to admit that I haven't tried a dedicated audio player (ie. appliance). The closest I have come is a laptop running Fidelize, JRiver and JPlay. And to be honest I just might try an "appliance" next. But for now I have my reference. I think cPlay is much the same as JPlay (from what I've read) but I haven't tried it. I'm "happy" :)
-> RF matters... Any switching power supply adds noise. CPUs, Video cards, etc. even make a difference. Use as sparingly as possible.
-> Run in memory. SSDs are okay, hard drives suck - unless it runs in memory :) Even then I'm not sure. But in some cases, who knows.
The bottom line is... Sorry... It's all a toss up. How many of us who are doing CA use the same setup? Not many.
All I know is I try to (and do) keep getting closer to music. It's a journey we all (unfortunately) have to take. I wish there was a panacea. If you can do it for free - do it - if that's what works for you. If you want more you'll have to search and experiment.
And hopefully the above things I've learned help!
All the best,
Jeff
Hi guys,I can second jmall's point of view saying "it's all a toss up". My experience includes fiddling with cMP/cPlay, foobar, JRiver, JPlay, XP, Vista, W7, WASAPI, ASIO drivers by Musiland/TeraDAK/Onkyo/ASIO4ALL, a NOS-DAC (TeraDak 3.1D), a good traditional DAC (Audio-gd NFB2), a modern asynchronous DAC (the one integrated inside Onkyo's new A-9000R Amp), a simple asynchronous DAC (Musiland Monitor 02US), a little re-clocking device (Audio-gd's Digital Interface =DI), an USB isolator (USB2ISO), a true original cMP²-machine, a netbook (Lenovo 205S) and a regular big workstation PC. I don't use upsampling except with cPlay. System drives were SSDs in all machines. I out the following:
1.) the combo workstation(W7, no optimizations, foobar)-> USB2ISO-> DI(power over USB)-> TeraDak(NOS)-> Beyerdynamic880DT is just GREAT. That's not an asynchronous system.
2.) the combo netbook(Vista, no optimizations, foobar)-> Onkyo-USB-DAC/Amp(asynchronous, true native proprietary ASIO drivers)-> speakers differs only in its sound signature (a little brighter) from the combo netbook-> Musiland(only USB-to-SPDIF used, but with true native ASIO)-> NFB2-> tubeamp-> speakers (a little darker and easier on the ears, but slightly less detail). The overall quality is the same.
3.) the combo original cMP²-machine(cPlay+ASIO4ALL)-> DI-> NFB2-> tubeamp-> speakers provides a softer, more analytic sound signature than the other three, but not more pleasure. It is not asynchronous. Overall I don't hear a significant advantage/disadvantage over the netbook configuration, but personally I prefer the "forward-playing" sound over the analytic.The logic inherent in the asynchronous approach appeals a lot to me, but at least with small, cheap re-clocking devices (DI, the TeraDak is also said to have a certain re-clocking functionality), their quality and effectiveness not thoroughly approved, great sound in adaptive systems seems to be possible just the same. So it all ends up with "buy what you can afford and what appeals to you, test and re-combine it, and find your personal optimizations". It is as frustrating as that (though the outcome bears great potential to be very pleasing). The most simple combo I found so far was Netbook(foobar)-> Onkyo A-9000R. That's it. It sounds extremely transparent and extended, but a tad on the brighter side and therefore not completely soft. And the overall cost for it may be the same as or even significantly less than for a true cMP²-machine and a good asynchronous DAC with good native ASIO drivers.
To me it seems as if the DACs contribute surprizingly little to sound quality - even the cheapish TeraDak 3.1D yields GREAT results. It seems to me that good native ASIO drivers are a key feature for good sound, since they are standing for a direct communication between player and DAC (or USB-SPDIF bridge), consequently the fastest and most direct way "out of the computer". Players may have a lot to do with disturbances by computer activity, so a player resistant to "intrusion" by such activity may be preferable. And lowering the computer's general activity as it is realized in cics' XP tweaks is generally a good idea (as the JPlay guys say: "it's all about timing" - and that timing inside the computer may suffer from irregularities by the computer's activity). But I must admit that I haven't tested JPlay thoroughly so far, so I don't know yet what its computer activity strangulation really does in favour of the sound. To me cMP/cPlay softens the sound, but it doesn't necessarily improve it (mybe my ears don't like upsampling...).
All right...?
Eunegis
Edits: 01/01/12
You should be fine with your music on your current machine. I have my music stored on my work computer with lots of applications. My music sounds great on this setup.
I have used various PCs with my Ayre QB-9 (async DAC) and they all sounded different... I personally would have to say unless you can get the power supply outside the desktop case - go for a laptop (if you have the choice). I have been using a fairly dated T60p IBM laptop (dual core, 2GB RAM, ~4 years old, Win7 x64 Ultimate) as my source these days. It's just better sounding then my fully outfitted desktop. Very "dark" backgrounds mainly. Let's the microdynamics come to the fore.
The lesson here is -
a) yes, the PC system you use has a lot to do with it
b) dedicate it to audio
BTW - the best sound I have found in PC audio (aside from running a 64bit version of Win7) is JPlay... Depending on my mood I might use J River to just play whatever, then JPlay without hybernation, then JPlay with full hybernation. Each is a bit different, progressively sounding better. Also, the latest beta of JPlay has a mini-mode for J River which also sounds excellent and allows you to use the J River interface but the audio goes through JPlay. An excellent match :) And if you are "full bore" into listening you can still use hybernate mode. Something to think about coming down the pipe.
Good luck!
Is it worth the effort to use a linear regulated power supply when using an async USB DAC? I'm sure it can't hurt...How good of a power solution is something like a PicoPSU or Morex converter with a 12V external brick supply?
Edits: 12/30/11
Well, the Music Streamer II line of Asynchronous USB DACs use an internal power supply that creates its own regulated power that only depends on the USB line as a raw power source. So, since the quality of the USB power does not matter to it, and the clock timing of the provided audio stream does not matter to it, then that means that a lot of the mods in the CMP hardware are not needed, and any properly made USB cable will work as well as the expensive ones (that are otherwise needed for adaptive USB DACs).
Unfortunately, the CMP project has not tagged each hardware and software mod with "this will help with jitter" and "this will help irregardless of jitter", so it is hard to say how much is unnecessary with an asynchronous USB DAC and how much still helps.
Previously I had found MusicBee player to have the best sound quality with my asynch USB DAC simply because it allows the user to specify a low buffer size (unlike foobar2000 and xmPlay which do not). But then I compared MusicBee and cPlay and found that cPlay does have somewhat better quality yet.
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:
Top of Page ]
[ Contact Us ]
[ Support/Wish List ]
[ Copyright © 2024, Audio Asylum, all rights reserved ]
