Best Low Jitter feed for external DAC

[jkeny]

I agree with the idea of avoiding jitter in the first place but have you tried to do this when using a PC as a transport? It's impossible due the number of variables in play both in hardware & software - disk servos, DC-DC converters, SMPS, chip gates firing - Operating System interrupts & housekeeping routines, interaction between s/w & h/w, etc. Even different playback software or whether FLAC or WAV is being played are recognised as variables

 

My contention is that you will never achieve full jitter reduction, reliably & successfully with a general purpose computer platform. Only through reduction & tight control of the parameters is it possible - look at ec-designs SD lossless card player on DIYA as a pointer to the direction - even though a FPGA rather than DSP would have been a better engine.

 

So with the platforms that we are currently using as transports, I think the only sane way is to try to treat the inevitable jitter coming from these sources. The synchronous clocking scheme seems to be a good attempt to do this & failing that an asynchronous clocking scheme seems to be the next best option.

 

Jitter, to me seems to be intrinsically related to or intertwined with power supply imperturbability (is this a word?) where the approach is to design as clean a PS as possible & then use as high a PSRR circuit or component as possible. So in jitter terms, reduce it as much as possible (but accepting that 0 is impossible) & then use jitter insensitive parts (Sabre ?).

 

As a general principle, this makes sense to me but now the problem becomes, how best to implement it?

 

Do these soundcards accept SPDIF input as a clock synchronisation?

Terratec Aureon Sky 5.1 with Envy chip

ESI Juli@

RME Hammer DSP

M-Audio 2496

Delta 1010

M-Audio Revolution 7.1

M-Audio Revolution 5.1?

 

 

[Audio_ELF]

It's my understanding (from what Gordon @ Wavelength has written) that there is no jitter in "disk servos, DC-DC converters, SMPS, chip gates firing - Operating System interrupts & housekeeping routines, interaction between s/w & h/w, etc. Even different playback software or whether FLAC or WAV is being played are recognised as variables". There other factors involved in these aspects which may affect sound quality but Jitter only exists when data becomes time sensitive at the SPDIF or other serial streamed point. Until then the "data is data" argument holds as there is no clock timing involved.

 

Using an async transfer, either Firewire or async USB (ala Wavelength, Ayre, dCS, etc.) a good clock minimizes jitter especially if used with a good linear power supply - quite a few people on the Naim forum use a KC Konnect 8 device with an adapted NASCP power supply (£300 FireWire device with a £300 PSU). Yes there is some Jitter involved still but using the FireWire interface and a good PSU minimizes it. Using a FireFace 400 device you could similarly start with minimal jitter due to the FireWire async transfer but you then add to that a WordClock input/output which can be linked to a suitably equipped DAC.

 

Using such an interface with a DAC which has reclocking circuits built in (either ASRC or fifo buffering, etc) should bring the effects of jitter down to a level where other factors become a lot more relevent (such as output stage, etc).

 

Eloise

 

 

 

[cfmsp]

 

 

"it's best if you can avoid jitter in the first place"

 

agreed, and would just add that not everything that affects the DAC should be called jitter. we don't yet understand all the other factors, so it's more difficult to provide simple advice about avoidance.

 

I will also say, that with Async USB and Firewire, there is a point of diminishing returns with jitter avoidance. Reclockers and what not, in advance of either Async USB or Firewire, seem an unnecessary extravagance. in my opinion. As recording engineers such as Bob katz have said, the best place for the clock is in the ADC/DAC. In recording, devices quite naturally have to be 'clocked' together on occasion. In my view, using an external clock is an unnatural (and unnecessary) implementation in the digital audio playback chain, and should be avoided MORE than jitter itself. It seems to me that if one's DAC benefits (substantially) from a reclocker, then the best bet is to get another DAC. Again, YMMV.

 

I'm reminded of Segal's Law - "A man with one watch knows what time it is. A man with two watches is never sure."

 

enjoy

clay

 

[jkeny]

It's my understanding (from what Gordon @ Wavelength has written) that there is no jitter in "disk servos, DC-DC converters, SMPS, chip gates firing

- The way I see it is that everything that disturbs the PS can cause some timing problem in D to A conversion & this is jitter. Servos in CD transports are a good example of this - causing fluctuations on the PS which can bleed into the PS of the clock.

 

I agree that I'm probably using the term jitter as a catch-all term to describe everything that effects the D to A conversion but in the absence of another term it seems useful.

 

I'll have a look at the Naim forum - can you give me a link?

 

[Audio_ELF]

clay wrote... "In my view, using an external clock is an unnatural (and unnecessary) implementation in the digital audio playback chain, and should be avoided MORE than jitter itself.

I've a feeling that its one of these things that with a badly implemented external clock, the result is worse than using "Ok" internal clocks, but with the highest end, best implementations (I know both dCS and Teac Esoteric have option of external Master Clocks and link DAC and Transport via word clock) , the external clock will pay dividends.

 

Thats another thing to add to the test list for another Symposium - Lynx & Berkley DAC with and without clock links :-) My list is growing :-)

 

Eloise

 

[cfmsp]

 

 

As an implementation approach, ASRC is probably fine for many.

 

Like you, IS, I have a 'philosophical' aversion to it, as it seems unnecessary.

 

I believe that it is NOT likely to yield the ultimate results, being rather more a practical/clever engineering solution that has a concommitant compromise in ultimate sound quality. It might provide 'cover' for various and sundry upstream audio 'problems', and thereby make great sense as a commercial product. But I think eventually it (ASRC) will be revealed as a masking agent in itself.

 

Food for thought: Metric Halo have just released their model ULN-8 preamp/ADC/DAC, which matches (or exceeds, depending on whom is talking) the level of transparency available in digital audio recording devices today. Despite being a world class recording device, it does not provide ANY SRC capability, asynchronous or otherwise. Supposedly, there were no available chips that could do real-time SRC with the appropriate level of transparency.

 

enjoy

 

 

 

[Audio_ELF]

The general link to the Naim Forums is http://forums.naim-audio.com There's not a specific thread where the TC Konnect8 with NAPSC is discussed but it is mentioned quite often. I'm pretty sure other people could supply you with similar quality power supply but the NAPSC is something that people have available after upgrading - it's originally designed to power the digital control section of their Mid-High end Pre-Amp. I'm unsure if you are aware but Naim do a lot of power supply upgrades and feel this is the way to improve quality.

 

Eloise

 

[Audio_ELF]

I suspect that the reason for using ASRC, etc is down to costs...

 

As a manufacturer you could spend (for example) $10 on the DAC chip, $5 on the FireWire interface and get a great result in terns of sound quality.

OR

You can spend $7 on the DAC chip, $1.50 on the USB interface and $1.5 on ASRC technology to link them all together and get a result thats very very close to the sound quality of the first design, but costing you about 2/3 of the first components pricing.

 

Now as an individual buying parts for 1 DAC thats not a huge difference ... but when you're building 1000 units it's a big chunk of your development costs.

 

Eloise

 

[barrows]

Just for clarity: my aversion to ASRC is based on listening tests. I used to work for a high end audio company, and we were developing a new DAC and disc transport. In the DAC we included an ASRC, and we also had a function which would allow the ASRC to be bypassed. With all other things being equal (our reference system) we could switch the ASRC in and out of the circuit for A/B listening tests. In this specific case the differences were clearly audible, in favor of no ASRC.

We also did jitter measurements which confirmed that the ASRC did indeed reduce jitter levels substantially when the DAC was fed a jittered signal (like optical out from a MacBook)-the disc transport we were developing featured very low jitter, and allowed the clock in the transport to be the master, so we really avoided jitter in the first place, and did not need the ASRC (to reject jitter) when the DAC was used with our transport design: with our transport the pair sounded way better when bypassing the ASRC.

With a computer source, one can benefit from a single, low jitter clock, located in the DAC, acting as master, with no need to reconcile differences (creating jitter) between different clock sources. Async USB, Firewire, and networked interfaces allow the clock in the DAC to be the master, resulting in low jitter, with no need to resort to additional re-clocking devices, ASRC, adding pro audio soundcards, or extra clock linking cables.

Many people on these forums seem very concerned with the idea of "bit perfect"; consider that adding DSP (like an ASRC) will result in a data stream that is no longer "bit perfect" as an ASRC eliminates the original bits entirely, creating a new data stream that is only a facsimile of the original.

 

[cfmsp]

 

Eloise,

 

we may be misfiring here, you refer to Berkeley DAC with and without clock and also to the 'option' of using an external master clock. I see a big distinction between the two, perhaps you do as well, and it just wasn't made obvious.

 

my view on preferred clocking approach:

 

1) top priority would be using low jitter clock IN the DAC, and using this to control the flow of data via Async USB or Firewire protocol

 

2) second priority - feeding the clock signal from DACs (e.g. Pacific Microsonics / Berkeley) which do not have async USB or firewire upstream to the computer (probably via Lynx card).

 

providing a master clock signal from the DAC back to the computer seems more desirable than implementing a separate, EXTERNAL master clock to me.

 

That said, I don't doubt that dCS could implement a cost no object solution to ANY approach that would be high quality. But, I don't agree that a dCS external clock option should be required for the highest possible sound as you seem to be saying with "the external clock will pay dividends." I could agree with 'might pay dividends'.

 

 

 

[Audio_ELF]

Clay...

 

I don't think our thoughts differ that much. The idea for a "single source" DAC for computer use is certainly either FireWire or Async USB with a single clock controlling dataflow throughout. Where thats not possible, then a single Master clock fed from DAC to interface (as per your 2 above) certainly has merits. My thoughts were though that a word clock interface implemented badly is probably worse than two independent clocks - so if both devices have a word clock interface give it a go, if not then don't sweat it.

 

My understanding is the idea (used by dCS / Esoteric / etc) of having a separate Master Clock is basically the same as your option 2, however a more accurate clock can be created by having it in it's own enclosure, with own PSU, etc. How much real worlds difference would depend on the rest of your kit though reviews of high end kit have indicated there is a audible difference when used with appropriate kit (i.e. it wouldn't transform a DAC Magic, but does significantly improve a DCS Scartatti setup)

 

Eloise

 

[glt]

idiot_savant (don't feel right using this name :-) )

 

"There is no reason in hifi systems why you can't lock everything together one way or another"

 

You can't "lock" clocks because each clock is independent and even if you can synchronize them at the start, they will diverge because each has its own precision and tolerance. You can only a single clock on multiple devices

 

jkeny:

 

I see you everywhere :-)

 

barrows:

 

"We also did jitter measurements which confirmed that the ASRC did indeed reduce jitter levels substantially when the DAC was fed a jittered signal (like optical out from a MacBook)-the disc transport we were developing featured very low jitter, and allowed the clock in the transport to be the master, so we really avoided jitter in the first place, and did not need the ASRC (to reject jitter) when the DAC was used with our transport design: with our transport the pair sounded way better when bypassing the ASRC."

 

That sort of proves that "unless you can slave everything to a single clock, the next best thing is to use ASRC"

 

 

In the end ASRC may be the most reasonable alternative to many. Feeding a high precision master clock to different devices got to be much more complex that running wires...

 

[idiot_savant]

Hi,

 

don't worry about my rather silly name - it's been earned over a long period!

 

When I say "lock", you're absolutely correct that free running clocks will vary over time with respect to each other - my main gripe about ASRC, as it happens. However, they can be "locked" by :

(a)Source clocks DAC ( DAC has a PLL which cause the DAC clock to track the source )

(b)DAC clocks source, either by feeding a physical clock back, or via asynch USB/firewire

©Masterclock type scenario, as highlighted by Eloise where the clock is in a different box altogether.

 

(a) is obviously the one where the source ( e.g. transport ) can have an effect on the DAC jitter, depending on how good the PLL in the DAC is - probably the worst-case scenario for introducing jitter is via adaptive mode USB

(b) is theoretically the "optimum" solution

© is the one used in studios for a variety of reasons, can probably give higher absolute frequency accuracy than (a) or (b) at the expense of absolute jitter performance.

 

The point of (b) (and ©) is that you eliminate entirely any jitter from the interface carrying the data, so there isn't _really_ any need for an ASRC.

 

One obvious example of ASRC being used in a scenario where the clocks can't be locked is in DACs using adaptive mode USB - in this case, the input really is very jittery, and in absolute frequency terms may be problematic for a DAC to lock to. Sticking in an ASRC will prove to be very effective in this case, but again, my preference would be to use asynch USB instead, and fix the problem at it's cause, completely. Then again, there aren't too many asynch USB solutions...

 

your friendly neighbourhood idiot

 

 

[Wavelength]

Gang,

 

The big problem with most of the ARSC's is not that it gives you this flexible clock buffer but has to do with the ALU unit.

 

You cannot do fixed math and expect good output when the ALU is fixed to 24, 26 or even 32 bits. It must be at least 64 and nobody makes anything like that. Remember all the coefficients for this type of math is less than one. Fractions in fixed point mean you give up all that low level information. Which has always been the critical point of upsamplers.

 

A better way to reclock the unit would be a sophisticated PLL FIFO arrangement like many high end companies use.

 

Thanks

Gordon

 

[jilly]

This site is very informative.

 

Thanks for sharing!

 

 

 

 

 

Debt Consolidation Loans

 

[Telstar]

The good thing about i2s is that is accepted natively by most DAC chips, so there is NO NEED for a receiver.

Any receiver adds at least 50ps of jitter.

 

Some firewire to i2s transceivers have good performances, and theoretically are the only relevant cause of jitter. The total measured performance of the best of such are around 70ps.

 

Now the bad thing about i2s is that the connection (read the cable) has to be SHORT, shielded, and the signal itself must be galvanically isolated. Often this is poorly implemented (i.e. north star, zanden...)

 

Note also that both usb and firewire need a proper isolation, and that this is also often lacking in commercial products.

 

[PeterSt]

There is no means to report spam I think ?

 

Peter

 

Edit : ... which was about a spam post - now removed.

 

[hifitubes]

Lavry. Any comments? http://www.head-fi.org/forums/f7/usb-spdif-converters-shoot-out-emu-0404-usb-vs-musiland-monitor-01-usd-vs-teralink-x-vs-m2tech-hiface-449885/index20.html#post6173885

 

 

virtually all DA's have some jitter cleaning circuitry. At the minimum one has some circuit called a PLL (phase lock loop) which cleans up much of the higher frequency jitter content. There are other schemes as well, some are very sophisticated.

 

 

And jitter is not only about the timing errors in the signal arriving on some cable into the DA. Much of the jitter issue has to do with timing errors due to power supply, component and circuit noise, electromagnetic pick up, poor layout... All that is INSIDE the DA, and that is where most of the issues are.

 

 

I am not saying that one should ignore jitter on the data arriving to the DA on a cable, but that is often a very secondary issue.

 

 

DA jitter matters at ONE LOCATION - where the digital signal is altered to analog. If you have 10 nano second of jitter, arriving on a cable from and interface, but the jitter energy is at say ABOVE 5KHz, that signal may go through a PLL circuit before it gets to the DA (where it matters). The PLL may clean the jitter it up by say 40dB (that is very realistic) and if so, the jitter is attenuated from 10nsec to 100psec. (40dB is 100 time attenuation). So one guy is measuring 10nsec, the other guy does not hear the impact, because the DA circuit "fixed the problem". it Is that surprising?

 

 

It is no wonder that while one is measuring over 10nsec, another is not hearing it. If that jitter energy were at say 100 or 500Hz, the PLL would be of little help. It may not reject low frequencies at all. One needs to know more detail then just one number. A 20nsec jitter at 10KHz may be less of a problem then a 1nsec jitter at 500Hz. One needs to have much more detail then some "simplified overall number".

 

[Wavelength]

Gang,

 

Look... jitter matters everywhere. If you only look at it when the data hits the dac you are missing more of the equation. If you treat it from the beginning then you will be a lot better off.

 

See designers think that the jitter into say upsamplers or filters doesn't matter. Well news for them if it did not matter then truly all the jitter measurements that Stereophile did would be the same for any interface....

 

Well take a look and you will see that they are never the same and the difference from most of the Adaptive USB to their SPDIF is drastically different. So these designers need to wake up and smell the coffee because jitter at any stage is going to effect the outcome and they need to start looking a little ahead.

 

Thanks

Gordon

 

[hifitubes]

You have not directly addressed any of his comments. He took the time to elucidate math on Head-Fi in numerous posts. We know you are a smart cookie Gordon ; )

 

I'm just wondering given the amount of OCD in this thread, if it matters as much as we like to believe.

 

[cfmsp]

"He took the time to elucidate math on Head-Fi in numerous posts."

 

Mr. Lavry took the time to 'elucidate' because he believes that HIS math proves HIS design approach to be superior. Maybe he's right, I don't know.

 

BUT, as far as I can tell, math means nothing to me when I;m listening to music. It seems perhaps useful as a theory to help an engineer decide where to begin - but, IMO, not as a proof that an implementation sounds superior (to another) as Mr. Lavry would have us believe.

 

It's all in the listening.

 

YMMV, etc., etc.,

 

clay

 

 

 

 

 

[hifitubes]

I agree, that's why I want to hear something cogent from Mr. Rankin. Rather than a broad sweeping generalization.

 

On paper, there is the both the claim for and against the 'digital cable length matters' issue. That's as good a place to start as any imo.

 

I found it interesting that Nugent never further explicated on his objective claims, rather he referred to a biased & invalid listening test.

 

I plan on ABX'ing with multiple devices soon and a few various lengths; I'm all ears.

 

 

 

[icebreaker]

To your block quote of Dan Lavry? Gordon was not even mentioned in that post. Is this discussion a carry over from another forum? Or were posts deleted from this thread? I feel I'm missing something here.

 

 

 

[hifitubes]

I posted something I thought was relevant; Mr. Rankin felt obligated to respond when I asked for comments from the group.

 

I enjoy Wavelength's contribution to high-end audio, but frankly if you are going to maintain an online presence, as a manufacturer, I don't think it's too much to ask of ANY company to stand behind their claims with either subjective tests or objective evidence.

 

This way we get a marketplace of ideas where the empirical data can be discussed by experts, then we can do our subjective listening tests and discuss our results.

 

If Mr. Rankin has conducted such ABx listening tests, or drafted a white paper on jitter, I would be happy to review and discuss either.

 

hifitubes

 

[cfmsp]

 

"but frankly if you are going to maintain an online presence, as a manufacturer, I don't think it's too much to ask of ANY company to stand behind their claims with either subjective tests or objective evidence."

 

Mr Rankin's rather well known, and very often stated, view is that people need to listen for themselves (as opposed to, e.g., expecting manufacturers to provide test data that mean very little outside of the context of the specific test - my words, not his).

 

Expecting someone to measure up to one's own expectations (as to 'maintaining as online presence') is asking for disappointment, IMO.

 

just my two cents,

clay