Article: Weiss Engineering DAC202 Review

[rlodad]

Chris,<br />

I am sorry if you think the comments are unrelated. I do not and did not think they were. Sorry,but you do not have my understanding. My question to Charlie Hansen was in response to his comments regarding the review, and my question to Gordon Rankin directly relates to the discussion and review(though perhaps I didn't make that clear) because I own a BADA (frankly, in part due to your review)and I wonder how the BADA with a Wavelink and shorter digital cable would compete with the Weiss DAC 202, the new king of the hill, and subject of your current review. Why should I start a new thread, which Gordon might not even see if it has few comments and doesn't make your "heavy hitters list" when he is in the conversation here, and I think it relates? I could dump CA and just ask him directly. Then nobody but he and I would benefit.<br />

<br />

If people are offended by posts that they see as unrelated in their in boxes, turn off e-mail notification.If you don't like the comments, skip them.<br />

<br />

[rlodad]

Barrows,<br />

Chris could not be the "suppressor." He is receiving the post. The suppression about which I inquired would be a passive one. My point is, I never see too much info. as a bad thing, and want to know any question asked by anyone. if not useful, I hit the delete key.

[weiss2496]

Gordon, if in that context "async" means that the DAC contains the master clock (for the sampling rate) and that the audio source is somehow slaved to that clock, then the Firewire scheme used in the DAC202 is an "async" one. <br />

An example that it has to be like that is what I have mentioned above, i.e. if the DAC202 is synced to an external clock the computer simply can not be (another) master, except there was an asynchronous sampling rate converter involved, but that is not the case with the DAC202. <br />

Also, the sampling rates, be it 44.1 and multiples or 48.0 and multiples, can be generated out of a single crystal oscillator with high precision and low jitter. Provided a proper PLL is employed. And that is what is used in the DAC202.<br />

<br />

Daniel<br />

[Wavelength]

Daniel,<br />

<br />

So you are saying you have two fixed oscillators in the DAC202, that when configured become the basis for the Master Clock going to the DAC chip as well as being feed back into the DICE chip to make the I2S (or other digital audio stream L/R justified, dsp etc)? This would be a requirement for true asynchronous use.<br />

<br />

rlodad,<br />

<br />

I never go out and test other companies products. This tends to make me stray from my design goals set for any product. It is best for you to contact some dealers and make the call yourself. Also it would be pretty unethical to take the word of any company when they talk about a competing product. What you think they are going to say that theirs is worse? come on...<br />

<br />

Metric Halo fans... FYI from their site....<br />

<br />

I got a couple of emails this morning and I am sorry to say I was wrong about their implementation it would be very similar to Daniels and is not Asynchronous in nature...<br />

<br />

<cite>MIO uses both types of transfers, isochronous and asynchronous pretty much all the time. The isoch transfers are used for audio transport and the async transfers are used for control, metering, and firmware updates. <br />

<br />

From their FAQ page.<br />

<br />

Thanks<br />

Gordon

[manisandher]

<em>"The isoch transfers are used for audio transport..."</em><br />

<br />

Could someone explain exactly what this means please?<br />

<br />

Mani.

[rlodad]

Gordon,<br />

<br />

I need to start doing this stuff at the end of the day. Clearly, I can't get my point across typing between patients.I wasn't implying that YOU should buy or borrow a DAC202 and/or a BADA to test with and without the Wavelink. I was trying to get an update on when it might be released so that I could buy one to use with the BADA and perhaps Chris might test it with both the DAC202 and the BADA to see if the Lynx and AES/EBU 110 ohm input is the weak link in the "BADA chain."<br />

<br />

Back to work for me.

[labjr]

<i><br />

"Metric Halo fans... FYI from their site....<br />

<br />

<i><br />

I got a couple of emails this morning and I am sorry to say I was wrong about their implementation it would be very similar to Daniels and is not Asynchronous in nature...<br />

</i><br />

<br />

Now two highly regarded DACs aren't even async.<br />

[cfmsp]

<br />

"Could someone explain exactly what this means please?"<br />

<br />

Agreed, I think we are deep into semantics here.<br />

<br />

Per my understanding, isochronous mode is a 'dedicated bandwidth' feature of 1394 spec (as Daniel explained). Essentially it means that nothing can interfere with the peer to peer communication between the firewire nodes.<br />

<br />

<br />

Re the entire comment "The isoch transfers are used for audio transport and the async transfers are used for control, metering, and firmware updates."<br />

<br />

It's been my understanding that the two modes were being used simultaneous. E.g., saying that the isochronous feature is being used to transfer data does not automatically mean that the data on the firewire bus are not also being processed asynchronously.<br />

<br />

OTOH, I'm certainly no expert.<br />

<br />

as a non-expert, I'm also not sure what, if any, advantage can be claimed for (what Gordon called) True Asynchronous versus the MH/Weiss approach of sending signals to the clock upstream. IOW, how this is a detriment as compared to the "control of flow" commands sent upstream in Async? I can't say. <br />

<br />

And now that it appears that (several of) the best sounding world class DACs do not, technically speaking, use Async, I don't really care. <br />

<br />

What IS interesting to me is that Firewire DACs don't seem to (be as likely to) benefit from fancy cables (as do Async USB), when the opposite would seem to be the case given that USB can claim Async status. ;0<br />

<br />

curiouser and curiouser,<br />

<br />

clay<br />

<br />

<br />

[cfmsp]

"Now two highly regarded DACs aren't even async."<br />

<br />

Myth-busters indeed! Firewire (based) DACs don't even need Async to do their magic. ;0<br />

<br />

<br />

<br />

And kudos to BJ, whose designs kick ass with absolutely NO audiophile pedigree whatsoever! I love it!<br />

<br />

EDIT: and also kudos to Daniel, who straddles the line between pro and audiophile gracefully (baring one exception, that of the "twice the price" Minerva vs. the DAC2)<br />

<br />

Plus, I was getting tired of typing Asynchronous.<br />

<br />

Also, as Gordon has consistently pointed out in the past, it's not the Asynchronous transmission that's so important, rather, it's (Async's support of) the use of fixed oscillators in the DAC being used as the master clock.<br />

<br />

clay<br />

<br />

PS, As far as I know, MH do NOT need nor use PLLs in the manner Daniel describes, as they employ two oscillators - one for 44.1/88.2/176.4 and another for 48/96/192. I know from personal experience as the first time I tried to play a 96k sample rate file, my ULN-2 would not lock on. Turns out it's "clock" for 48/96k processing needed to be replaced.<br />

[manisandher]

I can't be the only person who is totally gobsmacked by the fact that these firewire DACs are not truly async after all. I mean, it seems some well-respected posters have had it wrong all this time...<br />

<br />

Mani.

[cfmsp]

Mani,<br />

<br />

there's a several reasons to be gobsmacked here, but the one you point to is the less important one, in my opinion.<br />

<br />

The ramifications of this revelation is that the cachet of Async has next to nothing on which to base it's reputation other than Gordon DACs and now Ayre's QB-9. Nothing, nada, zip! <br />

<br />

EDIT: okay, well dCS can be counted, but there gear is so expensive that I don't tend to even consider it.<br />

<br />

Said another way, the much extolled virtues of Async transmission were based in part on Firewire devices that are not Async (per Gordon's views on what constitutes Async).<br />

<br />

Indeed, apparently NONE of the "well known" contenders (AFAICT) for world class sound in the $5k (+/= $1k) range are actually Asynchronous. Not the BADA, nor any of the Weiss's, nor any of the Metric Halos, not the PM Model Two, nor well, you get the idea. <br />

<br />

[Note: no disrespect to Gordon but his Crimson is pricier than this even in base dress and not as much is known about its sound compared to those mentioned above. I"m sure it sounds awesome!]<br />

<br />

How's that for 'gobsmacked' material?!<br />

<br />

To be fair, and going back to my earlier post, Gordon has said all along that it's not Async that matters, it's the fixed oscillators in the DAC being used as master that's the real deal, and of course, he practically yells that none of us should be worrying about the armchair engineering (as does Chris).<br />

<br />

But yeah, more than a few of us (including me) missed the boat.<br />

<br />

clay<br />

<br />

[labjr]

<i>"And kudos to BJ, whose designs kick ass with absolutely NO audiophile pedigree whatsoever! I love it!<br />

</i><br />

<br />

I'm not sure BJ is not pedigreed. He just doesn't blow his horn in the high-end circles. He delivers the goods.<br />

<br />

He's pretty well versed in digital from what I gather by anything he's written or commented about.<br />

<br />

<i><br />

"EDIT: and also kudos to Daniel, who straddles the line between pro and audiophile gracefully (baring one exception, that of the "twice the price" Minerva vs. the DAC2)"<br />

</i> <br />

<br />

This is the reason I questioned the value of the Weiss products. They may very well sound good, but it seems the MSRP is getting a bit ridiculous for what it is. <br />

<br />

EDIT: OMG is it me or did the price jump up since you wrote this review?

[barrows]

"The ramifications of this revelation is that the cachet of Async has next to nothing on which to base it's reputation other than Gordon DACs and now Ayre's QB-9. Nothing, nada, zip! "<br />

<br />

Do not let your enthusism for the sound of the Metric Halo products blind you to the truth.<br />

Actually, Async Clocking is used by most good single box CD players, and products such as the PS Audio PerfectWave transport, and PerfectWave DAC with Network Bridge, and the Genesis Digital Lens reclocker.<br />

The technology of an async interface using fixed frequency oscillators is inherently superior in jitter performance to any other clocking method, as the jitter inherent in a properly implemented async interface is solely the inherent jitter in the clock itself-any other clocking method will introduce more jitter, by definition. The reason for the additional jitter in any other clocking scheme, is that a PLL is used to generate the appropriate clocking frequency, using an oscillator for reference. Once a PLL is added to the clock circuit, one is now dealing with the jitter (at least) of the oscillator itself, plus that of the PLL.<br />

Now whether or not the additional jitter of a non async solution is an audible problem is something for the listener to decide-but the fact remains that async clocking is a tecnically superior solution.

[cfmsp]

<br />

"I'm not sure BJ is not pedigreed. He just doesn't blow his horn in the high-end circles. He delivers the goods.<br />

<br />

He's pretty well versed in digital from what I gather by anything he's written or commented about."<br />

<br />

I agree totally. My point was that BJ delivers the goods without the use of any audiophile approved (rather than pedigreed) methods, e.g. he uses op amps, SMPS, DC-DC converter, etc.<br />

<br />

well, if this isn't proof (to me) that Gordon is right about stopping the armchair engineering, I don't know that I'll ever get it.<br />

<br />

clay

[cfmsp]

I'm not blinded, imo. <br />

<br />

Re the point of my comment that you quoted - My intent was to point out, as I did elsewhere in the post, that the cachet that async has here on CA is, in large part, (apparently) due to misconceptions that several well regarded Firewire devices were assumed to be Async. To your comment below, I don't believe that the Async reputation here is built on the devices you mention.<br />

<br />

"Actually, Async Clocking is used by most good single box CD players, and products such as the PS Audio PerfectWave transport, and PerfectWave DAC with Network Bridge, and the Genesis Digital Lens reclocker."<br />

<br />

None of these products that you mention (are reported to) sound better than (or even as good as) the non Async DACs that I referred to! <br />

<br />

...and from my understanding the Asynchronous method in the PWT and the Digital lens is more accurately called a buffer and has nothing to do with using fixed freq oscillators as master clock in the DAC. I bow to your greater wisdom of things PS Audio, but I looked into this last year, and I doubt that it's changed.<br />

<br />

Additionally, the reason we have a great site like computer audio is that the CD players you refer to as using async interfaces can be bested, and rather handily, by any number of non-Async DACs.<br />

<br />

But you are right, I really did overstate things! <br />

<br />

<br />

<br />

"The technology of an async interface using fixed frequency oscillators is inherently superior in jitter performance to any other clocking method, as the jitter inherent in a properly implemented async interface is solely the inherent jitter in the clock itself-any other clocking method will introduce more jitter, by definition."<br />

<br />

Can you (or anyone) state with any certainty that the mechanism in use by Metric Halo is actually inferior to the 'inherently superior' Async interface you point to? Or that it introduces any more jitter?<br />

<br />

I don't believe that a PLL is in use for Internal clocking mode, but I can check.<br />

<br />

As far as I can tell, MH's use of fixed frequency oscillators and use of async communication upstream to 'control' the speed at which data is received by the clock is only different semantically from Gordon's definition of Async. <br />

<br />

Is there a practical difference that has an impact on the sound? If so, I don't get it yet.<br />

<br />

I'd say the proof is in the pudding. If we look at the evidence (of "true" Async DACs as compared to the MH) I'd say that we don't. Indeed using your examples, and even that of the Ayre QB-9, in my opinion, the evidence favors non Async (if indeed the MH box is not Async), any theoretical advantage notwithstanding. <br />

<br />

GOrdon's top piece uses a 'take no prisoners' analog approach and it starts out at almost twice the price of the LIO-8 before you start thinking about all those oh-so-tempting options (I've looked at these too!). For that reason, it's hard to do a comparison on a cost basis with the top non-Async DACs.<br />

<br />

BTW, I would (still) tend to agree with you that Async SEEMS like it would be theoretically superior - I'm not really arguing that, only that IF the MH box actually significantly differs from Async, then frankly, my opinion will change - and the theoretical advantage will be just that - almost entirely theoretical. <br />

<br />

In fact, the reported sound of the Weiss DAC would seem to call in question, the significance of any perceived inherent disadvantage of using PLLs.<br />

<br />

If my post comes across as combative, that's not my intent. I'm really enjoying a conversation with people whose opinion I respect a lot - thanks for your post.<br />

<br />

all the best,<br />

Clay<br />

<br />

<br />

[vonBraun]

Thanks for the informative article and your enthusiastic opinion. I've enjoyed the spirited comments as well.

[Part-Time Audiophile]

Where else can you find three of the biggest names in computer audio debating the finer points of a third-party review of an audio product? This is friggin' awesome! <br />

<br />

Charles, Daniel, Gordon -- please, for the love all that is good and righteous -- keep it coming! <br />

<br />

Sweet!!!<br />

<br />

[Andrew S.]

Hey Clay what about this:http://www.centrance.com/products/dacport/<br />

<br />

<i>Jitter Management - Debunking the Asynchronous Myth<br />

Some manufacturers may lead you to believe that Asynchronous USB transfers are superior to Adaptive USB transfers. This no more true than saying that you "must" hold the fork in your left hand. If you know what you are doing, you will feed yourself with either hand.<br />

<br />

<br />

<i>The USB argument comes down to jitter management and goes as follows: In Asynchronous mode the device is the clock master. In Adaptive mode, the computer is the clock master. Either way works fine, if correct design principles are followed. Here is the tricky part that often gets omitted: No matter which side is the source of the clock (PC or DAC), the two devices are still connected by the USB cable and the digital data on that USB cable is always irregular because the computer is involved. Computers do many things at once and end up sending data over USB in irregular intervals, no matter who is the clock master on the bus. This irregularity causes jitter. So, there is no jitter-free solution, just like there is no dust-free house. Irregularity always creeps in and needs to be actively managed.<br />

<br />

<br />

<br />

<i>Here is where the Asynchronous vs. Adaptive argument breaks down: In either of the two clocking schemes, jitter is present during transmission. It's inevitable and also ok, if it is properly cleaned up prior to the D/A conversion, where it matters most. Neither clocking scheme is superior and both are capable of performing well if you know how to reassemble the bits prior to the DAC. Now, how do you actualy do that? There are many ways, the oldest and simplest of which is buffering. Irregular data comes in, regular data goes out. The most important part is to make sure that samples leaving the buffer on the way to the DAC are clocked accurately. DACport employs JitterGuard™, a proprietary two-stage clock management system that does just that - cleans up the jitter on the USB bus so that samples are virtually jitter-free at the D/A conversion point <br />

<br />

oh and don't forget dCS....they are truly async aren't they.<br />

Have a Dacport for use in the office. Nice kit.

[labjr]

Actually, BJ seems well versed in all aspects of design. Analog, digital, power supplies. And there seems to be no pretense at all with him. No ego trip. <br />

<br />

To me it seems that Async transfer is more of an advantage with USB than firewire. Maybe because the USB interface works differently and the clocking etc is different since it wasn't originally designed for audio video like firewire.<br />

<br />

BTW, the price of the DAC202 was increased. I googled the article and the review originally had the DAC202 priced at $6440. So the price has gone up by $230. Is that because our discussion is drawing attention to the DAC202, thereby increasing the value of the product? It's a becoming a hot commodity!

[Charles Hansen]

>> Jitter Management - Debunking the Asynchronous Myth <<<br />

<br />

This is just silly. Of course, here's a manufacturer who has a dog in the fight. All of his products are adaptive (although I've heard rumors that he's working hard on asynchronous technology). So of course he's going to defend his technology. (At least until he get async working.)<br />

<br />

And the perceptive reader will note that I also have a dog in the fight. But these claims are just silly. I won't even bother to rebut them as there are probably a couple of dozen posters here that could just as easily.<br />

<br />

That said, jitter is just one of hundreds of parameters that affect the sound of a digital product. But since it doesn't cost any more to do it right and use async to get the lowest jitter possible, that is what we choose to do. And of course we also address all of the other factors that we can (given the price point and given the fact that we refuse to build our equipment in Chinese prison camps).<br />

<br />

And the wonderful thing is that you, the consumer, get to buy whatever equipment you want for whatever reason you want. Maybe because you like the looks. Maybe because your dealer will give you a discount. Maybe you like the sound. Maybe you like the feature set. Maybe, maybe, maybe....<br />

<br />

Have fun and happy listening!

[labjr]

<i><br />

"This no more true than saying that you "must" hold the fork in your left hand. If you know what you are doing, you will feed yourself with either hand.<br />

</i><br />

I don't know if I'd believe what centrance says. Seems like propaganda. And what the heck does eating with a fork have to do with jitter?<br />

<br />

The problem with USB adaptive mode appears to be that the DAC clock has to follow the computer clock so you can't use a highly stable clock at the DAC. It has to be continually readjusted and that causes jitter.<br />

<i><br />

"No matter which side is the source of the clock (PC or DAC), the two devices are still connected by the USB cable and the digital data on that USB cable is always irregular because the computer is involved."<br />

</i><br />

<br />

So get out of the business of writing code for USB receivers then. <br />

<br />

<i><br />

"Jitterguard"<br />

</i> <br />

<br />

I hate names like "Jitterguard" or "ultralock" some companies give to their processes. To me it's a sign that they don't know what they're talking about so they need all these trademarked buzz words to create marketing hype.

[barrows]

to respond:<br />

<br />

"None of these products that you mention (are reported to) sound better than (or even as good as) the non Async DACs that I referred to! :)"<br />

<br />

The above is subjective analysis, as stated in my post above, my only concern was to state that from a technical perspective, asyncronous clocking with fixed frequency oscillators will result in the lowest possible jitter, as the jitter is essentially just the inherent jitter of the clock itself and nothing more. As noted, the listener has to decide which sounds better, but-I have participated in listening tests which compared using an asyncronous clock to using using a PLL generated clock with all other parameters staying as close to the same as possible, and there was no contest-the asyncronous clock was obviously better sounding.<br />

<br />

"...and from my understanding the Asynchronous method in the PWT and the Digital lens is more accurately called a buffer and has nothing to do with using fixed freq oscillators as master clock in the DAC. I bow to your greater wisdom of things PS Audio, but I looked into this last year, and I doubt that it's changed."<br />

<br />

Both The PerfectWave transport and the PerfectWave DAC (when operating as a network player with the Network Bridge installed) are asycronous, with two fixed frequency oscillators (one for 44.1 base, and one for 48 base), clocking the data out of the memory, with no reference to any incoming timing. In the case of the PWT and PWD used together, the master clock ends up being in the transport, but they are connected by I2S (not SPDIF), so the transport clock connects to the DAC directly (no PLL). When the PWD is used as a network player, it is asyncronous also, fixed frequency oscillators control the timing out of the memory, direct I2S to the DAC chip, with no reference to any other clocks. <br />

<br />

"Additionally, the reason we have a great site like computer audio is that the CD players you refer to as using async interfaces can be bested, and rather handily, by any number of non-Async DACs."<br />

<br />

In my experience, this is actually not true, and is one of the fallacies of computer audio. A really good single box CD player will beat most simple computer based systems, at least to my ears. In any case, this is off my intended topic: that asyncronous clocking is technically superior. <br />

<br />

RE: Metric Halo, they do not seem to be very forthcoming in describing exactly how their products work, this is certainly their option, do you know how they work in regard to generating the clock? I am just curious.<br />

As Charles H. mentioned, everything matters, and jitter is just one parameter. A DAC might sound good even with higher jitter if everything else is well sorted-my only point is that this same DAC will sound even better if its jitter is lowered (while keeping everything else well sorted).<br />

<br />

Centrance: yup, looks like they are using some marketing terms (not that there is anything wrong with that). Sounds like they are using a dual PLL, similar to what Weiss does, to "clean up" the jitter. This is what might be referred to as a "band aid" approach-it might work (and it might have negative side effects, as I believe asyncronous sample rate converters do)-I have to agree with Gordon Rankin's approach here, much better to not get wounded in the first place, then no need for band aids.<br />

<br />

All of the asyncronous approaches take advantage of a memory buffer, the data goes in the buffer, and is clocked out by the appropriate fixed frequency clock. The key is keeping the buffer from overunning or underunning-my understanding is that Wavelength Audio's Streamlength code does this by managing the data sent over USB, slowing it down, or speeding it up as necessary so that no samples are dropped, and the clock at the output of the buffer can just run at the correct speed. The PS Audio products use relatively large amounts of memory, and use code to keep the memory from overuns or underuns. Adaptive USB (and Firewire using a PLL) systems instead change the clock frequency itself (introducing jitter) to keep the buffer from overunning or underunning. The asyncronous approach is a simple (although apparently difficult to implement) and elegant solution to virtually eliminating jitter as an issue.<br />

<br />

What's the best sounding DAC, well that is another question! But my experience leads me to believe that low jitter is important to the best sound-just like digital filters, power supplies, DAC converters, I to V and analog output stages, passive parts quality, etc, and in no particular order.<br />

[Elprior]

Totally agree with Barrows.<br />

<br />

I would add that you are constantly polluting threads here with MH products. The ultimate argument being 'it just sounds better'.<br />

<br />

That would be very nice to try and pollute only one thread out of two <br />

<br />

Although the rest of my comment is not totally on-topic also, I can say that the Int202 Jitter handling architecture has absolutely no effect in my system (against Jitter prone interface). So yes, there is more than Jitter in life <br />

<br />

Elp

[agentsmith]

Charles I have always respected your and your products particularly your no BS approach to pricing and marketing of your products.<br />

<br />

I am not from mainland China but but your comments of "Chinese prison camp" shows your ignorance and insensitivity.<br />

<br />

[cfmsp]

Barrows,<br />

<br />

"The above is subjective analysis,"<br />

<br />

Agreed, but I think there's a lot more support here for my position than yours.<br />

<br />

"... as stated in my post above, my only concern was to state that from a technical perspective, asyncronous clocking with fixed frequency oscillators will result in the lowest possible jitter, as the jitter is essentially just the inherent jitter of the clock itself and nothing more."<br />

<br />

As I stated I did not disagree with the comments about the theoretical advantage. My point was, and remains, that a large part of the evidence presented on CA (that convinced ME at least) that this theoretical advantage actually means anything in the real world was based on the belief that great sounding Firewire DACs such as the Weiss and Metric Halo products were/are asynchronous "in nature". If that is indeed not true (for the MH boxes that I have personal experience with), then MY OPINION as to the need for Async changes. <br />

<br />

I can sympathize with those who might think that my opinion (on Async) 'flapping with the breeze' here, but...keep in mind, my personal experience (on computer interfaces) is predominantly with Metric Halo boxes, and I was using the MH boxes as the evidence that allowed my full support for, and belief that, Async transmission WAS important. <br />

<br />

I'll also repeat - we've all learned that Async transmission is NOT the most important aspect (per Gordon and others) - it's the use of fixed freq oscillators (that are not varying to track some upstream clock) that offer the lowest jitter. <br />

<br />

<br />

I said:<br />

"...and from my understanding the Asynchronous method in the PWT and the Digital lens is more accurately called a buffer and has nothing to do with using fixed freq oscillators as master clock in the DAC. I bow to your greater wisdom of things PS Audio, but I looked into this last year, and I doubt that it's changed."<br />

<br />

Barrows, perhaps you missed my point here. I was referring ONLY to the (gratuitous, imho) use of the word "Asynchronous" as a description of the nature of the PWT and Digital Lens products themselves (Paul was using one year ago to describe their buffering scheme), and not the PWD used alone or with the PWT/Network bridge. I only made this comment due to your inclusion of the PWT and Digital Lens in your comment about the use of Async<br />

<br />

<br />

"RE: Metric Halo, they do not seem to be very forthcoming in describing exactly how their products work, this is certainly their option, do you know how they work in regard to generating the clock? I am just curious."<br />

<br />

I have an email into BJ now.<br />

<br />

I'll share the results.<br />

<br />

"The asyncronous approach is a simple (although apparently difficult to implement) and elegant solution to virtually eliminating jitter as an issue."<br />

<br />

The armchair engineer in me loves the idea of Async communication!<br />

<br />

<br />

"What's the best sounding DAC, well that is another question! But my experience leads me to believe that low jitter is important to the best sound-just like digital filters, power supplies, DAC converters, I to V and analog output stages, passive parts quality, etc, and in no particular order."<br />

<br />

agreed that the entire system is what's important. <br />

<br />

as for what is the best sounding DACs, I can only point to consensus beliefs as I don't have the time or opportunity or even interest in comparing all the top contenders. <br />

<br />

Re the consensus, I will restate that we now have a lot less evidence that Async transmission is needed for world class sound if indeed none (or very few) of the current contenders actually employ Async as defined by Gordon and your self. <br />

<br />

<br />

all the best,<br />

Clay<br />