Article: Weiss Engineering DAC202 Review

[Andrew S.]

@ Charles<br />

<br />

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

<br />

<I>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 />

<I>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 />

I don't know if what CEntrance say is silly or not. Nor do I care. I'm only really interested in what something sounds like. The tech is irrelevant to my ears.<br />

<br />

Having said that CEntrance have had some success licensing their tech to Benchmark, Bel Canto, Lavry and Bryston. I suggest their views should not be dismissed out of hand. There is usually more than one way to achieve a desired result. That is all I took the marketing quote to be.<br />

<br />

I don't think, with respect, that it matters who has a "dog in the fight". I may be naive but I wouldn't automatically assume a fatal prejudice by that condition precedent. <br />

<br />

<br />

Regards<br />

Andrew<br />

<br />

I apologize to Weiss for enabling OT discussion. Any publicity is good publicity I suppose

[Purite Audio]

Andrew S ,sorry your marketing has been far too subtle, what's the name of your dog?<br />

Keith.

[idiot_savant]

I stop reading CA for a couple of days, and there seems to be a thread I can contribute to!<br />

<br />

Right, so let's start by trying to establish the confusion of the term "Asynchronous", starting with firewire.<br />

In 1394/Firewire, there are precisely two means of transmitting a packet of data from one node to another: Asynchronous & Isochronous. Asynchronous packets are sent, and the node that sends it is guaranteed, by a series of retries and acknowledgements that the packet will be received by the other node, but there is no guarantee <strong>when</strong> the packet is received.<br />

Isochronous packets are not <strong>guaranteed</strong> to be received by the other node, but if they do get there, they are guaranteed to get there <strong>by a certain time</strong> - they can't be guaranteed to arrive, as if they fail to arrive, the retry would violate the guaranteed time of delivery. Note that since the packets are going over a dedicated bit of wire, all the packets should get there, but if, e.g. the wire is not properly connected, packet dropout may occur. <br />

Asynchronous packets are used when the bus is first configured - each node interrogates the other nodes to discover what they are, what they can do etc. This is why 1394 nodes must support asynchronous packets, as otherwise they cannot communicate at all!<br />

<br />

Isochronous is <strong>very</strong> similar between USB and firewire.<br />

<br />

So, in the MH case it sounds like: The Mac talks to the MH using asynchronous packets, enough to set up an isochronous channel to stream the audio over. Once the audio gets going ( using the isochronous channel ), the MH then communicates back to the Mac a flow control message using asynchronous packets, to ensure the buffer inside the MH doesn't underflow or overflow.<br />

<br />

Hence, it would appear that the MH operates in an equivalent of the USB Asynchronous mode.<br />

<br />

I've been looking into this a bit, and it would appear that this is <strong>not</strong> part of the 1394 audio standard, hence requiring drivers - I wonder if this is what the infamous dCS statement referred to?<br />

<br />

As for barrows assertion about the PWT/PWD is where I disagree, as he fails to mention how far away the critical DAC clock is being generated ( i.e. inside a separate box ). Common wisdom states that the DAC clock should be as close to the DAC chip as possible...<br />

<br />

And finally, the Centrance stuff is plainly marketing speak, and doesn't take account of the fact that not only is the USB frame extremely jittery, but it can be miles off in terms of absolute frequency as well ( +/- 1000ppm if I remember correctly ), which a PLL cannot do anything about<br />

<br />

<br />

your friendly neighbourhood idiot

[cfmsp]

<br />

Great to read you here again, and thanks for the most cogent explanation yet of Async Firewire implementations.<br />

<br />

As for dCS's comment - which I can no longer find anywhere - as I recall, their 'claim' was NOT simply that drivers need to be written. if I remember correctly they flat out stated that Firewire could not possibly do things that it could do well before Gordon 'discovered' Async USB. <br />

<br />

Perhaps I can't find it becuase it was removed?! If so, there's now an "app for that", called Evernote. If I'd been using Evernote, I could have clipped the offending material with one click, then it would have been placed in a repository (in some cloud somewhere) for textual query at a later time.<br />

<br />

highly recommended!<br />

<br />

clay<br />

<br />

[cfmsp]

<br />

<br />

The Centrance DACport might be interesting, due to form factor alone, but for purposes of highest quality sound possible, Centrance is off my radar.<br />

<br />

As for the number of folks licensing their technology, I think of these as the "me too" implementations, or rather, those adding USB quickly to an existing product to meet perceived demand, rather than deploy an all out best of class USB implementation (a la GOrdon, Charlie, dCS, etc.).<br />

<br />

interestingly, Paul McGowan claimed at the release of the PS Audio PWD that they had finally acquired a USB solution (i.e. Centrance), and that it is "as good as it gets" (as posted on his forum about one year ago).<br />

<br />

So, at least some people believe that the Centrance code is of high quality. <br />

<br />

cheers mate.<br />

<br />

clay<br />

<br />

PS, I finally got the Devore 9s. <br />

<br />

<br />

<br />

[barrows]

"As for barrows assertion about the PWT/PWD is where I disagree, as he fails to mention how far away the critical DAC clock is being generated ( i.e. inside a separate box ). Common wisdom states that the DAC clock should be as close to the DAC chip as possible..."<br />

<br />

Absolutely yes, the distance of the clock in the PWT from the PWD makes for a very slight increase in jitter, but, this increase is much smaller (by a magnitude) than the increase in jitter if the two are connected by SPDIF, and an SPDIF receiver/PLL circuit must be used (or an SPDIF connection to any DAC). Of course this distance "problem" also effects external clocking of any kind, say an (expensive) external high precision atomic based clock that some posters here sometimes laud the benefits of...<br />

<br />

In any case, the PWT-PWD combo, connected by I2S, produces excellent sound, and very low measured jitter levels, and is asyncronous. Beyond that, I expect the best performance of the PWD will be realised with the Network Bridge; when used this way, the fixed oscillators (running asyncronously) will be mere centimeters from the DAC chip.

[chrille]

I may not be techie minded, but yes I already did that repeatedly !<br />

And I still get the e-mails!

[The Computer Audiophile]

Chrille - Please look at the attachment here. It appears that you are still subscribed to this thread. Did you un-check this thread previously?

[Charles Hansen]

>> do not forget that this hyper competitive production environment is largely originated by companies from the West. <<<br />

<br />

FoxConn is a Taiwanese owned and managed company. Apparently there is a fair amount of racism, where the Taiwanese manager treat the mainland Chinese employees very badly.<br />

<br />

>> Surely Steve Jobs must at least know a little about the Foxxcomm modus operandi. But what did he do after the outbreak of bad publicity, he defended them, and you wonder why? Where else would they churn out those cheap and excellent iphones/iPads? Those cheap products has to come from somewhere. <<<br />

<br />

Of course Steve Jobs knows all about the problems. But all he cares about is money. Which is why I avoid buying Chinese products, even when they say "Apple" on the box.<br />

<br />

But things are changing. They gave the FoxConn employees a 70% raise! What does that say about how they used to treat their employees. But even more important, the artificially devalued Yuan is now going to be allowed to float. We will see huge increases in the price of Chinese goods, as well as all kinds of other problems. (The US owes China close to a trillion dollars and this debt is going to double.)<br />

<br />

>> In terms of environmental issues we are much worse than we think when it comes to treating the third world. <<<br />

<br />

Yep. We are selling cigarettes to the third world as fast as we can make them. DDT as well. Anything that is banned here, we just sell overseas.

[Andrew S.]

@ Clay - well done: I am sure that they will be the last speaker you buy for a quite some time. I am green with envy. Now to get you over to tubes:) at least as a second option. I picked up a Jadis Orchestra Ref recently to add to the collection and can readily endorse it (once it has been tube rolled to eg Penta KT88SC, EH 12ax7 and properly biased - this is a bear).<br />

<br />

Re CEntrance. I agree of course entirely. I no more champion their product than candyfloss. The Dacport is a handy little unit which sounds very good. As Charlie H said (at some point)everything is built to a price point and you gets what you pays for. I wasn't actually quoting CEntrance to endorse it's POV. Rather I posted the excerpt for discussion purposes only. It is clearly marketing and should be read that way. They are a respected OEM for many audio companies (eg the Bryston BDA1 on the CASH list) re jitter so should be accorded some credit. <br />

<br />

@Idiot Savant: thanks for a clear concise and pleasant post. You obviously work in the field or otherwise have a relevant knowledge set. Thank you for sharing. <br />

<br />

@Coops - no dog no name. I couldn't care less about the tech. When I'm listening all that matters to me is how a product sounds and if I like the sonic signature of it. I leave it to the da engineers to worry about which is "best". <br />

<br />

Re Chinese prison camps. That was a really unfortunate post by Charles. I don't doubt working conditions in some Chinese factories are awful by our standards. As are some of their environmental practices. <br />

I am sure none of us need reminding that we are all responsible for working conditions in developing countries by our daily consumption, either directly or indirectly. The drive for globalization (which really means the drive for lower costs of production principally by paying workers less in 3rd world countries and not having to comply with costly environmental and OHS mandates) was driven by the West in particular the USA. <br />

You cannot have have the benefit without the burden. The Foxconn's of the world exist to service our appetites for cheap goods and, of course, for profit. One of the beauty's of contracting out production, much like the infamous rendition policies of the Bush Administration, is the denial-ability that comes with it. Of course distancing doesn't remove the culpability.<br />

<br />

I applaud Charles' stance on manufacturing and would happily pay a premium for it. But the sad fact is in everyone's daily life in the West we support the "prison camps" just as much as if we were part and parcel of the management that drives them.<br />

<br />

No easy answer. The best we can hope for is I submit is that media focus threatens profits and forces CEO's to actually improve conditions. <br />

<br />

Just my 2 Cents. Of course I could be completely wrong.

[chrille]

I think I have managed to unsubscribe properly now.<br />

While online I have a question regarding the latest version of Snow Leopard on my Macbook Pro.<br />

<br />

Do you know if it will be possible to play higher sampling rates than 24/96 other than Firewire connection with this version,or not?

[Audio_ELF]

SnowLeopard will do 24/192 and 24/176.4 on any device which supports it... This is generally limited to FireWire; USB devices such as the M2Tech Fireface and on MacPro PCIe cards such as Lynx AES16e. The new MacMini will do 24/192 via HDMI too. <br />

<br />

The built in optical connection doesnt support these sample rates. <br />

<br />

Eloise<br />

<br />

[labjr]

I know Apple doesn't reveal much before they release a product but has anyone heard any rumors about when they will be including Light Peak in their products?<br />

<br />

[Audio_ELF]

I guess we'll have to wait for Intel to build chipsets supporting Light Peak first...

[tresaino]

For what it's worth: both the Ayre QB-9 and the Weiss DAC2 (i.e. not the new INT202) got very good reviews in the current HifiPlus. Alan Sircom reviewed the Ayre and Ed Selley the Weiss, different styles, would have liked the same reviewer comparing both and on the basis of similar considerations. Oh well..<br />

<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. Sorry Charlie I respect your company (and your past, still happy with my old Avalon Radians!) and agree 100% with your remarks about Chinese labour conditions, but these two omissions put your DAC off my radar screen and I ended up, happily, with the Weiss DAC2, sounds terrific and has all the digital inputs I need. I'm convinced yours is a great sounding DAC but these limitations will put many people off.

[Wavelength]

Gang,<br />

<br />

Ok here is the basis for any digital asynchronous setup.<br />

<br />

The design should put dual master clocks (one for 44.1/88.2/176.4 and one for 48/96/192) as close to the dac chip(s) as possible. The selected master clock will then be routed to the the parallel to audio serial link to create the I2S, LR Justified, DSP whatever link to the dac chip(s). To assure the computer link does not underrun or overrun the implementation has to have some kind of feedback pipe or flow control to assure the non-interruption of data to the dac chip(s).<br />

<br />

Gang... yes 10.6.4 does totally allow Class 2 USB audio. Apple has tested up to 16 channels at 24/192. Therefore... yes the ceiling is lifted and the fun begins.<br />

<br />

Thanks<br />

Gordon

[4est]

Why are two clocks required?

[labjr]

<i><br />

"Why are two clocks required?"<br />

</i><br />

<br />

So the clocks will be integer multiples of the two sets of sampling frequencies. Using one would cause more jitter.

[labjr]

<i><br />

"I guess we'll have to wait for Intel to build chipsets supporting Light Peak first..."<br />

<br />

</i><br />

<br />

I thought this was already in progress and due out by the end of the year. Maybe not.<br />

<br />

I imagine Light Peak will be ideal for Computer Audio.

[4est]

Earlier in this thread:<br />

<br />

"Async<br />

<br />

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"

[JR_Audio]

There is only one 25 MHz Crystal Oscillator one the XTL1 / XTL2 Pins of the DICE chip, and this frequency is not correlated to any audio sample rate, so the fractional divider in the JetPLL does create the appropriate Master Clocks for the audio signals.<br />

<br />

Juergen

[barrows]

"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 Weiss' point of view, as expressed here, is not shared by all digital engineers. Technically, a fixed frequency oscillator will produced a lower level of jitter, than a PLL generating a clock frequency from a single oscillator reference frequency. Daniel Weiss feels that the PLL approach is adequate, some other designers (like Gordon Rankin, Charles Hansen) disagree.<br />

Technically, no PLL is perfect, and employing a PLL will always add some jitter (to the inherent level of the reference oscillator). Some will suggest that the jitter is low enough with the PLL approach, others will suggest that lower jitter (or they may point to specific types of jitter) is always going to sound better. So we have different points of view regarding design approaches.

[Charles Hansen]

>> 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 />

<br />

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

<br />

There are barely a handful of digital files above 96 kHz. And for anyone who cares about all twelve "high res" files, next month we will introduce a new USB receiver board that works at 192 kHz. It requires that your operating system will handle it. Apple just released an update to Snow Leopard that handles 192. Windows won't for the foreseeable future, so one would need to install a custom USB driver that we will offer on our website.<br />

<br />

As far as connecting CD players, why in the world would you want to connect a CD player? You already have a CD drive built into your computer. Almost all music player programs offer the choice of ripping it to the disc or playing right off the drive in real time.

[BobH]

any other Dac manufacturers who would like to join in? It's a great shame that this thread has been allowed to become little more than free advertising for competing manufacturers.<br />

<br />

May I suggest that future reviews do not allow comments. Let people raise a separate thread if they wish to comment on a review. That way the collection of reviews will become a valuable, and still readable, resource. Rather than the repository for bitching, sniping and counter-advertising that they seem, unfortunately, to be turning into. IMHO.

[Moses]

Bob, I think I understand your annoyance, but really overall this for me has been a fascinating and illuminating thread. Surely I can't be the only person who understands 'asynchronous' a lot better because of it. The people who've weighed in have generally been raising very substantive points, IMHO.<br />

John