Best Low Jitter feed for external DAC

[Wavelength]

Jkeny,

 

I would have to agree that this is a project that you would have little luck with.

 

First again for someone else pointing this out but I2S is for mm not cabled.

 

Second yes all of the async devices above would need new clocks and a ton of modification. Many of them have a ton of DCDC converters inside also effecting the clocks. Others don't even have clocks but use PLL derived clocks. For them as with others you would have to alter the code to make external clocks work.

 

PCI really is not the way to go. The power supplies there are even worse.

 

The FitPC for which I have 2 of is not very fit at all. They are slow as crap and have a ton of DCDC coverters on the mother board. If I can hear a major difference between a 1GHz PC and a 2GHz PC and also even more between a 1GB memory model and a 4GB then using a 500-800Mhz/512M micro PC is nothing more than saving space and will not really make a high end candidate.

 

The big deal is that ok... say you get this all to work. How do you even know if it works better than you have now?

 

Thanks

Gordon

 

[jkeny]

Thanks Gordon,

We seem to be tracking one another on various forums. As peryourt post on AA it looks like Ethernet chip + FPGA seems to be the possibly ideal solution but still some problems of on-board DC-DC converters & possible RFI emissions to be ironed out!

 

[Wavelength]

Jkeny,

 

Well that and software...

 

Basically the problem with Ethernet is that there is no software. It is much easier to derive a USB solution than any of the other ones that I have seen.

 

Take it for what it's worth... I have looked at hundreds of alternatives now over the last six years.

 

Thanks

Gordon

 

[vortecjr]

nice post!

 

[colinharding]

Technically the best way to achieve a near zero jitter state is to use a DSP-1 processor instead of the typical PMD-100, DF1704 data input chip. In this sense the data runs in a two-channel Digital Interpolation Filter and data in-phase processor state for digital audio. Meaning that the data entered into the dac will run parallel instead of straight in and out. Jitter in commercial or high grade devices can be very high, as much as 200PS which is not very good even though thats a relatively low jitter value, however with the information running parallel within the processing unit Jitter is invariably zero. Its just intrinsic to the implementation that the jitter is that low, which is astronomical. This impementation also lowers the jitter of other respective devices to a near zero state even when using cheap mass-produced equipment. The only company that I know of that is capable of this technology is AudioGD and it exists in their DAC Reference 1 which retails for 1550. But don't let the price lower your expectations, it is recommended that you have VERY high end equipment rack to back it up because of its transparency and neutral characterstics.

 

colin

 

http://www.audio-gd.com/enweb/DACRE1.htm

 

[Audio_ELF]

Colin.

 

Can you please disclose your connection to Audio GD as your post seamed rather like an advert.

 

I'm also always very suspicious of "the design is unique" if it's so good then other companies would want to use same / similar methods.

 

Eloise

 

[colinharding]

I'm sorry I didn't mean to bolster or in any way advertise for AudioGD, its simply the only company I know of currently that employs this technology. IMHO it is currently the best way to go about totally reducing your jitter when using an out board dac. Additionally the company is based in China where these chips are manufactured putting them in an opportune place to test and employ them before any overseas (from their perspective) manufactures can get obtain them. I'm am a long time customer and fan of their work, but I'm sorry to make my post sound a bit like an ad as it was not my intention. I put the link in my last post, it proves what I have told you, but again their is totally the possibility of some other company employing a different or same technique that accomplishes the same goal. Consequently I am just not privy to their doing so and would love to hear of any alternative techniques. Just throwing my two cents down.

 

colin

 

[ted_b]

but is limited to 24/96. great GUI? yes, the iTouch!! The iPeng app foir Squeeze Center is virtually identical to iTunes on the iTouch/iPod (albuma rt, browsing, playlists, yadayada) and allows me to have a great ethernet player (my modded Transporter) grab music packets and send them, via high quality BNC 75 OHM SPDIF or AES/EBU (low jitter ethernet, low jitter player) to a top DAC of my choice (demo'd Weiss, Berkeley, Bryston so far). Note: the analog stage tube mods of my Modwirght Trasnsporter beat all but the best of the DACs....regardless...I agree that the next big $$ winner is the person who develops an ethernet based server/client setup that allows all sample rates and bit depths, with a friendly iTouch-based GUI. Sean Adams, founder of SlimDevices, left Logitech recently. Maybe he's on to something???

 

Ted

 

[jkeny]

Colin,

I appreciate your posting - I don't fully understand what the processor is doing but I assume that because it works differntially on the clock & data then it eliminates(?) jitter - can you explain more how this works? - I've read the link but still no wiser as to how it works.

 

This DSP-1 processor board looks like a stand alone product but I don't see any price for it or if it is sold separately. I would have thought other companies might be interested in licensing this technology (if available) given it's stated benefits.

 

It seems to be the FPGA solution that was theoretically mentioned above?

 

My investigations have led me to a simpler (& cheaper) path. One used by PeuFeu & John Swenson - to use SPDIF & to reclock at the DAC using a low jitter clock and send this clock back to the soundcard via SPDIF. Because jitter coming from the soundcard is no longer important (it's reclocked locally) a Toslink connection can be used from the soundcard to the DAC thus providing galvanic isolation avoiding the pollution of the ground plane from the PC. This seems to cover all the bases but I'm relying on you guys to point out the flaws. Has anybody implemented this scheme?

 

I know it will require a soundcard that accepts an external clock feed - so next question is - what is the cheapest soundcard that does this? I believe the ESI Juli@ does. I've heard that some RME cards do - which ones? Any others?

 

Edit: X-Fi also seems to accept external clock

 

[vortecjr]

I am going to read the esi manual today and see if I can spot any trouble with the card. The emu manual revieled the some interesting negative features and lets make sure the aes is free of them.

Dare I add the lynx card to the list....

Quick question....what is the advantage of reclocking at the dac (this part I undersand) and then sending the clock back the sound card (this I dont understand)?

 

[Audio_ELF]

From reading the description ... isn't the DSP-1 a resampling solution ... they say "Two-channel Digital Interpolation Filter and data in-phase processor for digital audio." ... using DSP technology. You still need to get the i2s input to the board which still is only designed to be transmitted over mm so you need either a USB/Firewire to i2s converter OR a good SPDIF output from your computer and then an SPDIF to i2s conversion. This is no different (if I understand the DSP-1 data sheet correctly) than the Cambridge Audio using the "Adaptive Time Filtering" method designed by Anagram technologies, nor countless other similar resampling methods.

 

If this is correct, then it doesn't really fit in with the original topic - which is how to get digital audio out of a PC with the minimum of jitter.

 

Eloise

 

[idiot_savant]

I hope no-one minds me stepping in here - the problem with reclocking at the DAC is that the source still has whatever problems it has - reclocking it with a lower jitter clock is great, but that lower jitter clock must STILL track the source clock - imagine if your super-duper low jitter local clock is temperature compensated, and is exactly related to 44100 samples a second, but your source isn't so super duper, and over time and temperature drifts between 44099 and 44101 samples a second. If your low jitter clock ignores this ( to remain independent of the jittery source ), where does the extra sample come from when the source is slightly slow, and where does the additional sample go when the source slightly fast? CG made an excellent analogy somewhere else on the site, to do with chocolate, I think!

 

This is why sending the local clock back is an excellent solution - the clock in the source adjusts itself to the low jitter clock in the DAC, so the good clock never changes ( which is the important one ).

 

Yours,

your friendly neighbourhood idiot

 

[cfmsp]

 

"This is why sending the local clock back is an excellent solution"

 

I"m not suggesting that sending the local clock back is not also an excellent solution, but with Async USB and Firewire, the DAC (as master clock) communicates to the source when it needs more data, which theoretically eliminates the need for a local clock at the player. In many installations, the extra clock would not seem to be necessary.

 

That said, I notice a posting from well respected source regarding the DAC to source hookup used at the Symposium which indicated that the Pacific Microsonics DACs fed a signal back to the Lynx AES cards, so perhaps we can never be too precise....or perhaps we'd be gilding the lily, unless the remainder of our system could resolve what slight differences the extra clock might make.

 

just my two cents, YMMV, etc.

 

 

 

[Audio_ELF]

I think that using an Async USB or Firewire DAC, there is no need to communicate a clock back to the "source" as it's all internal to the DAC.

 

If using a standalone DAC (i.e. with SPDIF or AES3 inputs) then feeding the clock back into the interface gives a single clock to all parts of the digital to analogue interface.

 

Eloise

 

[Wavelength]

Colin,

 

Actually a DSP is not a really good place for something like this. DSP's as well as many processors have tons of clocks which add jitter to the stream.

 

Even the TAS1020 which has very little going on will add some. But in my experience with the 10 or 20 DSP's I have worked with the jitter would be easily 5x that of the TAS1020.

 

JKeny is right the best way is with an FPGA. You basically push parallel data into it and the I2S stream can be formed and would be the lowest possible jitter because nothing else is happening except for the synchronized clocks forming the I2S output.

 

BTW anyone who says they have ZERO jitter is telling a big fat lie. Send one over I will put it on the Wavecrest and see how it fares.

 

Thanks

Gordon

 

[jkeny]

Yes, the suggestions of asynchronous USB & firewire are essentially doing the same thing as I stated above i.e. synchronising the timing of sending the data with the timing for receiving the data at the DAC. However asynch USB is restricted to a small number of DACs & Firewire DACs again are limited. In both cases a low jitter clock is needed which is not always the situation.

 

What PeuFeu & John Swenson have done is to use your external DAC of choice with a low jitter clock & send this clock signal back to a suitable souncard via SPDIF. This synchronisation is needed as stated above because if the clocks are unsynchronised (free running) then a situation can arise causing samples to be dropped.

 

This method also allows the connection between PC & external DAC to be galvanically isolated (through TOSLINK) avoiding the dirty ground that resides in the PC. Even with asynch USB this is not the case (unless steps have been taken to ensure this). I'm not sure if Firewire galvanically isolates the DAC? This can be as important to sound quality as low jitter clocks, I believe.

 

So come on all you PC sound experts - what is the cheapest soundcard that will accept a SPDIF as input & synch it's output to the master clock in this SPDIF signal? I know the ESI Juli@ will do this - any others? A lot of Pro soundcards accept the word clock as input for synchronisation but I've read somewhere that this is not as good.

 

I wonder if the bottom part of a Juli@ card is enough to do this without the top reversible part? I've read that the Creative X-Fi can do this but can't identify on which X-Fi card it's implemented.

 

Any comments?

 

[Audio_ELF]

According to the website - the EMu 1010 card* can have an extra "Sync Daughter Card" added which allowed a word clock input - though some people say the EMu has issues with setting sample rate.

 

Eloise

 

*The EMu 1010 PCI card is the basis for most of EMu's range of PCI solutions including the 1212 and the 1616/1616M packages. The packages add additional analogue inputs and outputs which for the purpose we are discussing are not required.

 

[Mr.C]

 

@jkeny:

"A lot of Pro soundcards accept the word clock as input for synchronisation but I've read somewhere that this is not as good."

 

Are you referring to sending the word clock using s/pdif with a "black" signal? If so, I think that there is a bid debate over which is better, s/pdif or word clock cable, with no absolute resolution ie. different manufacturers support different sides. If this is the case, then it opens up all those pro audio cards with word clock input

 

[pfarthing]

I have a question - playing devil's advocate - how really important is this problem of fixing jitter over S/PDIF or even USB, when we have ASRC chips like the AD1896 as used in the Benchmark et al, or the new generation of receivers like the Wolfson WM8804 and the new "jitter immune" DACs like the ESS Sabre?

 

Put another way, if you say that accessories like interconnects and power cables are like the last 5% of payback in terms of refining one's ultimate sound quality, how much bang for the buck do you really get pouring $$$ into transports rather than say, just getting a better sounding DAC?

 

 

[idiot_savant]

I'd say that ASRC techniques are fundamentally flawed, and would be my least favoured approach to reducing jitter in a system. They have far too much "magic" about them for my liking - you have an excellent local clock for the DAC, and no matter how jittery the input is, this magic chip fixes everything with no drawbacks, giving "jitter free playback".

Without going into the technicalities, the basic way an ASRC works is by doing high rate interpolation followed by a decimator, the coefficients of which are generated on-the-fly, based on the ratio between input and output. These coefficients therefore change over time as the two clocks drift ( as they cannot be "locked" together, or why use an ASRC? ). So, you have a system whose frequency and impulse response cannot be guaranteed at any one time, all you can guarantee is that they will change ( slightly ) over time - all to improve the measured jitter performance, as opposed to overall filter performance.

 

ASRCs are fantastic things for their intended application ( dealing with signals from different clock domains with ok performance ).

 

Jitter is a real, measurable problem in digital systems. It's definitely not the only one, or even the biggest, and source-induced jitter can be cured by any of the solutions where the DAC clock can drive the source (e.g. Async USB, Ethernet, Firewire, clock back to the source ). Sticking something in that negates all of these solutions and causes it's own seems the wrong approach to take,

 

your friendly neighboorhood idiot

 

 

 

[barrows]

Agreed with idiot savant: ASRC should be avoided for best sound, Some are probably better than others, but in my experience they always seem to muck up the sound (I have not heard the built in ASRC in the ESS yet). IMO the best approach is to not generate the jitter in the first place, rather than allowing it to exist, and then trying to reject with a DSP solution like an ASRC.

Maybe Gordon will correct me here, cause I'm am not entirely sure about this, but I think there are also some drawbacks vis a vis sending the DAC clock back to the soundcard, and accepting an SPDIF (or AES, which is really just balanced SPDIF) interface. The DAC clock can be very accurate on the PCB at the DAC, but this accuracy will be lost when sending it back over a cable to the soundcard-the clock signal is an analog signal, and will be subject to cable losses, reflections, and all the other problems we associate with SPDIF connections. The other problem is that we are now still dealing with the flawed SPDIF interface, this signal needs to be sent through an SPDIF receiver, and the clock stripped out, and then needs to be re-synched with a PLL, and converted to I2S to feed the DAC-so jitter will creep in from inaccuracies in the SPDIF receiver and the PLL circuit (although I certainly agree that this approach, assuming a low jitter clock in the DAC, should outperform relying on the local clock on the soundcard).

Locking a bunch of devices together to a single master clock is essentially a studio technique, which needs to be done in recording, because there can be many different components that all need to have the same clock reference-unfortunately, the recording process and recording engineers usually are willing to accept much higher jitter levels than an audiophile would. Typically, recording engineers will consider jitter levels below 1 nS acceptable, and audiophiles would really like to see sub 100 pS jitter levels. Yes, I realize there are some engineers that are concerned with achieving less jitter than the levels I have mentioned above, but they are still in the minority.

I think we really should consider the advantage of using a computer for playback: we do not have to use the inherently flawed SPDIF interface (and AES is the same thing). When the music signal is just data, there is no (critical) timing reference, so we should keep the music signal as data for as long as possible, bringing the data to the DAC and converting it directly to I2S, with a local fixed frequency clock (or two to cover the two different base sample rates) and then sending this to the DAC (via the filter/oversampler of the designers choice). ASYNC USB, Firewire, and networked interfaces all allow one to do exactly that, and when inplemented properly, will result in very low jitter levels at conversion.

 

[glt]

Actually, according to a fellow that presented a tutorial at diyaudio (also co-founder of Silicon Labs), unless you can slave everything to a single clock, the next best way to attenuate jitter is the use of ASRC. There is no magic, just math. It is not that the clocks "cannot be locked" but that there are two clocks -you cannot lock the clocks and therefore by definition, the sample conversion is asynchronous. I have a pointer to that thread in my blog and also summarized the main points.

 

[idiot_savant]

strictly speaking, if you can't slave everything to a single clock, you NEED an ASRC... ( clock could be in transport, seperate master clock or DAC ). There is no reason in hifi systems why you can't lock everything together one way or another. If you decide you use an ASRC you CANNOT lock the clocks together ( because then you would have modified data by the ASRC process, plus jitter fed through from the input to the local clock ).

ASRC ( as I said earlier ) _appears_ to be magic - but the maths used are based on approximations, which change over time. As with anything else, it's a different set of compromises.

Additionally, if you use an ASRC you are introducing two unrelated clock domains somewhere that is very sensitive to noise ( the analogue out of a DAC ) - the two clocks ( the DAC clock and the derived input clock ) will "beat" against each other - again, in a random fashion due to the non-locked scenario, which considering most manufacturers strive to have a single clock domain ( usually by having 2 crystals, only one of which is on at a time ) seems to be a retrograde step.

 

As regarding to the original thread on diyhifi, does the guy there not say that the thing chooses between different coefficients on the fly ( which I alluded to earlier )?

 

your friendly neighboorhood idiot

 

 

 

 

[Audio_ELF]

Whatever the pros and cons of ASRC there is no doubt that it's best if you can avoid jitter in the first place, rather than trying to engineer it out later on...

 

[idiot_savant]

Agreed.

Sorry, I get a bit carried away I get stuck into a couple of things. ASRC is one of them

 

your friendly neighbourhood idiot