Article: Weiss Engineering DAC202 Review

[Purite Audio]

I am sure that a discussion ( over a beer ) between the three designers would be fascinating and courteous, healthy competition is good, because it pushes the boundaries of what is achievable.<br />

Keith.

[barrows]

First, I am not suggesting that a Weiss converter will not sound good, nor that a Wavelength converter will not sound good. But some folks posting here need to get one thing straight: a fixed frequency oscillator will result in the lowest possible timing error (all other things being equal, assuming proper implementation). This is just a technical fact.<br />

A fixed frequency oscillator produces jitter at the inherent rate of the oscillator itself (plus increases due to board layout, and other implementation issues-these are assumed to be equal for the sake of understanding here).<br />

A PLL circuit, referencing an oscillator, produces jitter at a rate of the inherent jitter of the oscillator plus the inherent jitter of the PLL itself.<br />

There is no such thing as a zero jitter PLL, therefore using a PLL will result in more jitter than using a fixed frequency oscillator alone.<br />

Note-just as Manis example of the rear engine Porsche Carrera above-a converter using a PLL can achieve very good performance indeed-but to expand upon this example, at the highest level of automotive performance, Formula One, we do not see any rear engine cars-I submit that ultimately (and we may not be there yet) at the highest level of digital converter performance we will not see any PLLs.

[Elprior]

Well,<br />

<br />

formula ones are RMR cars, am I wrong ?<br />

<br />

What's more they'll broke into pieces after two days of normal traffic. The Porsche 911, on the contrary, will give you countless days of pleasure. <br />

<br />

Elp

[Charles Hansen]

>> At the end of the day though, the "complaint" about DAC manufacturers and self promotion wasn't aimed at Gordon so much as Charles IMO <<<br />

<br />

Wow! Tough crowd!<br />

<br />

Chris Connaker invited me to comment on the technology used in the Weiss. You may have noticed that I have not done so, simply because Daniel Weiss doesn't dispense enough information for me to make heads or tails of it.<br />

<br />

But I did start reading the thread, and when there were questions that I felt I could answer, I did so. Things like "How do you make a $500 asynchronous USB DAC?" Or, "What is the status of OS X with respect to 192 kHz USB audio?". When I thought it would be helpful to illustrate a point with an actual product example, I did so.<br />

<br />

Naturally I used my products as those are the ones that I know about, and yet I also included clear statements that there were other comparable products.<br />

<br />

And for my trouble, I am called names and denigrated. Believe me, I have better things to do than post here. Even with all of my "shameless promotion", I don't think we've seen an uptick in sales yet. So I'll be glad to let you all fight amongst yourselves and untie the Gordian knot of computer audio!<br />

<br />

Love and kisses,<br />

Charles Hansen<br />

President<br />

Ayre Acoustics<br />

(for the whiner who complained that I didn't make my affiliation clear)

[The Computer Audiophile]

<i>"Chris Connaker invited me to comment on the technology used in the Weiss."</i><br />

<br />

I don't recall this. I looked over my emails as well as found no evidence of this.

[jonmarsh]

I think everyone here needs to lighten up a bit, go to your corners, and chill out. <br />

<br />

I've known Charlie since the late 70's and he's one of the least self aggrandizing people I've ever met, especially ones involved in THIS business! I don't always see eye to eye with Charles (for example, I have a HUGE collection of 24/176.4) but then he's probably not aware of people like myself or Harald extracting DSD to high res LPCM from SACD's. No one knows everything, and I think it's too easy for some of us to forget that from time to time, when we should be willing to cut each other a little slack. Otherwise, things can get ugly quick. <br />

<br />

This site has some real nuggets of knowledge here and there, but some days the discussion veers off in directions that does little besides contributing to the noise floor. Maybe the temperatures outside are a little high this time of year, and the humidity less than ideal, but that's no excuse for not using a little restraint in posting. <br />

<br />

There's an old saying: "It's better to be silent and thought a fool, than to speak forth and remove all doubt". One could substitute other descriptors for "fool" with equal validity and applicability. <br />

<br />

/RANT OFF. <br />

<br />

<br />

<br />

Principle Engineer<br />

Infineon Technologies<br />

IFNA Corp. <br />

<br />

<br />

Principle Engineer <br />

AudioWorx Acoustic Consulting

[Andrew S.]

Dear Chris<br />

Perhaps the thread should be split.Discussion of your review of the Dac 202 might be separated from discussion of async and what it means.<br />

Rudeness is not warranted at all in any thread. And that applies to me as well.<br />

Regards<br />

Andrew

[AB835]

Chris earlier today you stated this.<br />

<br />

" I also encourage all manufacturers to read the review thoroughly and point out any technical inaccuracies."<br />

<br />

I would assume that "all" would include Charlie.

[The Computer Audiophile]

Hi AB835 - Actually no it doesn't include Charlie in this case. I wrote the previous statement replying to a <a href="http://www.computeraudiophile.com/content/Weiss-Engineering-DAC202-Review#comment-47848">question from Eloise</a> about sending my review to the component manufacturer before I publish it on the site.

[Charles Hansen]

>> I don't recall this. I looked over my emails as well as found no evidence of this. <<<br />

<br />

Chris, you're right, you didn't specifically ask me to comment. But you did start CC'ing me in a big e-mail thread discussing the technology. Why else would you send me copies of e-mails if you didn't want my input?<br />

<br />

Go see when the last time I made a posting to this forum. The only reason I've made any posts here recently was because you brought the entire matter to my attention. Like I said, I'm a busy guy and I generally don't post here. I'll be glad to refrain in the future.

[labjr]

Charles,<br />

<br />

I get a kick out of your posts even if they are sarcastic. There is actually some useful information in them too. I've learned quite a bit about about async transfer and DACs from you, Gordon and Daniel in this thread. More so than the BS comments and claims made by some other manufacturers. I'm glad you call them out on those claims too.<br />

<br />

20 years ago we only got to read brochures. The internet and these forums are a great resource. I see no problem with manufacturers joining the debate to set the record straight. Just like on a news show when they have a panel of experts. Otherwise we'd only be speculating amongst ourselves. <br />

<br />

I hope you'll continue to post here.<br />

<br />

Thanks

[The Computer Audiophile]

Hi Charlie - Gordon contact both of us after the review was published. I simply hit reply to all on the emails. I figured he wanted you involved in the conversation as well.

[Andrew S.]

@ Charles<br />

<br />

<i> And for my trouble, I am called names and denigrated. Believe me, I have better things to do than post here. Even with all of my "shameless promotion", I don't think we've seen an uptick in sales yet. So I'll be glad to let you all fight amongst yourselves and untie the Gordian knot of computer audio!<br />

<br />

<i> Like I said, I'm a busy guy and I generally don't post here. I'll be glad to refrain in the future.<br />

<br />

No need to be passive aggressive. I enjoy reading your posts but do not support you posting at the cost of a cart blanche licence.<br />

Ditto Gordon.<br />

<br />

FWIW I find Daniel Weiss's posts to be informative, on topic and respectful. I have no skin in this game - I am not concerned about the tech and which is "better". <br />

<br />

[labjr]

<i><br />

I am not concerned about the tech and which is "better".<br />

</i><br />

<br />

I am! <br />

<br />

I want the best possible sounding DAC and all the little pieces add up to a good sounding unit. Do you think it's an accident that some companies build great products or maybe they just happen to sound good? There's sound engineering involved. <br />

<br />

I want to know why they sound good. What I like about Charles is that he gets right to the point. He's obviously a very articulate writer and he's witty and a little sarcastic.

[Andrew S.]

<i>Do you think it's an accident that some companies build great products or maybe they just happen to sound good? <br />

<br />

You infer without context. At a minimum.<br />

<br />

My ears don't read tech explanations. I do not care how or why a company builds great product. I recognise you and many others on this forum are so interested. <br />

<br />

<i>What I like about Charles is that he gets right to the point<br />

<br />

More correctly he gets right to his point. Not <i>the point.<br />

<br />

<br />

[Lars]

That's right Andrew. Let's keep the place dull and without controversy.<br />

<br />

Charles, I see no reason why you would want to post here. Your time is better spent elsewhere. <br />

<br />

Steve<br />

<br />

[Audio_ELF]

<em>I want to know why they sound good. What I like about Charles is that he gets right to the point. He's obviously a very articulate writer and he's witty and a little sarcastic.</em><br />

Clearly some of that is true - I am not doubting that Charles "knows his stuff" ... but he has clearly disparaged another companies products and promoted his own in these posts.<br />

<br />

Post entitled <em><strong>"Arcam USB DAC"</strong><br />

>> $500 and Async USB. I just know someone can produce this stuff for this dollar amount. <<<br />

Yup. Just make it in China and use only op-amps instead of discrete circuitry.</em><br />

<br />

This was his first post in this thread. The inference can be made that made in China and op-amps bad. Charles later admitted he had no inside knowledge as to where the Arcam R-DAC was made (most Arcam products are built in the UK) and that he "Perhaps was thinking of Cambridge [Audio?]"<br />

<br />

Then posted ...<em><br />

>> Well that stinks [the Arcam only doing 24/96]. Seems like it's difficult for everyone to get beyond 24/96. It's gonna be forever too before there's a lot of 24/192 material to play. <<<br />

Our new DX-5 has a USB receiver board that will go up to 192 kHz (thanks, Gordon!). There are two problems:</em><br />

Eh? Who mentioned the Ayre DX-5 ... no one until Charles - this clearly breaks Chris' guidelines for manufacturers not promoting their own products unless asked a direct question!!<br />

<br />

And followed up with...<em><br />

>> Does quality really have anything to do with the cost of parts? or whether or not opamps are used? How much more can discrete circuits cost? <<<br />

Well, most people use cheap Chinese resistors that cost about 2/10 of a cent to buy. In the audio section of our DAC we use US-made resistors that cost about $0.30 to buy, a factor of 150x.<br />

I'd love to sell a DAC for $500. But I'm not going to use Chinese prison camps to do it. And I'm not going to cut corners with cheap parts.</em><br />

Again disparaging competitors products for (a) using cheep resistors and (b) building in China <strong>which the product in the review doesn't isn't</strong>.<br />

<br />

He then started on the CEntrance products with...<em><br />

>> Jitter Management - Debunking the Asynchronous Myth <<<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.)</em><br />

While there is possible arguments that the CEntrance (adaptive) code creates high jitter environment than StreamLength (async) code, Charles used very emotive terms like <em>silly</em> and <em>dog in the fight</em> and spreads rumors as if to disparage any thought that the CEntrance code could actually result in a good DAC so they are HAVING to change to async technology.<br />

<br />

Charles then went on defending his products<em><br />

>> Sircom should have pointed out more clearly that the Ayre does 'only' 24/96 and has only a USB digital input - these are two serious handicaps for those who would like to be more future-proof and be able to connect also CD players or other digital sources. <<<br />

Why should Sircom have pointed out non-issues?</em><br />

Erm ... maybe because for some people they are issues; part of reviewing a product is surely making it clear how it can and can't be used. Every car review comments on top speed, despite the fact that even the smallest, lowliest car sold can go quicker than the speedlimit of most countries. And isn't the fact that Charles is busy promoting the fact that his DAC and BluRay player will soon be able to do 24/192 means his company thinks 24/192 IS an issue!<br />

<br />

And the the piest de resistance...<em><br />

>> But I was under the impression that with Snow Leopard support had been extended/improved? <<<br />

FireWire could always operate at high sample rates because it used bulk mode and appeared to the computer hardware like a hard drive. It then required software drivers to allow it to record and play back audio.<br />

For USB it has been a slow progress. Leopard (10.5) was supposed to handle Class 2.0 Audio but turned out to have some problems. Then Snow Leopard (10.6) had working Class 2.0 Audio but was limited to 96 kHz and therefore offered no improvement over Class 1.0 Audio.<br />

Just a few days ago Apple released OS X version 10.6.4 which fixed USB Class 2.0 Audio so that it goes up to 192 kHz. We are shipping the new high speed USB receiver board in our DX-5 Blu-ray player now, and should be caught up enough to ship the QB-9 by next month. Other manufacturers will no doubt have other product soon also.</em><br />

So again in answering a question about Apple and Snow Leopard, he manages to get in comments promoting the features of his own products.<br />

<br />

So thats the "points" that Charles Hansen raised in this thread. None of which were on topic and several were disparaging (sometimes incorrectly or at least with doubtful accuracy) products and working practices that didn't relate to the product reviewed.<br />

<br />

Eloise

[Wavelength]

Daniel,<br />

<br />

<cite>Gordon, then how do you explain that we can sync our DAC202 to an external sync, e.g. wordsync on BNC, and have the computer playing a file tied to that sync? And we do not have sampling rate conversion involved?<br />

<br />

Well first off that would be good if you had a word clock input. But then again the problem is that the DICE chip does not take advantage of this.<br />

<br />

What you really need is some software feedback method for complete async implementation.<br />

<br />

In regards to PLL improving jitter... Daniel remember the audience here and more information is better.<br />

<br />

Gang a PLL can be used in many ways. One way is with a VCXO to re-create a cleaner clock from say a noisier or more jittery clock. The other way and the way in which the DICE and other Adaptive mode devices works is to create a reference clock as a frequency synthesizer. These clocks tend to be really poor and especially bad for audio work.<br />

<br />

That is why so many companies that live with this technology have to incorporate some kind of jitter reduction circuitry be it up/resampling or a secondary PLL/VCXO.<br />

<br />

But the basic question here Daniel is... do you have dual fixed oscillators that can be directly connected to the dac chip in a true asynchronous setup?<br />

<br />

4est,<br />

<br />

<cite>All I can say is BS theroretical speculation. You may be a competent digital engineer, but that is analog and it is fool hardy to make that claim. Especially as complex as jitter is and how it may be measured. I still do not see how the clock is created as making a difference. There has always been more than one way to skin a cat. Maybe, just maybe his PLL deals with jitter in a way you do not understand. I'll leave that to Weiss. Then again, maybe it is you who is trying to learn something here...<br />

<br />

I have a lot of testing equipment here and have done digital design since 1981. I would be happy to publish how bad PLL derived (frequency synthesizers) oscillation is. I could send you measurements from my Wavecrest analyzer which is good to 400fs.<br />

<br />

Gang!!!!!!<br />

<br />

I need a little help here. I really hate replying to stuff here without even knowing your first name. Can everyone here at least reply with their real names!!!!!<br />

<br />

Thanks<br />

Gordon

[cfmsp]

As stated previously in this thread, the use of “Asynchronous” on CA (referring to digital data transmission to DACs) has been conflated (perhaps confusingly so) to include use of fixed frequency crystal oscillators (FFCO) as a DAC’s local master clock as this approach/design has been noted as ideal for reducing intrinsic jitter to an absolute minimum by Gordon and others - including Bob Katz, from whom I first heard it - and has been implemented by BJ Buchalter (in Metric Halo devices since 2001). <br />

<br />

Asynchronous (meaning asynchronous to any upstream clock) is deemed the only transmission method capable of allowing use of FFCOs as a DAC”s master clock to the exclusion of (use of) PLLs, FFDs, etc, and it is likely for this reason that these ideas are 'conflated'.<br />

<br />

Note: this is not to say that good sounding DACS cannot be made which employ PLLs, and FFDs. The topic here is regarding the theoretically best design of a clock circuit that has the lowest possible intrinsic jitter, and that does not introduce jitter of its own (as can PLLs & FFDs). <br />

<br />

<br />

The claimed intrinsically lower jitter of fixed frequency crystal oscillators (note plural) - as compared to use of multiple PLLS and Fractional frequency dividers (the latter required when only a single crystal oscillator is used as the DAC’s clock) - is substantiated in work presented to AES in 2006 by product designers of just such a product (i.e., multiple PLLS, and FFD).<br />

<br />

<br />

Some excerpts:<br />

<br />

“Investigations on the clocking issues in a 1394 network are presented in [3] and [11]. The resulting jitter in the 1394 clock reference signal is calculated to 20 to 40 ns RMS and it is recommended by [11] to reduce this by at least 60 dB from 200 Hz and up.”<br />

<br />

This means that use of Firewire’s intrinsic clocking alone is NOT appropriate for high quality DAC performance. Given that the firewire master node IS synchronizing the slave node’s clock, I do not feel that this approach merits being called Asynchronous, in any event. I only mention this due to Daniel’s reporting of this mechanism upstream in this thread. It’s not clear if he is pointing to this as rational for referring to his DAC as being Asynchronous (i.e. not synchronized with any upstream clock signal, whether embedded in the signal or not), but it's the only comment I've seen that seems to even approach a legitimate claim of asynchronous behavior.<br />

<br />

<br />

Regarding the use of Fractional Frequency Dividers, which are required when one uses a single master clock - as opposed to use of fixed frequency oscillators (FFCOs) suggested by Gordon and others as being a key critical component of Asynchronous USB/Firewire, the AES paper has this to say:<br />

<br />

“Many varieties of all-digital frequency synthesizer are known. They can typically be regarded as fractional frequency dividers (FFDs). They divide a master clock by a value that is typically a fractional number. The edges of the output signal are justified to those of the master clock. In most FFDs the justification jitter contains strong discrete spectral components at beat frequencies. Such circuits are generally unsuitable for clock cleaning applications. Sigma -delta and other techniques can be used to smooth and shape the justification jitter spectrum [20], [21], and [24]…”<br />

<br />

The point being that FFDs introduce artifacts (not present in the original signal) that must be cleaned up, and therefore are to be avoided if one is looking for a circuit with the lowest intrinsic jitter. Said another way, FFDs are jitter increasing elements in a circuit.<br />

<br />

<br />

“A crystal oscillator is commonly known as being the best performing clock master solution for any type of audio converter.”<br />

<br />

That pretty much sums it up with regards to the ideal solution. To put this in better context, the designers presenting this paper are using (fixed frequency) crystal oscillators as the ‘reference’ standard for their measurements of intrinsic circuit jitter published therein. <br />

<br />

Regarding the measurement of a circuit’s intrinsic jitter, the AES paper has this to say:<br />

<br />

“The circuit's intrinsic jitter is the jitter at its output when an effectively jitter-free reference is applied to its input. The criteria for the resulting jitter of the ideal clock regeneration circuit can be jitter level and spectrum, […] It can also be the audibility of the jitter in the sampling clock for the mentioned converters.<br />

[…] In this paper we have chosen the level of which the jitter does not generate 0 to 20 kHz modulation noise above - 100 dB from full scale when converting a jitter wise difficult audio signal: 20 kHz full scale. We want the noise floor to remain clean while converting this signal through a high performance DAC. In music signals full scale 20 kHz components are rare so the requirement might seem tough.<br />

<br />

The target jitter level is specified below.<br />

• Baseband jitter (100 Hz to 40 kHz): Less than 50 ps RMS<br />

• Wideband jitter (100 Hz corner): Less than 500 ps RMS”<br />

<br />

<br />

In Table 1 “Jitter values, RMS, peak and peak-peak from different measurement systems” of the AES paper, the measurements of the designers comparisons of their own product and that of the crystal oscillator show a 40 to 50-fold increase in jitter over and above that of the crystal oscillator, for baseband jitter (as recorded by their Aeroflex equipment). Note: the product under test is referred to as on-chip VCO in the Table 1.<br />

<br />

Mind you, these are the measurements the product designers chose to prove the efficacy of their products jitter reducing capabilities, and they still come up well short of simply using crystal oscillators as the master clock.<br />

<br />

Also in reference to Table 1, we are asked to…<br />

<br />

“Note the spectrum of a crystal oscillator, which is commonly accepted as the least jittery clock source. Results in Table 1 seem to underline this.”<br />

<br />

Interestingly, and ironically, the designers also measure another product (of their own manufacture) which DOES use a crystal oscillator as Master.<br />

<br />

Comparison of measurements (as shown in Table 1) of the product under test and a previous generation product using crystal oscillator as master, showed a 5-fold increase in jitter in the product with new (multi-PLL/FFD) design.<br />

<br />

Regarding this previous product, the designers say:<br />

<br />

“System 6000 in clock master mode is using a crystal oscillator module. By comparing the crystal and System 6000 in clock master mode difference in this technology alone can be observed. System 6000 has approx. 10 times higher RMS jitter in “PWM” band and in the baseband [than the crystal oscillator alone]”<br />

<br />

<br />

So there you have it. The newly designed product with multiple PLLs and an FFD has significantly more intrinsic jitter than use of FFCOs as master clock (10 times more), and even more than that of FFCO implementation in the designers previous generation product.<br />

<br />

Why would this product design be presented as a success then? This answer also lies within the AES paper. Said simply, “lower cost”.<br />

<br />

<br />

clay<br />

<br />

<br />

<br />

[Lars]

Thanks for the informative post Clay. Or should I say Professor Clay.

[The Computer Audiophile]

<i>"The topic here is regarding the theoretically best design of a clock circuit that has the lowest possible intrinsic jitter, and that does not introduce jitter of<br />

its own (as can PLLs & FFDs)."</i><br />

<br />

Good point Clay.

[weiss2496]

Let me summarize some points I made and give some more information about the DAC202:<br />

<br />

- As for the async definition – in my (highend - audio) book a async DAC has a independent local clock to which the audio source is slaved. How that clock is generated is another issue and has nothing to do with the async concept. The DAC202 uses this concept of async clocking.<br />

<br />

- I agree that a crystal oscillator is potentially the best clock source in terms of jitter. Nothing new here. <br />

<br />

- Jitter matters in digital audio in three applications. A/D, D/A and Asynchronous Sampling Rate Converter (ASRC). I.e. the sampling clocks in A/D and D/A should be as jitter free as possible. In an ASRC the filter coefficients (a SRC basically is a large low pass filter) are calculated on the fly out of the ratio of output sampling rate / input sampling rate. If any of these rates fluctuate (jitter) the ratio jitters as well. In all other places jitter does not matter, e.g. it is pointless to say S/PDIF is a bad interface. S/PDIF is perfectly fine, it transmits the data and it transmits the necessary sync information. It is up to the receiver how to generate the sampling clock for a DAC out of that information. <br />

Clock signals without jitter are not possible to generate because of inherent noise sources, like transistors, resistors etc. So the goal is to have jitter figures as low as possible and/or with a benign frequency spectrum.<br />

Whether jitter is detrimental to the sonic quality depends on the nature of the jitter. Discrete jitter frequencies, i.e. when the sampling clock fluctuates in a periodic manner, in certain frequency regions, are the most detrimental. On the other hand a noise like jitter spectrum simply rises the Signal to Noise Ratio of the system to some extent, but otherwise does not have any detrimental effect. So if a jitter figure in picoseconds or nanoseconds is specified the next question would have to be how the spectrum of that jitter looks like. If it is a “noisy” spectrum then jitter figures can be much higher without any noticable effect. Noiselike jitter can even be used to cover up discrete jitter frequencies, a technique we use in our CD transport to “help” DACs with jitter problems. So jitter is not a bad thing per se – “it depends” as we engineers use to say.<br />

<br />

- Now for another can of worms: In the DAC202 we use a DAC chip which employs async sample rate conversion to reduce jitter effects. We did not chose that chip because of that feature though. We use it because it performs extremely well. The jitter reducing feature is a “nice to have” thing and the filter necessary for the sample rate conversion turns out to be of a quality which does not compromise the chip’s performance. I usually “shy away” from async sample rate conversion (despite I co-designed one in the early Eighties at Studer), but in that case the implementation has been done really well. <br />

<br />

I tell this to give a complete picture of the clocking concept in the DAC202. We have a JET-PLL based clock generator which is the master clock for the Firewire source. And a second, crystal oscillator based clock for driving the DAC chip at the output of the async sample rate converter (ASRC). <br />

The DAC2 unit, by the way, does not use an ASRC, its DAC is clocked off the JET-PLL. And still, it gets very good reports regarding sonic quality. Seems the JET-PLL isn’t that bad….<br />

<br />

Some recommended reading on jitter:<br />

<br />

http://www.jitter.de/english/eng_navfr.html<br />

<br />

http://www.grimmaudio.com/whitepapers/pll%20and%20clocking.pdf<br />

<br />

http://www.grimmaudio.com/whitepapers/PLL%20and%20clock%20basics.pdf<br />

<br />

http://www.grimmaudio.com/whitepapers/clock%20jitter%20spec.pdf<br />

<br />

Daniel<br />

<br />

<br />

[cfmsp]

<br />

Glad you enjoyed it Steve.<br />

<br />

The Professor here is Bob Stern, who pointed me to the paper.<br />

<br />

I'm just a reporter with an opinion, usually backed up by some substance somewhere, if I could only remember where. <br />

<br />

clay<br />

[labjr]

How important is jitter in the A/D compared to the D/A process? We never really know which equipment is used for mastering etc. It would be nice if there was an equipment list in the liner notes.

[cfmsp]

<br />

<br />

"We have a JET-PLL based clock generator which is the master clock for the Firewire source. And a second, crystal oscillator based clock for driving the DAC chip at the output of the async sample rate converter (ASRC)."<br />

<br />

Thanks for clarifying this point, Daniel.<br />

<br />

<br />

"As for the async definition – in my (highend - audio) book a async DAC has a independent local clock to which the audio source is slaved."<br />

<br />

I think we can all agree that we've discovered (in this thread) that there is no consistency as to the term Asynchronous (as it refers to DACs) amongst DAC manufacturers. I will say that my definition does not include what is commonly referred to as 'slaving', in the sense that this word (slaving) implies trying to keep two clocks in sync. Perhaps this is only semantically different.<br />

<br />

<br />

Keep up the great work! Despite that we are in disagreement as to what is the best design, my bet is with play money, and you are betting (your company on) the quality of your products, and doing quite well I might add.<br />

<br />

I will admit that three of the DAC manufacturers I admire most are yourself, Gordon Rankin and BJ Buchalter. <br />

<br />

There is a lesson here (that I need to learn and) that bears repeating - and which Gordon mentions in every third post - "enough with the armchair engineering, get out and listen to the DACs and choose based on how they sound to you". Chris does as well.<br />

<br />

That is precisely how I chose my first Metric Halo box - the ULN-2. I knew nothing of DAC design when I purchased it. <br />

<br />

cheers,<br />

clay<br />

<br />