Best Low Jitter feed for external DAC

[jkeny]

What's the best way to get a low jitter feed to an external DAC?

 

Because of the need for lowest jitter, I believe the following applies:

- avoid SPDIF; prefer I2S

- avoid internal PS; preferred extrenal PS

- avoid internal clock unless it's low jitter; preferred external synchronous reclocker feed from low jitter clock with low noise PS

 

So, my thinking is to:

- use a fanless PC (FIT-PC) connect by wire to the network

- use a linear PS to power this

- use a USB DAC that uses asynchronous mode

- mod it for external PS (if needed)

- mod it for better clock or external low jitter reclocker

- mod it to tap I2S as the feed to the external DAC

 

Am I talking about a Squeezebox modded with a John Swenson reclocker or are there other/better/cheaper options?

What about modding a asynch USB DAC:

Edirol UA-1EX (asynch?)

Tascam US-122

EMU 0202

 

[Mr.C]

The Juli@ card apparently has an easy mod to get an i2s output. The Stello DA100 Signature and Northstar dacs have i2s inputs.

 

That being said, I'd caution that i2s is like the rest of the digital signals: it isn't necessarily the format that makes it better (although it seems to enjoy an inherent advantage), but it is the implementation of the format that makes all the difference. Just look at the difference in USB dacs/converters, or at the ~$60 Teralink-X converter that does usb to i2s. As Gordon Rankin pointed out, the usb chip is jittery which passes the jitter to the i2s clock signal. The same goes for adding an i2s receiver to the DAC. Of course, I'm a big hypocrite because I'm considering doing exactly the same thing as you (having a dac modded for i2s input).

 

 

 

[Audio_ELF]

i2s was designed for transmitting signals over the mm distances between ICs on circuit boards (i2s means Inter-IC Sound) not over tens of CM between devices. If the signal cables are not parallel and exactly same length then quality can be much worse.

 

For the technical details Gordon @ Wavelength is much better plaed and this has been his advise in the past. The same advise is also published by at least one high end manufacturer.

 

Eloise

 

[jkeny]

The Juli@ is a PCI card, I think? I wanted to stay away from these as they run off the PC's PS & I don't believe are easy to change to external PS - but I could be wrong with all this?

 

As you said it's important how the I2S signal is realised but the inherent advantage of I2S is that the clock signal is carried on a separate wire as is NOT the case with SPDIF

 

Another criteria that I forgot was to galvanically isolate the digital feed to the DAC.

 

I've seen somewhere (but can't remember) the idea of using a synchronous reclocker and the card delivering the digital signal over optical Toslink to the DAC because the higher jitter doesn't matter with the reclocker The advantage being it conveys galvanic isolation from the PC.

 

Edit: Elouise, has this distance been established? I've heard reports that 10s of cms is fine! Once the clock signal 's integrity is maintained, I think it's OK. This would entail giving the cable & terminations more consideration than is usually afforded to SPDIF signalling but this is no bad thing

 

[idiot_savant]

I would agree that PCI cards have problems with being supplied by a PC PSU, together with a lot of RF type

noise that would be hard to eliminate, although the Juli@ seems to be well received.

 

I have also become intrigued by the current trend for using I2S to connect together DACs and transports, so I've had a look at some measurements for systems using I2S as the transport->DAC interface, and found that they actually tend to offer much worse jitter performance than "standard" boxes using SPDIF. For example, the Zanden ( which seems to have started the craze ) has been measured in stereophile as having 1018ps of jitter ( http://stereophile.com/cdplayers/1106zanden/index4.html ), compared to something of about the same era using SPDIF, e.g. the Grace Designs m902, which has 405ps of jitter ( http://stereophile.com/headphones/406grace/index3.html ).

I think the issue is that most people say the key to jitter performance is having the clock right next to the DAC chip, whereas with a longer I2S cable this is obviously a long way from the DAC chip. Again, this would seem to depend very much on the implementation used, but it would imply that a well done SPDIF interface will measure better than a poorly done I2S interface.

 

 

[audiozorro]

If I use the top DAC in the CASH List, all I care about is what is the best feed for that DAC to maximize SQ.

 

The current top dog seems to be the Berkeley Audio DAC and I would feed it with the recommended Lynx AES16 I/O PCI card. On the other hand the excellent Weiss Engineering DAC would be feed through the firewire connection.

 

One of DACs that I have, is a Benchmark USB DAC1 (4 inputs) that is fed by a Lynx AES16 card from an XP music server, fed by a Juli@ card through coaxial connection from a Vista music server, and connected to my MacBook Pro computer (not a dedicated music server) through either the toslink or USB connections. The only connection I wish the Benchmark had is a firewire input so I could get better than 24/96 out of my MacBook Pro with OS(X).

 

What sounds the best? Well I've been so impressed with cMP/cPlay and Amarra lately that tend to believe that after excellent source material, the software playback engine may be far more important than these other considerations, not that I don't think that good power and low jitter aren't important.

 

[idiot_savant]

I would agree that the Berkeley/Weiss look to have very good performance - I don't know, I've never listened to either... I'm uneasy about the ASRC inside the Benchmark, although, again, people swear by them...

 

On the other hand, while I can see that it is easy to corrupt the audio going from a PC or a Mac to an external DAC ( k-mixer, going through Vista/OSX SRC ), I don't understand how two playback engines playing back the same audio being bit-perfect can sound different - as I understand it, there is a lot of buffering between the playback engine and the output. Again, I've not heard Amarra, or cPlay, so I can't say they aren't any better, but I can find no logical way to explain it being better - surely bitperfect means the data from the original source material is passed to the DAC without any change?

 

 

 

[soren_tyson]

Hi,

 

Reg. the comment to have firewire input into the benchmark, I also have a benchmark but I have the understanding that everything is resampled to 110kHz internally. So I doubt that we would benefit from anything above that?

 

The 110kHz is mentioned in this review:

 

http://www.stereophile.com/digitalprocessors/108bench/

 

Best regards

 

Soeren

 

[jkeny]

OK, I hear what you are saying about the jitter figures but there are too many questions about these measurements to go into here. Suffice to say that a single jitter number is meaningless, however if these tests were done with the same equipment and conditions then they can be used to show the relative level of jitter from the two different DACs. Best test would be to compare the jitter figure from a DAC that output both I2S & SPDIF in order to draw any conclusions.

 

Ah, Audiozorro, this is another piece of the jigsaw altogether, and I stayed away from mentioning it in order to focus on how best to retrieve the audio signal

 

[cfmsp]

 

jkeny,

 

that we all have access to the same stuff (products/info/etc), and come to different conclusions, and yet can be happy with the sound, certainly supports the argument that there are many successful paths.

 

That said, I hope I don't annoy you by challenging a couple of your assumptions.

 

First and foremost, my belief is that the simplest path to success with computer audio is to get a dac with a very good internal clock, the good ones do NOT need to rely on ASRC to reduce jitter.

 

I'd also avoid S/PDIF (in all it's varieties), but I prefer Firewire. Async USB also works, BUT, is essentially just an attempt to get USB to behave like Firewire (as an interface between computer and DAC).

 

either way (Firewire or Async USB), having a good clock in your DAC, and using it to control the flow of data from the computer, eliminates the need for upstream clocks/reclockers.

 

If you don't have a good internal clock in your DAC, then you're probably wasting money putting a 'better' clock, or reclocker, in front of it, IMO.

 

FWIW, I did upgrade the power supply of my 'pro audio' DAC.

 

enjoy

 

 

 

[audiozorro]

IMO generalizations and only one way philosophies very often lead to wrong results and conclusions. Does a NOS DAC sound better than a Upsampling DAC? Sometimes yes and sometimes no. Are you more concerned with jitter or digital filtering or heavens forbid, how good the DAC sounds?

 

The top DACs in the current CASH List are Upsampling DACs. Is it better to manipulate your audio data in the DAC hardware or the player software? Is the approach taken by Benchmark Media to resample the audio data to 110kHz, the sweet spot for the internal DAC chip they use and their design the right approach? Do memory players such as cMP/cPlay and XXHighEnd sound better than non-memory players? Does the cMP/cPlay approach to minimize computer noise, load and unnecessary computer hardware and software operations produce superior sound results? By the way most users of cMP/cPlay are upsampling so audio data by definition is no longer bit perfect. Questions abound over what Amarra is doing, but you won’t find anyone who says soundBlade or Amarra don’t sound excellent.

 

You could ask who is the better athlete – the athlete that smokes several cigarettes each day, eats whatever, trains hard and is naturally gifted or the athlete that doesn’t smoke, follows a healthy diet but doesn’t train as hard or isn’t as naturally gifted? Let’s also pollute the bit perfect athletic abilities by introducing performance enhancing drugs, now who’s the faster, strongest athlete?

 

Sorry to digress, I only mean to say there are often no simple answers or only one way of doing things in digital audio. Audio designers should naturally labor over these issues but most audiophiles often only care what sounds superior. Implementation is everything.

 

 

[jkeny]

cfmsp,

You don't annoy me at all - I'm here for open discussion & learning.

I agree about having a very good internal clock in a soundcard but I don't know of one - can you nominate some?

The only asynch USB cards I know are the ones in the first post & I don't think any of them have great clocks but I may be wrong?

 

Edit: Audizorro, I'm a tweaker with just enough knowledge to be dangerous who likes to think he can improve things so just buying a soundcard is not what I'm interested in

 

[audiozorro]

I only use an internal soundcard to get 24/176.4 and 24/192 digital out to my external DACs. I was happy with my MacBook Pro and DACs until I took the CA challenge to build an "Audiophile Reference Music Server For A Song". Actually I wasn't happy (are audiophiles ever happy?) with my Apogee and TC Electronic firewire DACs that provided 24/176.4 and 24/192 output from my MacBook Pro and guaranteed efforts to get 24/192 digital out were too expensive ($3K Mac Pro with Lynx or $2.5K Mac Pro with $2.5K Weiss DAC2). The PC Windows challenge was too cheap to pass up, even with the Lynx card.

 

For those who like it simple, easy and don't like to experiment, buy a Mac, the Amarra software and the best DAC your budget allows. Even though I didn't feel that the Apogee FW Mini DAC was better than my Benchmark DAC, it still sounds very good, it is a little less expensive and it has 24/176.4 and 24/192 firewire digital inputs. Both the Apogee Mini DAC and Apogee Duet (limited to 24/96) have gotten excellent reviews and this is before Amarra. Assuming Amarra supports these DACs, the combination of Amarra and these Apogee DACs may be hard to beat without spending several thousand more dollars.

 

[cfmsp]

jkeny,

 

I can't help you out with internal soundcards. apologies.

 

I'm of the belief that, using Firewire or Async USB, special purpose soundcards aren't necessary.

 

I run firewire right out of my Mac's firewire port, via internal 'soundcard' (a misnomer?).

 

I'd do the same into one of Gordon's USB DACs.

 

I'll bow out here, as I'm not much of a tweaker these days.

 

enjoy

 

 

 

[jkeny]

cfmsp do you know of DACs with good clocks apart from Gordon's?

 

[blueixus]

There is a very neat USB to 12S/SPIDF made by DDDAc. It also has a NOS Dac on board. I have used this and it sounds fantastic, caveat is that is limited to 48kHz. The implemetation is very thorough - it has completely transformed my view of itunes.

 

Regards

 

[cfmsp]

 

jkeny,

 

I have no way of testing 'clock's, but in as much as the clock quality is absolutely critical for professional audio recording devices, that's where I'd start. I believe devices that are well regarded in pro audio forums include Apogee, Metric Halo, Prism, RME, Benchmark, etc. Lavry is a strong believer in quality of the internal clock, but, alas, no firewire or async usb, as far as I know. Neither does Benchmark.

 

I use a Metric Halo ULN-2, which is a pro audio ADC/DAC with high quality mic preamps for professional audio recording. I also occasionally record, so I didn't get this just for the DAC, but some do. John Atkinson (Stereophile) uses it for recording on location. It's practically unknown in the audiophile community, but well regarded in pro audio circles.

 

Don't be afraid to buy pro audio gear that has more features than you might need. Margins in pro audio are 'shit', especially as compared to audiophile-specific brands.

 

I paid $1500 I think for the ULN-2 2-D. YOu can find them used on ebay / gear slutz / etc for much less than $1000. the 2D has every possible input except USB (USB not being a pro audio interface). Now would be an especially good time to consider as Metric Halo have just released the ULN-8 (8 channels of the highest quality sound on the planet), and so many are selling their ULN-2 to upgrade.

 

 

 

 

[usernaim250]

I've heard good things about the TC Konnekt8, which is a (cheaper) firewire interface. TC developed the "JET" technology that Weiss licenses, but it is in the $300 Konnekt8. The recommendation I've heard is to use the Konnekt8 via firewire and run spdif from it to your DAC.

 

[barrows]

Best interface between computer and DAC is: choose one,

 

Network player, the king of these is the Linn DS, the drawback of the network player is that it requires the company that develops it to also develop their own GUI, because the GUI is part of the system. The big benefit of the network player is that it is not really a streaming device-audio files are sent over the network as data, and as such are not time dependent. Done properly, the network interface is entirely immune to jitter issues, the only relevant jitter being the jitter that is inside the player itself. A network player is very hard to develop, as it basically requires an OS of its own, and is essentially a bespoke computer at the receiving end. Very few audio companies have the resources to develop this type of player. Network players have the further advantage of allowing storage to be physically distant from the audio components.

Async style USB: like Wavelength, Ayre QB-9, and dCs. These devices reduce jitter in data transmission from the computer to very low levels, by making the clock in the DAC the master clock for the whole system. By having a fixed frequency clock in the DAC control the whole system, including the transfer of audio data from the computer, jitter is reduced to very low levels. Drawbacks: currently these devices only support files of up to 24/96, and cannot handle higher resolutions, computer must be close to the audio system.

Firewire: As with Async USB, properly implemented Firewire interfaces allow the clock in the DAC to be the master for the whole system, resulting in very low jitter levels. Firewire interfaces are also capable of handling all resolutions of audio up to 24/192. The only drawback is that some computers do not have Firewire interfaces, and some Firewire chips are not adequate to interface with every Firewire device available.

It seems to me, that when high end computer audio matures, the interface of choice will be networked. The network connection offers so many advantages, that the company that comes up with a network player with a great GUI, complete compatibility for file resolutions and formats, at a reasonable price, is going to do really well. This may take awhile, and it may take a computer company to make the interface part of the design, and then provide the interface to audio companies who then combine the interface with their own DAC circuitry.

 

[jkeny]

Thanks barrows,

A great synopsis

 

[usernaim250]

Great post. Would it be possible for several high end companies to band together on the programming for the network OS/UI and just keep the hardware proprietary? Or will we just wait for someone to write something good that they are willing to license?

 

[Audio_ELF]

Have one name for you w.r.t. interfaces on "network" clients ... Meridian / Sooloos. They've got it cracked but it's more of a unified system (ripping and playback) than Linn's UPnP clients. Another good interface goes to the Naim HDX but again it's mostly a standalone device rather than network player - though it will play from network and can supply data to other "NaimNet" devices.

 

If only iTunes was a UPnP server / controller ... Would be perfect solution to combine iTunes with a Linn DS. Curently the Available UPnP controllers are quite limited, though there is a new iTouch / iPhone controller for the Linn DS that looks hopeful as a good solution.

 

Eloise

 

[cfmsp]

usenaim,

 

probably the latter, and even that's sketchy, IMO.

 

My rationale:

 

Audiophile firms, in general, seem to be uninterested in writing ANY software, let alone something as significant as described above. Audiophile firms have moved away from a perfectly good interface that was designed (at least in part) for transmission of audio data, because Firewire requires special-purpose driver software be written and supported. Indeed, this was (one of) Gordon's reason for working with USB instead of Firewire.

 

If an audiophile firm writes something this significant, I doubt that we'll see it in anything other than the multi-kilobuck category. E.g., the audiophile firms that do write significant software don't seem to license it to others, but use it as competitive advantage and try to recoup cost themselves, e.g. Meridian, dCS, etc. (Although dCS did license the RingDAC to Arcam, so perhaps my 'generalization' could be wrong.)

 

I won't disagree significantly with Barrows post above, except to say, I don't see myself likely to pay a premium (let alone one measured in thousands of dollars/euros/etc.) for a network OS/GUI/player solution for the simple reason that, the effect of jitter prior to arrival at the DAC has been substantially eliminated (by Async USB and Firewire devices), and even in a network/player, there will STILL EXIST jitter in the conversion from Digital to Analog, just as it does in current best in class DACs. Until a chip/device/circuit comes along which can totally eliminate the jitter at the time of conversion, I don't see a significant advantage over Async USB or Firewire.

 

That said, the advantage that the sort of networked/player (that Barrows described) may have is this: it will be a turnkey system with control over ALL aspects of the computer-based audio system, and thereby will be able to tune (albeit permanently) every element of the playback chain (barring those subject to outside influence, such as EMI). IOW, we'll come full circle, and eliminate the tweakiness of current computer-audio music playback.

 

thoughts, anyone?

 

clay

 

 

 

 

 

 

 

 

[Audio_ELF]

Well you can give yourself a +1 as I quite agree...

 

High quality UI exist from audio companies only in high end products such as Naim HDX or Meridian / Sooloos system at multi-thousand pounds. Other than that it's UPnP type interfaes which are limited.

 

Not sure if dCS licenced to Arcam, or if they produced DAC ICs attempting to compete with Burr Brown, etc.

 

Eloise

 

[cfmsp]

 

 

"Not sure if dCS licenced to Arcam, or if they produced DAC ICs attempting to compete with Burr Brown, etc."

 

I don't recall either Eloise, despite being the proud (and still) owner of an Arcam CD23 when it first hit the market many years ago. I'm fairly certain that the RINGDac was an 'approximation' of the processing offered in dCS' upmarket devices, but can't remember exactly how it was incorporated.