New Dichotomy - Async vs. Non-async DACs

[Audio_ELF]

Gordon said "Ethernet is capable but really at 10/100 speeds it is limited due to the turnaround and the heavy load by IP protocol especially when you consider data grams and the stacks. But it is capable of doing audio well. I am just not sure why none of these audio companies have written a driver to make their Ethernet look like a dac??? instead they have these applications specific for their dac???

Do you really believe with the issues of QoS and the fact that within a switch packets can easily be delayed and then at the far end each packet would need reconstituting into the correct order, checksummed, requested and resent when missing or corrupted, etc. that there is a real benefit of creating a true IP / Ethernet connected DAC? What benefits would it have over USB/FireWire or a streaming device?

 

Eloise

 

[CharlyD]

Hi Eloise - In response to your points:

• Agreed - Squeezebox is a networked audio device. I believe that audio processing (the codec) takes place at either the SqueezeCenter server or the target SB. I'm not sure what format is used to transfer the content over the network if the Squeezecenter is decoding.
  
• UPnP/DLNA requires that the system support transfer of audio content in LPCM. Several other formats are optional. Decoding of content may take place at either the server or the rendering device.
  
• While TCP/IP is a packet protocol, audio content may be streamed through a handshake mechanism very similar to asychronous USB. There is no persistent storage of the streamed content.

Nearly all the DACs we discuss here have an embedded and very specialized computer built in. The asychronous USB DACs we're all so fond of execute code to handle that protocol. This computer is just a part of the transmission chain from the player/codec to the DAC. You are correct that most network DACs include the necessary codecs to convert encoded (MP3, WAV, FLAC, etc.) content streamed from the server. Once again, all UPnP/DLNA servers can stream LPCM (unencoded) audio.

 

[Happy]

 

Ethernet has no real QoS issues. It was a problem several years ago - not any more. I hold several patents in the solution to QoS (and packet inspection - queuing theory in switches) over Ethernet both in local and wide area networks.

 

The Ethernet switch (not router) is a full non blocking switch (this is why Ethernet will ultimately replace fibre channel in storage networks). The Ethernet switch cost is one reason why Ethernet so dominated comms over the last 20 years.

 

The benefit of Ethernet is cost, distance, reliability and standards. Speed is also pretty good. GigE is inexpensive, 10GigE is not bad. Clearly it is not used like USB - which was designed to attach peripherals to computers.

 

Most of the music in my home is distributed and played back via Ethernet. My NFS server is connected via Ethernet; My home security system is Ethernet based. My home lighting system is Ethernet.

 

The downside in a device like a DAC is the operation of the stack. Essentially you need a compute device, however small, to terminate the stack. Then one is mixing compute with analogue - arguably inevitably in a DAC device.

 

Having said this most home devices PS3, Sonos, Xbox, TV's have Ethernet interfaces. The cost of putting an Ethernet interface into a device is of the order of $10.

 

/Paul

 

[cfmsp]

 

"A fixed digital audio based oscillator will always out perform an oscillator that is moving to match some incoming stream.

 

In it self any oscillator that is moving is adding jitter to the system that it is working on and that is not good."

 

Gordon,

the Weiss units (Minerva/DAC2) claim to use a PLL for jitter reduction, stating that "JET PLL uses feedback to lock an oscillator to a timing reference".

 

This seems incongruent to your point above.

 

I wouldn't think you'd use a PLL for an async Firewire communications.

Perhaps the PLL is only used for non Firewire inputs?

 

clay

 

 

[barrows]

I believe the dual PLL used in the Weiss gear is only used to reduce jitter on the SPDIF inputs, and not for the Firewire interface. I forget where I read this though. This question should really be addressed to Daniel Weiss rather than Gordon. Daniel is pretty responsive to direct inquiries through the Weiss website.

 

[cfmsp]

 

Barrows,

Thanks for the response, and good point re Daniel.

 

I thought it was probably confusion on my part, which is why the post was addressed to Gordon. I edited it after the original posting, and lost sight of the target.

 

cheers,

clay

 

 

[idiot_savant]

Right, I think I may have a shot at this.

 

Please excuse me for joining in late, but, if I may, I'd like to trawl through the thread from the start, so probably won't cover everything in one go.

 

Firstly, jitter measurements, and asynchronous protocols:

The Miller Jitter Analyser ( the tool John Atkinson/Stereophile use to get the "numerical" jitter number ) is broken for current products. Firstly, let us go through how the test is meant to work, as defined by the late Julian Dunn - it is, incidentally, a very well thought out test signal, as will become apparent. The theory is this - to separate quantization noise from the equation, we use a tone that is precisely 11.025kHz. The clever thing about this is that you have 4 samples per cycle, which are exactly + full scale, 0 , -full scale, 0 - it doesn't matter how many bits you represent this with as the source, the DAC must be able to reproduce this. Onto this, you add a signal, which is typically the smallest squarewave you can reproduce, and for historical reasons, this means the LSB toggles at 229Hz to try and excite data related jitter, and normally LSB for this test is the 16th bit.

You then FFT ( or take a spectrum ) of the output of the DAC reproducing this tone. A perfect DAC will have an infinitely narrow enormous spike at 11.025kHz, with harmonics from the squarewave starting at 229Hz at 96dB down, and repeating at odd multiples of this, decreasing with frequency - so, one at 687Hz, one at 1145Hz and so on. The idea is that jitter will generate sidebands equidistant around the tone at 11.025k, and you look for these, weight them in some way, and this gives you the "jitter number".

There are three problems with this approach. Firstly, the equipment doing the measurements will be the limiting factor ( as the sidebands will likely be small for good gear ) - The Miller test uses a 16 bit ADC. Secondly, the effect of low frequency jitter is to widen the fundamental 11k tone - so all the jitter components get "stuck together" as far as the measurement is concerned to give falsely low measurements.

The third problem is that if you have a DAC that is more noisy than jittery ( for example, the Wavelength ones ), there is too much noise to find the sidebands. In this case, the Miller analyzer will return a figure of 0ps, which I'm pretty sure Gordon will say is not the true measurement....

 

So, I'd prefer people to look at the jitter graph than a number, as the Miller number you cannot take on it's own.

 

As for async vs adaptive, currently there are only three companies offering async using native drivers, and all three seem to get very good jitter measurements. As I have said before, async offers the opportunity to eliminate interface jitter - i.e. you could have a super async protocol, but synthesize the DAC clock with something sub-optimal, jitter performance will be poor. It really doesn't matter as to how the async mode is done ( i.e. USB,firewire,ethernet,clock back), but for an interface where there is no drawback for doing it properly ( namely USB and ethernet ) apart from effort from the manufacturer, then I would be tempted to go with the manufacturer who has put in the effort - it is unusual in engineering, in that there are quite a few positives for the end user ( lower jitter with data integrity ) and limited negatives for the manufacturer ( extra effort, but support in terms of standards )

EDIT

NB the other aysnc modes can be equally good, but have drawbacks - firewire needs drivers, and the DAC in master often needs hoops to go through changing sample rates etc.

 

Returning to the "legacy" DAC manufacturers mentioned in the first post, I think it is interesting how many of them choose to add USB inputs to their DACs via use of an off-the-shelf-chip that basically turns new-fangled-USB into SPDIF that they already have architecture to support...

 

your friendly neighbourhood idiot

 

 

[Happy]

Very well put!

 

[cfmsp]

 

yes, well put,

and welcome back, I was hoping you would be lured back to respond.

 

clay

 

 

[idiot_savant]

Returning to the original thread subject for a moment, and the possibility of a dichotomy - I can't see it. The whole "async" thing is sufficiently diffuse ( i.e. USB,firewire,ethernet competing), and the market is in such as state of flux. Additionally, you have, e.g. the November issue of stereophile having an "advertisement" where some technical untruths are freely published, just to muddy the waters ( John Siau, I'm looking at you )

EDIT

it occurs to me that naming John Siau may upset the legal representatives of this site. However, he is freely publishing ( in fact paying for ) an article in Stereophile, in which he states some factual inaccuracies, which I'm sure Gordon, or Charles, or the guys at dcs would confirm.

 

I'd like to see a real dichotomy where the innovators in the field leapt forwards, so the manufacturers who put in the R&D effort to make things genuinely ( and measurably ) better got their rewards at the expense of the manufacturers who change a chip and gain tick marks in the brochure....

 

I live in hope,

 

your friendly neighbourhood idiot

 

EDIT

thanks clay,

I've been, um, saving some small, cuddly animals or something...

 

[cfmsp]

 

"I'd like to see a real dichotomy where the innovators in the field leapt forwards, so the manufacturers who put in the R&D effort to make things genuinely ( and measurably ) better got their rewards at the expense of the manufacturers who change a chip and gain tick marks in the brochure...."

 

well then, maybe we just need more kindling!

 

hang around, perhaps we should turn the heat up a bit on those who just add the Centrance code & a USB port to their DAC and claim that it's pretty much "as good as it gets" (as Paul McGowan did).

 

good to hear you were serving a worthy cause in your absence.

 

clay

 

 

 

[The Computer Audiophile]

It would be productive to at least mention the so-called technical inaccuracies published by John S. That way everyone can evaluate the statements themselves and decide whether the above statement is an opinion, fact, or both. I don't recall what was said in print. If anyone can help us out here I would appreciate it.

 

[idiot_savant]

I don't want to be someone who just goes "bah, they're wrong".

 

If you can see anything wrong with what I'm saying, feel free to cut this post/previous post.....

 

It's all in the "sponsored" section, and an "interview with John Siau"

 

Firstly, and this is pedantic... "Q: How did you develop the 24-bit data path?" "JS: We designed custom software for the TAS1020B USB interface" - which was designed by centrance

 

Secondly, and the point I really want to raise:

"Q: What about asynchronous USB inputs for high bit rate files?"

"JS: Asynchronous USB DACs tend to trigger OS-based sample rate conversion. The user must be careful to set the DAC sample rate to match that of the file being played ( or the OS will step in and and trash the audio quality). In contrast, the frequency-agile DAC allows instantaneous changes to the sample rate so that a playlist can have a muixture of 44.1,88.2 and 96khz files without the risk of OS based SRC"

 

I would contend OSX and Vista don't care whether the DAC is adaptive or async for this case...

 

your friendly neighbourhood idiot

 

 

[cfmsp]

Classic marketing crap

 

clay

 

 

 

[barrows]

In defense of PS Audio, at the time, the Centrance code was the best thing available, and do not think for a minute that it was easy for PS Audio to provide it. Because PS Audio always viewed the best computer audio solution to be a network player, they did not feel the USB connection warranted investing additional engineering time that could be applied to the (considerably difficult and involved) process of developing a high performance network interface.

In further defense of PS Audio, the development of the PerfectWave Transport was a huge engineering project, taking over a year of time between PS Audio's engineering team and their consulting partners, resulting in a new paradigm in disc transports, and the first dedicated disc transport to be able to play high resolution wav files in their native state, and deliver that data stream the partnering PerfectWave DAC via I2S.

Additional kudos go to Gordon Rankin, whose development of the Async USB code was apparently a labor of love; if his reports of how much development went into the Streamlength code are accurate, I doubt he will ever be rewarded financially for this work relative to how a software developer for a computer game or other more marketable software would be.

It is easy to sit on the sidelines and criticize audio companies for not providing exactly the product we want, or for outlandish claims regarding performance, but it is important to realize that these are very small companies, with limited resources, doing what they do because they love music, and desire to improve the music playback experience for everyone.

 

[bordin]

Recently, I just discovered that the Minerva didn't lock on the S/PDIF input. The relay kept toggling on and off.

 

It happened only when using one of the coaxial cables, feeding the S/PDIF signal from my Metric Halo ULN-2.

 

I'm not sure this is with the dual PLL of the Minerva.

 

Regarding async v.s. sync operation, an engineer friend of mine said it would be better to describe the dichotomy as a single clock v.s. multiple-clock source.

 

BTW, a Wavelenght DAC will be "landed" next week. :-) Hearing is believing !!

 

[idiot_savant]

I agree that small companies with limited resources must target those resources, because there is no way to make a box that will be perfect for everyone.

I do object to the outlandish claims for performance, and I also object to people stating outright lies (hence my objection to the benchmark stuff in stereophile). PS Audio are by no means the worst for this, but they do make some ridiculous claims as well.

I've said it before, and I'll say it again: In what other industry would the manufacturer be able to make such outrageous claims on things that can be measured? I have absolutely no problem with, e.g. PS Audio saying "we use I2S because we think it sounds the best", but when they say "we use I2S because it is the lowest possible jitter ( only 2ps )" and the measurements in Hifi News prove this to be wrong, nobody seems to care?

If you bought a car because it claimed to do 0-60 in under 4 seconds, yet took 11, you wouldn't just shrug your shoulders and admire the upholstery, would you?

 

I'm sure the benchmark and the PS audio stuff sounds great, so why do they feel the need to just make stuff up? I'm really not trying to pick on any companies here, it just depresses me the state the industry in general,

 

your friendly neighbourhood idiot

 

[cfmsp]

 

"Regarding async v.s. sync operation, an engineer friend of mine said it would be better to describe the dichotomy as a single clock v.s. multiple-clock source."

 

Bordin,

 

That's true, and Gordon described it differently as well.

 

But I tend to agree that use of a high quality 'single' clock in the DAC is the key design concept.

 

As they say, the man with two clocks never *really* knows what time it is.

 

clay

 

 

 

[Happy]

Not strictly true - you can operate async and sync with only one clock source - the difference is that async is bit/byte delivery with no clock source (requires flow control), sync requires a clock source (implicitly or explicitly).

 

It is true however that you can deliver files using sync (this is how TDM netwtorks work) and interestingly you can deliver sync and async files using async technologies (this is how ATM works - and, by extension the internet).

 

I can see the your friends point; in my system there are 3 clocks - the Lynx internal clock - the DA reclocker and ultimately the Alpha DAC. In another thread the BADA people state that they don't really rely on external clocks and they regenerate the samples/clock internally - in an open loop system this works great - the only real technical problem is long term (minutes) loss of samples (a couple) as buffers exhaust - not a problem in audiophile stuff.

 

Ultimately the DAC will clock out samples at 44.1Khz as long as the 'samples are there' and 'that' clock is accurate/stable the delivery method to the DAC is irrelevant.

 

As I said in a previous post the internals of the DAC details are important: - noise, psu, DAC conversion technique, up(over)sampling choices. I can just here DAC manufacturers complaining amongst themselves that the community is focussing on the wrong things - bit like buying a car because it is red/blue/green - people will, but in the end it just doesn't matter. (Costs aside).

 

/Paul

 

[barrows]

I do share some of your feelings re audio companies and the use of Hyperbole in marketing. i am not sure what Benchmark is talking about in the ad you quoted, and it is a little worrisome when stuff like that is stated as incontrovertible fact.

 

"I've said it before, and I'll say it again: In what other industry would the manufacturer be able to make such outrageous claims on things that can be measured? I have absolutely no problem with, e.g. PS Audio saying "we use I2S because we think it sounds the best", but when they say "we use I2S because it is the lowest possible jitter ( only 2ps )" and the measurements in Hifi News prove this to be wrong, nobody seems to care?

If you bought a car because it claimed to do 0-60 in under 4 seconds, yet took 11, you wouldn't just shrug your shoulders and admire the upholstery, would you?"

 

I can tell you this because I was formerly employed by PS Audio, and I was involved in the development process of the PerfectWave DAC and Transport: I2S was definitely used because it provided the lowest possible jitter connection between the Transport and DAC, and by using I2S the listener can bypass the ASRC (as it is not needed for jitter reduction). Bypassing the ASRC sounds better, apparently because the resampling process introduces some kind of distortions (conjecture) better sound is easily confirmed through listening. The SPDIF/AES connection does result in higher jitter than the I2S connection when the PWD is run in "Native" mode (bypassing the ASRC). If one engages the ASRC when using the SPDIF/AES connection the measurable jitter drops to very low levels, but the sound is definitely compromised.

Unfortunately, HiFi News tested pre-production samples of these products that definitely had some problems. Hopefully, someone will publish tests of fully operational production units soon.

I do agree that the "2pS" stated above (not sure where you got this quote, but I will believe it's accurate for the sake of discussion) is unfortunate: the language of the statement does not precisely state what this number refers to, although it is easy to infer that it refers to the total jitter level present as noise at the analog outputs of the DAC, obviously this is not the case. I suspect that PMcG was actually referring just to the jitter introduced by the cable carrying the I2S clock signals, perhaps? In any case, I agree that the "2pS" stated above is somewhat misleading.

What I can say directly, is that PS Audio did use the I2S connection specifically because it offers the lowest possible jitter, and that any statements to that effect are true.

I just wanted to stand up here for a manufacturer, because it is really easy for people on the sidelines to criticize how products are developed, and marketed-but there are not many people on the sidelines who really understand how difficult the development of these products are for small companies. Additionally, companies are constantly badgered by consumers and armchair engineers demanding all kinds of different features, and explanations of why they built a certain product a certain way. Having been personally in the position of having to directly respond to all kinds of consumer, and reviewer, comments and observations for an audio company, I certainly can understand how easy it is to make statements that are not entirely clear, and how such statements could easily be interpreted as inaccurate, or even intentionally misleading, when every attempt was made to give accurate information.

 

 

[cfmsp]

 

Paul,

 

Your point is actually reinforcing Bordins, IMO.

 

I believe that his engineers friend's comment about the dichotomy having more to do with configuration of clocks IS actually the better way to describe the issue. We tend to use Async versus non-Async language to describe it, which as you've articulated above may no be precisely correct.

 

For my part, I purchased my ULN-2 before hearing about async usb. One of the Metric Halo design principles (which I was attracted to) is the ability to clock incoming data with it's high quality clock, as espoused by Bob Katz and others.

 

As Barry Diament said in a separate thread today - it sounds so good that I don't really care how it does it. Presumably one factor (of many, as you point out) is its clocking.

 

As for the DAC manufacturers, they will surely complain when customers are interested in aspects which they do not incorporate in their own work. Since the majority of the industry is NOT currently using single-clock / async / whatever-you-wan-to-call-it in their DAC design, I'm not surprised that they are complaining. They might be better advised to work to improve their own products, esp. if - as the early returns seem to indicate - the new approach is a significant improvement (i.e., Gordon's USB approach versus Centrance that the 'me too' folks are implementing).

 

Yes, implementation is everything, but, when an innovation comes around, the older tried and true methods may no longer be capable of equivalent results in the implementation. I'm not saying that we're there yet, but, if Gordon's approach does turn out to be a new wave, things will get very interesting.

 

just my two cents,

clay

 

PS, I appreciate the perspective you bring as a DAC designer, without a product to sell. That's quite useful here, IMO.

 

 

 

 

 

 

 

[cfmsp]

 

Barrows,

 

"I do agree that the "2pS" stated above (not sure where you got this quote, but I will believe it's accurate for the sake of discussion) is unfortunate"

 

As I recall, this number was quoted by Paul as the specific amount jitter per the manufacturer's spec in the (don't laugh) Asynchronous clock in the transport, which the further suggestion that this was the only jitter in the system. But I don't have time to google and find the comment, and my memory is certainly not infallible on these things.

 

I'm fairly certain it was NOT a measured number, yet it was still being quoted.

 

just trying to help here, if not, please disregard.

 

clay

 

 

 

 

 

[barrows]

that certainly sounds plausible. ~2 pS as the jitter spec for the clock in the PerfectWave Transport as stated by the manufacturer of that XO. The spec for intrinsic clock jitter will probably not be met when actually implemented in a product, as the spec is produced in a laboratory environment under ideal conditions (perfect, voltage regulated, no noise DC lab supply, perfect temperature control, no RF interference, etc.). At the I2S output of the PerfectWave Transport, the actual jitter should be very close to that of the intrinsic clock jitter, as implemented in the product, and a lot of effort was spent to implement the clock and the I2S output as well as possible. There will always be some added jitter along the way to the transport, losses in the cable and the I2S sender and receiver circuits-this is one of the reasons why the HDMI cable for I2S matters.

In any case, the point is that PMcG was not actually referring to the jitter (as measured noise) at the analog output of the PerfectWave DAC, and that he could have been a lot more precise in how he stated this so that what he said would not have been misinterpreted.

 

[idiot_savant]

have been stated here many times, so I think we'll have to agree to disagree on the subject. I have said that choosing HDMI cabling was a smart move on the part of PSAudio, but I would maintain that SPDIF done properly is better.

 

Out of interest, when you bypass the ASRC ( again, my views on ASRC being evil has been stated before ), does the audio still go through the Wolfson filters?

 

It would appear that lots of people selling the PWT/PWD include the words "jitter free", but credit to PSAudio, they seem to quote "very low jitter", which, again I have no qualms with.

 

I don't set out to bash companies, or products, but merely try to give some insight as to what some of the psuedo-technical marketing stuff means - to be honest, my next irritation is with a British DAC about to hit the market, that I couldn't possibly Name - if a man with 2 clocks doesn't know the time, how about the man with 10?

 

your friendly neighbourhood idiot

 

[barrows]

I appreciate your posts here as you seem quite knowledgeable. I just wanted to provide some insight on how difficult it can be for manufacturers, who in my experience, really are working really hard to provide good products, and make their solutions understandable.

I disagree with you re SPDIF-it is flawed as an interface IMO because it requires the use of multiple clocks and PLLs and digital receivers/transmitters to embed and then strip out the clock data. I know you feel differently.

The PerfectWave DAC has an TI ASRC chip, and the Wolfson DAC. The filters used when the ASRC is not resampling ("Native" mode) are incorporated in the Wolfson DAC chip, and are user selectable. It is quite easy to experience the sonic improvement when in "Native" mode with the PWD, as this is user changeable. It is also important to understand that the DAC itself (and its filters) are still running at a higher sample rate in "Native" mode, so the filters are applied to "oversampled" data, the oversampling is just the direct integer oversampling of the DAC chip itself, rather than the asynchronous resampling done by the ASRC chip.

Yeah, I know which UK product you are talking about. I have not bothered to read their white paper yet, but off the top of my head it is hard to understand how 10 separate clocks could be a good thing!