To Reclock or Not to Reclock ...

[vortecjr]

I heard the term "Lens" before in a video from Paul, but I can't remember in what context. Does the PW Transport use this technology?

 

Jesus R

www.sonore.us

 

[ziggyzack]

'consider the PS Audio PerfectWave Transport-there is absolutely no technical reason any computer based system should outperform it'

 

Well, I can think of several:

 

1) It still has only a limited amount of time to get the data off, so will not be able to deal with certain problems, which a ripping program would deal with. And problems are not always obvious or visible on the disc surface.

 

2) There is no way of knowing how good a rip it is getting afaik.

 

3) It doesn't compare with AR, which is THE gold standard.

 

4) It fails to eliminate a mechanical transport from your hi-fi stack.

 

5) Hopefully CD and other disk media will age well but there is no guarantee, so future readability may be problematic.

 

[hifitubes]

I recently added a Burl DAC, and clock my Lynx AES16 to its word clock output.

 

I also have a Zodiac+ which I am considering keeping as a headphone amp, and to use as a "de-jittering" unit on the last leg from Lynx > Burl.

 

According to Marcel (and my test) there is no serial word clock data on that AES output of the Z+.

 

I figure it should prove interesting to add this between the Lynx and Burl (while keeping the Burl DAC as master clock)...we'll see.

 

[The Computer Audiophile]

Jesk - You're really starting to sound like a troll based on your comments here and your previous post calling this all nonsense.

 

 

[hifitubes]

Jester - does your assessment apply to a system with a DAC set as master clock for the transport? I'm guessing you would say yes.

 

Maybe this will shed some light on this:

 

http://yabb.jriver.com/interact/index.php?topic=59460.0

 

WASAPI induces much less system latency than my Lynx ASIO driver, and frankly it sounds better to my ears.

 

Matt at J. River was contacted by many of us using high quality DACs and sound cards because WASAPI seems to push everything through and let the audio hardware "do the work" - we were noticing dropouts, on reliable setups, as compared to ASIO, and they re-engineered WASAPI method on their system to a WASAPI - Event Style.

 

It let's the audio subsystem pull data (when events are set) instead of pushing data to the system. This allows lower latency buffer sizes, and removes (hopefully) the unreliable Microsoft layer documented in this thread.

 

Maybe not relevant, but interesting nonetheless. I didn't really understand some of what you posted due to the typos.

 

[manisandher]

Hi Steve,

 

Before I offer my thoughts on your initial questions, as a previous D70 owner for 6-7 years, I think it'd useful to just summarise the various wordclock options the D70 offers. There are three (incidentally, these are the terms Esoteric uses, not mine own):

A. PLL

B. RAM

C. wordclock+RAM

 

I'm certainly no expert, but in answer to your questions, here are my thoughts:

 

1) "What's actually going on: Is the DAC's clock being completely bypassed with my current configuration?"

 

It depends on which configuration you're using. If it's A, then my understanding is that the DAC's clock is effectively being bypassed.

 

If it's B, then the DAC is asynchronously reclocking the input using it's own clock and a 128MB buffer.

 

If it's C, then the DAC clock is acting as master and the transport (and this includes any computer interface you may be using) will be slaved to it. My understanding is that your current transport does NOT allow for C, as it doesn't have a wordclock input.

 

2) Would replacing the current interface with a quality reclocker improve the sound?

 

Well, if you're going to use A, then perhaps. But, if you're going to use B or C, then I don't see how this is going to help.

 

3) Has anyone compared these alternatives and, if so, what are your thoughts?

 

My strong recommendation would be to use C. But this requires the transport to have a wordclock input. In addition, if you want to use the D70 up to 24/192, then you need a transport that has dual-wire AES capability. From experience, the RME AES-32 (PCI card) works well. If you can't accomodate a PCI card (and I believe you can't with your Mac Mini), then your only option is the firewire Weiss AFI1 - it is the only non-PCI transport that I know of that has wordclock I/O and dual-wire AES capability. I currently use this interface with my PM Model Two and prefer its sound over the RME AES-32. But it's kind of expensive...

 

HTH.

 

Mani.

 

 

 

[SteveChicago]

Thank you Mani.

 

You are the only person who answered my questions. And, I'm happy to add, you did so comprehensively, succinctly, without bias, and without casting aspersions on comments of other posters. I truly appreciate it.

 

With my current configuration, I am using PLL + RAM (i.e., your scenario "B") with the digital filter over-sampler engaged. It's nice to know that my DAC's clock is still relevant and part of the equation. The sound is quite good, BTW, even though I'm using a lower priced pro interface.

 

I'm very interested to see how the incorporation of the Weiss AFI1 changes / improves the sound and whether it's worth the additional $$$.

 

Steve

 

* * *

 

@ Chris: I am direct and I don't beat around the bush -- I enjoy your site and its content. Respectfully, however, I do not appreciate you calling other members "trolls" or the like. This is supposed to be fun and informative. Please lighten up.

 

Steve

 

 

 

[manisandher]

My pleasure Steve.

 

With your current setup, try comparing scenario A with scenario B. I'd be interested in knowing whether you hear a big difference in SQ between the two.

 

Of course, if/when you get the AFI1, let me know how scenario C sounds.

 

Mani.

 

[barrows]

The "Lens" is PS Audio's name for their asynchronous clocking/re-clocking technology. It has its origins in the "Digital Lens" re-clocker produced by Genesis when Paul McGowan and engineer Bob Stadtherr worked there.

The PerfectWave transport uses a "lens" at its output, reading the data out of solid state memory and clocking it with a fixed frequency oscillator. The Network Bridge (optional card that makes the PerfectWave DAC a network audio device) uses a "Lens" at its output to provide low jitter data from the network to the DAC chip.

PS Audio will also be introducing a stand alone PerfectWave Lens as a separate product, essentially a multiple input digital source selector and re-clocker. The PerfetWave Lens will also be able to accomodfate the Bridge card, for those who might want a network streaming device to pair with their current DAC.

Nice meeting you at RMAF by the way!

 

jesk, or whoever you are, asynchronous means "not synchronous". You may have a lot of knowledge of your field, but it is clear you are not up to speed on the common ways of reducing jitter in digital audio. In digital audio, the term "asynchronous" is used to describe a data transmission method where the clock is not determined TO ANY DEGREE be the rate of the incoming data-a large buffer is used, which has flow control managed by code, and the output of this buffer is clocked by fixed frequency clocks (no PLLs or digital synthesized clocks). By this method the output jitter is generally as low as the inherent jitter in the clock circuit itself-hence the clock is "not synchronous" in any way with the incoming data. This method of clocking (or re-clocking as in the above examples) is very different different than how digital audio is generally handled by SPDIF input DACs-these use PLLs to adjust the clock to sync with the rate of the incoming data-typically resulting in jitter levels on an order of magnitude higher than what can be achieved with asynchronous techniques.

I would suggest that you educate yourself on high end digital audio playback before making any more absolute statements here-it appears that you have a lot of knowledge, which could be shared here. Streaming audio playback (extremely time sensitive) is very different from ordinary data transfer.

 

[barrows]

"1) It still has only a limited amount of time to get the data off, so will not be able to deal with certain problems, which a ripping program would deal with. And problems are not always obvious or visible on the disc surface."

 

The above, in real use, is incorrect. The PerfectWave transport works just like a computer ripping a CD with good ripping software: it rips the disc at high speed, and does re-reads with any sections that produce errors until it gets a "perfect" rip. The drive is a DVD ROM, and the ripping code (proprietary) works very similar to "read until right" type solutions like EAC and dbpoweramp. As the data is read, it dumps it into memory. There is plenty of time for this process to take place with no ripping errors, as the memory can easily store minutes worth of playback. It can also read DVD data discs loaded with wav files and play them back directly by the same method (up to 24/192).

Yes, it does not do checksum comparisons with a database, so with very damaged discs perhaps there could be an error or two that gets through, but in practice this is not a problem. Personally, I do not bother with doing checksum comparisons with my rips with the computer, I am not that paranoid.

You may want to learn a little more about a product before you make assumptions on how it operates.

 

 

 

[jesk]

Comments inline:

 

> jesk, or whoever you are, asynchronous means "not synchronous". You may have a lot of knowledge of

> your field, but it is clear you are not up to speed on the common ways of reducing jitter in digital

> audio.

 

Clever statement. Asynchronous means in different technologies different things. So Lets stay in the

digital audio world when talking about asynchronous.

 

> In digital audio, the term "asynchronous" is used to describe a data transmission method where

> the clock is not determined TO ANY DEGREE be the rate of the incoming data large buffer is used, which

> has flow control managed by code, and the output of this buffer is clocked by fixed frequency clocks

> (no PLLs or digital synthesized clocks).

 

Partial wrong. Asynchronous means that the sending process isn't locked and can be interrupted. This

is possible with userland threading or kernel threading.

 

What asynchronous not automagically should mean is that the receiving end of the communication isn't

doing CDR (Clock Data Recovery). This should be done in any case.

 

In neither way of implemention the clocking should be settled by the rate of the incoming data.

Imagine a process has to get and send data as accurate as 1/44100 or even 1/192000 a second. Thats

not possible because of the lack of a realtime OS and because of involvement of too unprecise

physics.

 

Asynchronous communication which is not possible with SPDIF has no benefits for handling jitter. The

only thing which can be done with it is keeping the receivers buffer in a well filled state. As soon

as the buffer fills too much up or gets empty the receiver can communicate this to the sender so that

it can adjust its rate apropriate.

 

PLLs are for nothing more used than for CDR.

 

> By this method the output jitter is generally as low as the inherent jitter in the clock circuit

> itself-hence the clock is "not synchronous" in any way with the incoming data.

 

No receiver should adapt to the rate of the incoming signal as its inaccurate. You can do this wrong

with both ways of communication - again, not a matter asynchronous or synchronous.

 

> This method of clocking (or re-clocking as in the above examples) is very different than

> how digital audio is generally handled by SPDIF input DACs-these use PLLs to adjust the clock to sync

> with the rate of the incoming data-typically resulting in jitter levels on an order of magnitude

> higher than what can be achieved with asynchronous techniques.

 

Wrong. They just try to adapt to the rate to know if they should interpret that stream as a 1k, 2k,

44k, 88k, 96k or whatever they support rate. Thats the reason why they modulate the data as

Biphase-Mark-Code.

 

> I would suggest that you educate yourself on high end digital audio playback before making any more

> absolute statements here-it appears that you have a lot of knowledge, which could be shared here.

> Streaming audio playback (extremely time sensitive) is very different from ordinary data transfer.

 

No comment.

 

[ted_b]

Is there a primer or comprehensive explanation of clocking somewhere on the web? I mean, I understand the concept, understand what jitter is defined as, just not the details, and can't seem to follow what appears to be straight forward logic and math. I'm still confused on master clock, slave, word clock, etc. I don't mean to dumb down this discussion, so please don't try to explain here...just if anyone has a good white paper or primer location I'm all for it.

 

[ziggyzack]

'You may want to learn a little more about a product before you make assumptions on how it operates.'

 

That's an undue admonishment Barrows. I have read plenty on the PWT and I described how it behaves perfectly well. I have to say I don't like the PWT much. I see it fitting in is as a substitute for proper computer audio for those who are put off by the idea of computer audio, and want to use their original media. Of course it's good that it gives access to high quality music to this probably huge market segment, but it does something very expensively that can be done better and much much cheaper, and is a technological cul-de-sac.

 

It does have a limited amount of time to get the data off, because it's limited by the memory in the player (which I'm sure is ample) and the amount of time taken before playback catches up with wherever it experiences an error. As it doesn't read the entire disc up-front, this is always a risk. You therefore have a fast-spinning CD-ROM drive in your hi-fi rack when it discovers errors. dbPowerAmp went to town on some of my CDs, including those not obviously damaged, re-ripping loads of frames and taking a very long time, longer than realtime, and eventually got perfect rips. Amazing. These were exceptional cases, but they were nevertheless real. Some, it couldn't successfully rip at all, so I know I need to get replacements, or live with them interpolated. EAC and dbpoweramp have been developed over several years and produce output files you can verify. With the psaudio system, you pretty much have to take a newcomer's word for it.

 

Yes, the PWT doesn't ask very much in the way of tech knowledge of its users, but does it live up to your statement 'the PS Audio PerfectWave Transport-there is absolutely no technical reason any computer based system should outperform it'. Categorically, no. And the quality of its read-until-right function - a really specialist endeavour - is very hard to verify as PS Audio say they will not provide the functionality for the PWT to be used as a ripper.

 

ZZ

 

[The Computer Audiophile]

Jesk - You use the word "should" quite frequently. Do you know of any product that functions exactly how you think it "should".

 

[CG]

"Is there a primer or comprehensive explanation of clocking somewhere on the web?"

 

Try these. None are from sources that can be impugned as being hobbyist in nature or so-called audio voodoo.

 

http://www.analog.com/static/imported-files/application_notes/5847948184484445938457260443675626756108420567021238941550065879349464383423509029308534504114752208671024345AN_756_0.pdf

 

http://www.eetimes.com/design/automotive-design/4010006/Understand-analog-digital-converter-clock-jitter-and-why-you-should-care

 

http://www.maxim-ic.com/app-notes/index.mvp/id/800

 

 

 

[audioengr]

Jesus - my USB interfaces, including the older Adaptive 24/96 and my new synchronous 192 reclock, so a reclocker is not needed if you use these USB interfaces. They already reclock.

 

My reclocker the Pace-Car is used primarily for WiFi devices such as Sonos, Transporter, Squeezebox, Duet, Touch, AppleTV, some converters such as Lynx AES16, Fireface400, and some transports such as Marantz SA-11SE.

 

Steve N.

Empirical Audio

 

[audioengr]

"Asynchronous in the case of digital audio is nonsense. Period."

 

Not true. Asynchronous has a broad meaning in digital electronics. It's unfortunate that they named this mode of USB async. It should have been called "pull-mode" as opposed to "push-mode".

 

My Pace-Car actually works both synchronously and asynchronously. If you read about the three modes, mode 1 and 2 are synchronous and mode 3 is asynchronous.

 

Steve N.

Empirical Audio

 

[audioengr]

Barrow wrote:

"In digital audio, the term "asynchronous" is used to describe a data transmission method where the clock is not determined TO ANY DEGREE be the rate of the incoming data-a large buffer is used, which has flow control managed by code, and the output of this buffer is clocked by fixed frequency clocks (no PLLs or digital synthesized clocks)."

 

Actually this term as you describe it only applies to one mode of USB protocol, nothing else.

 

In digital electronics, asynchronous generally refers to circuitry that is clocking a signal into a register or flip-flop that has no timing relationship to the local clock.

 

Synchronous refers to circuitry that is clocking only signals with fixed timing relationship to the local clock.

 

Steve N.

Empirical Audio

 

[audioengr]

Barrows wrote:

 

"Personally, I do not bother with doing checksum comparisons with my rips with the computer, I am not that paranoid."

 

Well you should be. I ripped a lot of disks with EAC without using Accurate-Rip. I had to go back and re-rip all of them with dbpoweramp with Accurate-Rip enabled because of the significant difference in SQ. Try it. 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 N.

 

[barrows]

Like I said, I was talking real world useage and not in theoretical terms as you are. All it takes is one listen to the PWT in a system and comparison with well implemented hard drive playback (to the same DAC) to realize what I am saying is true.

 

PS Audio makes both solutions, so the consumer can decide what they are comfortable with, and what will work for them. If one wants the performance of a computer based ripping and playback solution, but is more comfortable with putting a disc in a drawer, they can achieve both with the PWT. If one would rahter not have a physical disc spinner in the rack, one can choose to use the network bridge with the PerfectWave DAC and have delivered to the DAC that way. It is the consumers choice, either way will result in the same, superb sonic performance. Make no mistake though, the PWT/PWD combo is not sonically compromised versus a ripped file playback, as they are the same thing.

 

[jesk]

> Not true. Asynchronous has a broad meaning in digital electronics.

> It's unfortunate that they named this mode of USB async. It should

> have been called "pull-mode" as opposed to "push-mode".

 

My statement meant that I don't see any reason for asynchronous modes for transmitting audio.

 

I think i explained it enough what asynchronous is about.

 

 

[audioengr]

"My statement meant that I don't see any reason for asynchronous modes for transmitting audio."

 

Then you dont understand the role of jitter in the D/A conversion.

 

Asynchronous USB allows a free-running clock to be used as clock master near the D/A chip. This is the lowest jitter solution.

 

If you dont believe in jitter, that's another thing entirely. I wont spend any cycles trying to convince you. Waste of time IME...

 

Steve N.

Empirical Audio

 

[jesk]

> Then you dont understand the role of jitter in the D/A conversion.

 

> Asynchronous USB allows a free-running clock to be used as clock

> master near the D/A chip. This is the lowest jitter solution.

 

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?

 

> If you dont believe in jitter, that's another thing entirely. I

> wont spend any cycles trying to convince you. Waste of time IME...

 

You didn't read my posts, elsewise you would know that i believe in jitter. I just dont believe in techniques which just exists to get new market segment. Let me guess: you sell that kind of asynch USB stuff?

 

[ziggyzack]

Barrows, you started off saying 'there is absolutely no technical reason', and now you've retreated to 'I was talking real world useage and not in theoretical terms'.

 

Ok, I'm sure the thing sounds good an awful lot of the time, but the PWT is a marketing-led ginger step-child of a product, in my opinion of course.

 

Happy to agree to disagree though, lest people get mad

 

 

[The Computer Audiophile]

Jesk - In your previous post you said this:

 

"Why the whole "DAC jitter via USB/Toslink/SPDIF etc."-issue is only marketing and total nonsense

 

I promise that noone is capable to prove the opposite... :-)

 

Based on where you are accessing the site from I'm guessing there may be a bit of a language barrier, but nonetheless it appears you don't believe jitter is an issue and that everyone should engineer DACs using your theoretical method. I'm willing to bet there is very good reason why every engineer doesn't do things your way.

 

Can you point to a product designed your way?