To Reclock or Not to Reclock ...

[ziggyzack]

This stuff all came about because, long story short, people were plugging macs and pcs into dacs using the USB port and using the computer's crummy clock to time the audio signal. So the audio was mangled, but the timing of the data coming over the USB interface could be loosely considered 'syncronous'. The answer to this was called 'asynchronous usb' which does it right - i.e. no audio timing signal is applied to the audio data until it's within the controlled environment of the dac box.

 

What is unbelievable is that 'hi-fi' companies ever did it any other way. Ok, a dedicated audio card with an spdif out controlled by an accurate clock - that has downsides but at least some attention has been paid to clocking. But using the same interface as the one for your mouse, keyboard and external hard drive, just because it's there and familiar - bang. Bad audio, but provided as standard. It took a few specialist companies a fair amount of work to write audio drivers that would pull the data on demand, buffer it, etc.

 

So people say 'async' now in contrast to a recent time when data paths and interfaces, which should have had nothing to do with the audio chain aside from data delivery, were effectively tasked with maintaining an audio clock. And when the master clock was some POS on a motherboard.

 

Right, let's see who disagrees with that...

 

[audioengr]

"Good explanation. Which free-running clock do you mean and why should that help with jitter? Jitter forms while reading data, transcoding it, mux it, transfering it over the wire/fibre. Much of this happens because of not using realtime OSes and because interfaces/hardware isnt behaving in terms of electricity and attenuation always 100 percent the same. Why should asynchronous transfer-mode in USB help with that?"

 

The free running clock that clocks the USB interface in an async USB implementation. This is a "pull-mode" of transfer. The device acts as the clcok master and asks the computer for data over discrete intervals.

 

All precious implementations of USB audio streaming used Adaptive mode, which uses some type of PLL to track the incoming data. This is the "push-mode" of transfer. The device must accept the data at whatever rate the computer transmits it and synchronize its clock to this rate. Since the clock is variable and must "lock" to the incoming rate, it is more jittery by definition.

 

I sell both types of interfaces, Async up to 24/192 and Adaptive to 24/96. This is not about marketing. I'm an engineer. I design this stuff. Async is a superior method as described above.

 

Steve N.

Empirical Audio

 

 

 

[jesk]

Chris, again I'am not saying that jitter isn't important. But cleaning up jitter is just very easy. Stream your data somewhere, find out its rate, buffer it, and then feed it to the DAC. Of course done by a local clock. Clocks are everywhere today. No magic about it.

 

At the moment "vendors" are massively using the hype about the term jitter and its lack of clarity, what it is, why it is and how its solved since years in digital technologies, to make money out of crap.

 

Do you really believe there are no other technologies where you have to feed digital informations into D/A converters to get in exact timing grids stuff happening? Its just everywhere happening. Digital Audio is not different. The difference is maybe that in digital audio streaming over USB/SPDIF/Firewire the sample-rate needs to get analyzed first before having the informations in which rate it needs to get reclocked again. But thats all. Even that could be circumstanced if there would be a protocol around that audio stream like in RTP carrying parameters about its audio payload and so e.g. carrying also its rate.

 

And again, I'am not saying that there are no vendors not just using a buffer+clock+dac in their DAC-units, most of them are doing exactly that. But the hype about Anti-Jitter solutions is just a self-running money machine which has no reason to exist, because solution is simple, already there and widely used.

 

 

 

[audioengr]

"What is unbelievable is that 'hi-fi' companies ever did it any other way."

 

Well, that fact is that the expertise to do these interfaces was not at ANY audio company, so we relied on TI and third-party software developers to do this work. This is why I first licensed the adaptive code from CEntrance, as did Benchmark, BelCanto, PSAudio and others.

 

Most companies still do not have the expertise in place to do adaptive, so we license from M2Tech, Ploytec and others.

 

Consumers seem to always assume that this is some kind of conspiracy or marketing snake oil when its not.

 

Steve N.

Empirical Audio

 

[cfmsp]

"The above statement might be mostly correct, but consider the PS Audio PerfectWave Transport-there is absolutely no technical reason any computer based system should outperform it."

 

 

Can it communicate with any DAC via Firewire? Can it communicate to a DAC via Async USB?

 

Until it can, I don't see how you can say that there is "absolutely no technical reason any computer based system should outperform it"

 

I also can't help but note the irony of your taking Jesus to task for making a generalist statement (which you interpreted as being absolutist), when your own statement above includes "absolutely no" and "any".

 

 

just sayin'

clay

 

 

[jesk]

> The free running clock that clocks the USB interface in an async

> USB implementation. This is a "pull-mode" of transfer. The device

> acts as the clcok master and asks the computer for data over

> discrete intervals.

 

And does that help to avoid jitter? The answer is no. Because jitter

is generated in any case on its way to the final DAC.

 

> All precious implementations of USB audio streaming used Adaptive

> mode, which uses some type of PLL to track the incoming data.This

> is the "push-mode" of transfer. The device must accept the data

> at whatever rate the computer transmits it and synchronize its

> clock to this rate. Since the clock is variable and must "lock"

> to the incoming rate, it is more jittery by definition.

 

As there are only a few rates to be considered its quite easy to

set the clock appropriate. It doesnt need to adjust the rate

continuous. After clock-rate is found out, it just needs to get fed

with the data out of its buffer in that rate.

 

 

[ziggyzack]

'Accurate-Rip... It's not only checking the dataset. It's checking the offset also. Very important IME. I have test tracks with incorrect offsets. I can hear a difference in SQ with each one.'

 

Steve, I don't follow that. AIUI, the offset determines where a track actually starts vs where the drive thinks it starts, but it's measured in number of samples. (Anyone thinking this sounds like a nightmare, dbpoweramp asks for a CD in good condition and configures the drive offset itself during first use). Getting the offset wrong shouldn't mangle the sound or affect SQ in any way, it will slightly affect where the start and end of a track is, but that's all. Of course, if the start and the end of the track is out, then this messes up the AccurateRip lookup. So discovering and setting the drive offset is all about configuring for use with AR, it's nothing directly to do with SQ.

 

[cfmsp]

 

"Well, that fact is that the expertise to do these interfaces was not at ANY audio company"

 

 

Perhaps you don't consider Metric Halo an audio company because they're a "pro" audio company?

 

They released their first Firewire-based ADC/DAC using the local clock as master in 2003.

 

clay

 

[The Computer Audiophile]

Hi Jesk - Thanks for the response. I disagree with your comment about cleaning up jitter being easy. In high-end audio manufacturers are seeking the absolute lowest jitter specs possible. Since jitter measurements are readily available, although not done consistently by everyone, it's clear that no technology can totally remove jitter. Getting jitter to a certain level may be easy, but reducing it to single digit picoseconds when measured using many different methods is not easy. If it was easy everyone would do it.

 

You are 100% correct that D/A converters are everywhere now. But, the jitter specs inside a standard mobile phone are not that important and phone manufacturers don't strive for the best. They are seeking low cost.

 

There's a thread around here where we discussed using a memory buffer and how it's not the panacea that many people think it is. There is so much more to it than buffering data to memory. I've asked this question to AES Fellows, Ph.Ds and very respected engineers who have nothing to do with making money off this stuff. All say it's not as easy as it theoretically sounds.

 

I wish this was easy. We could have better DACs for less money.

 

Thanks again for your response. I can see your point of view a bit better now.

 

[audioengr]

"As there are only a few rates to be considered its quite easy to

set the clock appropriate. It doesnt need to adjust the rate continuous. After clock-rate is found out, it just needs to get fed with the data out of its buffer in that rate."

 

Okay, I understand what you are missing.

 

The clock rate must be EXACTLY the same if the data is coming at its own rate and is buffered and clocked-out with a local clock. This is impossible.

 

No 2 clocks have exactly the same frequency. You will eventually have data overrun (bits falling on the floor) or data underrun (gaps that cause dropouts). Eventually at the rates we are talking about is fast, seconds at best. Even with huge buffers, if you have a playlist of 20 tracks, you will have problems, guaranteed.

 

Steve N.

Empirical Audio

 

 

 

[The Computer Audiophile]

Hi ZZ - WOW, we actually agree on something :~)

 

[ziggyzack]

That's what I was thinking, and apparently agreeing with Clay too! Though I won't push it

 

[audioengr]

"Getting the offset wrong shouldn't mangle the sound or affect SQ in any way, it will slightly affect where the start and end of a track is, but that's all."

 

I agree in principal, but it does. I have proved this to myself and many others including Jon from Sonic Studio. I even did demos at 2009 RMAF in my room. Everyone heard the difference in Amarra and everyone heard the difference in these offset tracks.

 

I even have customers with NOS DACs that tried my sample tracks. They report that each sounds different.

 

Another streaming audio anomaly that we dont understand.

 

Steve N.

 

Empirical Audio

 

[audioengr]

"Perhaps you don't consider Metric Halo an audio company because they're a "pro" audio company?

 

They released their first Firewire-based ADC/DAC using the local clock as master in 2003."

 

They were not known as a high-end audio company. In this same timeframe there were async solutions from other companies also, including Ploytec, which was used in Tascam and other inexpensive "pro" gear. It was buggy and not ready for primetime. I tried it. It needed USB 2.0 to be in all machines.

 

Steve N.

 

[ziggyzack]

Well for me, I'd leave it at 'we don't understand' rather than concluding drive offsets are audible, given how excessively unlikely that is, but then that's probably not empirical enough

 

[barrows]

"Can it communicate with any DAC via Firewire? Can it communicate to a DAC via Async USB?"

 

Not sure what your point is here? Are you suggesting that only by communicating via firewire will state of the art performance be achieved? If so, we are in total disagreement.

My point was, and is, that the PerfectWave Transport performs as an equal (sonically) with any computer based playback method, as it is the same as computer based playback: because:

 

1. It rips data from the disc (CD or DVD data disc) using software designed to re-read until an error free rip is achieved.

2. It plays this data out of a solid state memory, using a fixed frequency clock, to achieve both bit perfect and low jitter playback. This is "asynchronous" data transfer...

3. It uses I2S to transfer the data to the DAC, making the fixed frequency clock the "master" and only clock in the playback resulting in very low jitter level at the DAC chip.

 

Async USB and/or Async Firewire are only two ways to get bit perfect low jitter playback, the PWT/PWD combo is another way, as is Ethernet. All of these methods when properly implemented can result in state of the art digital performance in terms of being extremely low jitter, and bit perfect.

 

My statement about "absolutes" was not in reference to anything posted by Jesus, it was in regard to the quote from Steve, stating that computer audio playback exceeds the performance of all CD transports. I have a great deal of respect for Steve's work in this area, my point was just to demonstrate that using absolute language in marketing one's product can often turn off consumers. If one reads Steve's site, there are a lot of absolute statements, some of which may be true, and some of which are at the very least, questionable.

 

Jesus, if you got the idea I was critisizing anything you posted, please accept my apologies, and I hope the above clarifies what I was trying to say.

 

 

 

[jesk]

Ok Steve, now we understand us. Yes this is the drawback, absolutely.

 

*But* for this to happen the clocks must run out of each other widely.

 

44.1K/16b means 88.2KBps. Having only a buffer of 200KB would mean beeing able to cache more than 1 second of audio. Until the clocks are ran out of each other with a difference of 1 second all 20 tracks would be played. What also will happen is that after each song the buffer will empty and so over/underrun will not happen.

 

Enough for today. Good night. :-)

 

[cfmsp]

"...my point was just to demonstrate that using absolute language in marketing one's product can often turn off consumers. If one reads Steve's site, there are a lot of absolute statements, some of which may be true, and some of which are at the very least, questionable."

 

Barrows, I think I have a better understanding of your point now. You're saying that the PWT can deliver (to DAC via I2S) at the same technical level as other methods.

 

we're in agreement about absolutist language turning off customers. I was more than mildly curious about the PWD/Bridge when the PWD was first delivered/reviewd over a year ago. I frequented the PS Audio site, but got truly turned off by the "kool-aid" as dispensed by Paul, and fans.

 

Here's an example of absolutist language that also turns me off.

 

"...the PWT will read Red Book CD's and WAV files of any resolution from both CD and DVD discs (such as the Reference HRx discs) and output near-perfect digital data to any D to A processor made."

 

I originally had this quote in my earlier reply and took it out. Perhaps my reply will now make more sense, given that the PWT will NOT communicate via either Async USB or Firewire, despite the claim that it will talk to ANY D to A Processor made.

 

I asked about these two forms of interface (not because I believe Firewire to be the absolute best - how many times do I need to correct your misconception about my opinion on this? :0) for the simple reason that I didn't see how one could claim that there was no technical reason that any computer system could outperform it, when the PWT will NOT deliver data via either of these formats, or even ethernet, for that matter.

 

FWIW, I don't consider an I2S interface as being of the same caliber as the best Firewire or Async USB DACs. I'm not alone, as most engineers here seem to agree.

 

 

Probably best we agree to disagree, esp. as I have no issues with your preferences for (and support of) all things PS Audio. I was mostly just trying to point out the irony and plethora of all the absolutist talk.

 

cheers,

 

Clay

 

 

 

PS, I misread Steve's comment as Jesus's in your reply, as you had quoted Steve's direct addressing of Jesus.

Apologies.

 

 

 

 

[barrows]

Believe me, I have never liked Paul's use of words in marketing materials, I believe he uses absolute terms and hyperbole way too often, and I (and others) at PS Audio often butted heads with him on this approach (but he was my boss).

As to the fanboy effect, well, some here might suggest that this could be the kettle talking...

In any case, I will speak up for the PS Audio stuff, as their approach is a good one, and all too often here I see people making generalisations about the PWT/PWD and Bridge, which show a lack of technical understanding of what these products really offer. Because I am quite well versed in their approach I do feel compelled to speak up for them. Note though that these products are not what I use, and my enthusiasm for them comes strictly from a technical (and listening experience) understanding of their approach, and not from some personal/emotional investment in them.

As to I2S, respectfully, you are incorrect, when properly implemented, and not run a long distance (kept under two meters) PS Audio's I2S interface is essentially "jitter free" (in quotes, to denote usage as is common among manufacturers!). This can be (and has been) measured.

The PWT can connect to any DAC via SPDIF, and as such, it will deliver performance equal to or better than any other SPDIF approach (Wavelink, etc.). I am sure we can both agree that SPDIF is not the best way to go though-but very good SPDIF certainly can produce very good performance, just not as good as the best fully asynchronous implementations (Firewire, USB, Ethernet, I2S).

 

[audioengr]

Clay wrote:

 

"I don't consider an I2S interface as being of the same caliber as the best Firewire or Async USB DACs. I'm not alone, as most engineers here seem to agree."

 

You can count me out. The performance of I2S like all other digital interfaces depends on the implementation. I dont agree with the PSAudio implementation, but they are at least on the right track. Noones product is "jitter-free". Impossible.

 

I believe my I2S is better. I have measured the jitter and it is extremely low, less than 100psec, depending on the clock I use. With some clocks, its 30psec, and that is P-P over all frequencies, not RMS at one frequency like most companies spec.

 

I demonstrate every year at RMAF the difference between USB, S/PDIF and my I2S interface driven by an outboard device like my Off-Ramp or Pace-Car. The I2S is always a bit better, but very close to my S/PDIF, provided you use my Bitmeister digital cable. The difference is more obvious with other cables.

 

My I2S is no different than any other non-differential digital interface. I have designed dozens of similar interfaces during my 30 year career in computers. Not being a standard is not an impediment to achieving a high-performance design, except maybe for designers with less experience.

 

Maybe you dont realize this, but I was attacking jitter in computer audio playback long before there was a Wavelength and long before PSAudio and BelCanto had computer interfaces. I was the first manufacturer to show computer-driven audio at CES. I was also the first real hi-end company to offer 24/192 async USB interface - in March of 2010. I just dont advertise in magazines or have a large staff at my company. But I do make the best sounding digital. My Overdrive DAC got Golden Ear award from TAS - "the best USB DAC" - Steven Stone, as well as my USB converter, the Off-Ramp. I won a DAC shootout last year in California with the best DACs of that time, including Wavelength, Weiss, dCS, EMM labs and Berkeley. They may have big marketing staffs and advertising budgets, but I have the design experience.

 

Steve N.

Empirical Audio

 

[cfmsp]

"As to I2S, respectfully, you are incorrect, when properly implemented, and not run a long distance (kept under two meters) PS Audio's I2S interface is essentially "jitter free" (in quotes, to denote usage as is common among manufacturers!). This can be (and has been) measured."

 

Barrows, my opinion on I2S hardly matters, it's also the opinion of most of the engineers here whenever the topic has been debated!

 

basically, it's not commonly accepted that I2S interfaces perform at the same high level as the big three - Firewire, Async USB, Ethernet.

 

No one I know relies on published jitter specs (or other jitter measurements) to prove two devices are equal caliber.

 

More to the point, in my opinion, all any computer has to be able to do to best the PWT is to deliver a high quality data stream to any of the DACs that outperform the very few I2S DACs extant.

 

I say all this light-heartedly, as if we were in a bar in Boulder sharing a beer and giving each other a hard time over our differing views.

 

cheers,

clay

 

 

PS, I sent you a PM.

 

 

 

 

 

 

 

 

 

 

 

 

[cfmsp]

 

"You can count me out."

 

I remember Steve, that's why I said "most".

 

 

 

You were also the first with I2S interfaces, as I recall.

 

Kudos for being a first mover!

 

cheers,

clay

 

 

 

 

 

[ted_b]

Sorry, had to do a "small world" post.

 

[audioengr]

"You were also the first with I2S interfaces, as I recall"

 

No, actually another innovative company, Audio Alchemy started this and then the follow-on company Perpetual Technologies carried-on. Some of their CD transports connected I2S to their DAC's were highly regarded by those in the know in the industry, including some dealers. Then Northstar added I2S to their DAC and Transport as well as Stello and AudioLogic. These are all compatible using the right cable. A couple of companies did a different version that was differential and used a large "D" connector, but this never caught on. The problem with most of these is that the transmission-line effects and terminations were not dealt with properly due to inexperience of the designers. Much like most of the S/PDIF interfaces.

 

Then PSAudio did their based on LVDS technology, which is not the best for jitter IMO, but at least it has rules for termination, so you dont have to know much about transmission-lines.

 

I've been thinking about adding the PSAudio connnector to my Off-Ramp in addition to my I2S connector. Have had a lot of requests for this. Maybe next fab. It would be interesting to hear the difference.

 

Steve N.

Empirical Audio

 

[vortecjr]

I'm good and I understood it was a quote. Anyway, I was mearly speaking about my tests and hope others understand that they are specific to what I'm working on. Also, just trying to inspire people to try different things!

 

Barrows, thanks for the information on the "lens" topic. I did not realize the relationship between the Genisus Lens product and Paul M:) Indeed it was very nice to meet and chat with you at the show!

 

Steve, I have read lots about your product and even traded e-mails with you and I never realized you were reclocking the usb input. To bad about the m2tech hi-face though...no linux drivers!

 

Clay, I have something really cool planned for firewire, but it's taking time...I'll keep you posted!

 

Jesus R

www.sonore.us