Interface woes

[G_Steven]

I would appreciate it if someone could explain to me why the DAC interface matters at all in a well designed DAC. If I can get a bit perfect copy across any sort of connection, it would seem as though the DAC would have the responsibility of buffering the data internally and using it at the EXACT correct moment in time from the buffer NOT from the interface. I could make the buffer many megabytes in size if I chose to thereby smoothing out several minutes worth of jitter! Given then, that the bit is of the correct value (and in the right order of course) and it is handed off to the converter at the correct moment from the internal buffer, why should it matter at all what interface is used to transport it?

 

Clearly I'm missing something here...

 

[cfmsp]

 

"it would seem as though the DAC would have the responsibility of buffering the data internally and using it at the EXACT correct moment in time"

 

Steve, I can sympathize with you.

 

The short answer is - until Gordon 'discovered' Async USB (for audio), there was only one protocol (Firewire) which operated in the manner you describe, to wit, giving the responsibility for determining the EXACT correct moment in time TO the DAC (i.e., using the clock in the DAC as master) as opposed to the Source component.

 

Unfortunately, only Pro audio companies manufacture Firewire DACs (probably due to the need to write OS specific Firewire drivers in order to use the Asynchronous mode of Firewire). By and large, Pro audio DACS have low WAF (with the possible exception of Weiss), plus many audiophiles have poor opinions of Pro audio gear, despite (or perhaps because of) the fact that recordings are necessarily created using pro audio devices. Suffice it to say, even now, there are only a small handful of devices which appeal to audiophiles that operate asynchronously (with the master clock in the DAC, rather than at the source).

 

Some people consider some of the network players as functionally equivalent. I use Firewire, and don't know much about the network players, except that they are NOT all created equal. If I were looking for my first high quality DAC, I would likely only consider Firewire or Async USB. I'd start by having a listen to Gordon's Proton or Brick (if you don't mind tubes).

 

Hope this helps your interface woes.

 

Clay

 

 

 

 

[The Computer Audiophile]

Ho G_Steven - I am certainly a member of the Armchair Engineers group and consider myself a novice at best when it comes to the very technical workings of DACs. However, I think you've oversimplified how DACs work. There many things that take place and decisions to be made by DAC designers that make a product handle jitter and sound good. DACs are certainly nothing new and I'm willing to bet the method you propose would have been done by many designers over the years who've built AES and S/PDIF interface DACs.

 

Just my thoughts. Could be totally wrong or just somewhat wrong :~)

 

[G_Steven]

Thank you Clay,

 

Your description of the problem makes sense as far as it goes, but I still don't understand why the computer has to be in control of the timing. Just as a thought experiment, (reality actually) I could copy the music to my iPod via USB and play it hours later. Clearly my PC or MAC has no influence on my iPod listening experience unless it sent corrupted data. If Apple can make an iPod so cheaply, complete with its proprietary internal interface and DAC, why can't the audiophile manufacturers re-clock the data by means of a buffer?

 

Still confused...

 

[zerung]

Steve,

My Caveat is I have a doctorate in arm chair engineering Hence it goes rather like this - in all humility:)

 

The interface has been the slave to the advancement of digital audio via the computer realm. The interface have never been designed to offer the best digital output. The best one I have heard about is via the PCI card with Lynx card. Next the use of firewire with suitable driver is again required to make the interface useful. USB has been one giant problem due to the democratic, free for all protocol . Wavelength succeeded in milking suitable signal from the computer due to their asynchronous USB audio protocol has helped as this has allowed for the master clock to reside in the DAC and the data fetched to the DAC where the jitters and the audio signal is suitably converted to analogue signal. Generally one could to say that a well design DAC has a well designed interface. Or has tweaked the maximum from the interface.

 

I dont think the computer manufacturer are interested in making the output any better as this will add cost and there are not enough profit margin to be had for a niche market. Hence this is left to the DAC manufacturer to sort out the problem.

My 2c.

 

[G_Steven]

Thank you Zerung,

 

I think I get it now. In order to utilize the interface as it was intended, the DAC has to "follow the rules" of the interface even if the "rules" are bad. I guess my question is more philosophical then: Why don't DAC manufacturers use the fille directly like my Alpine car stereo head unit (which truly sucks by the way) does? I can insert a thumb drive into it and it will play music by reading the file directly. The head unit then becomes responsible for its own timing. In other words, why should they use the interface in the conventional manner that you have described, why not just use it to transport the file and do the rest of the work internally?

 

Less confused but more disappointed...

 

[Mr.C]

They are doing this in a few situations like firewire, Async usb, and the network players (Sonos, Squeezebox, and soon to be PWD with bridge). I think that DACs were and still are built primarily for use with a CD transport or on the pro audio side of things. Because the audiophile demand is focused on cd transports, most of which output s/pdif, the other parts and technologies are on a development track that has started later. We'll get the technology, we just need to be patient for it to become mainstream. BTW, the Chord dac uses a FIFO buffer I believe.

 

[washington678]

This is an interesting discussion.. thank you for sharing.

 

 

 

taux pret auto

 

[Audio_ELF]

This thread actually echos another which began discussing the use of i2s between "transport" and DAC.

 

The idea of a buffer is used in a few devices that I know of ... the two most famous are probably the Chord (originally DAC64, now QBD76 and also devices built around these) and the Genesis Digital Lens device - a stand alone buffer you connected (via SPDIF) between a transport and DAC. The Digital Lens looks to be built into the PS Audio PerfectWave Transport.

 

Eloise

 

[cfmsp]

 

eloise,

 

In your mind, is this 'buffer' significantly different than say, the way Async USB or Firewire manages the underflow/overflow of data in it's 'staging area' (I was looking for a different word to use than 'buffer').

 

just curious,

clay

 

 

[Audio_ELF]

To my thinking, it would be better to avoid jitter by using async USB or FireWire rather than trying to eliminate it after using a buffer. However it's very difficult (maybe impossible) to compare as no dac with FireWire also has a buffered spdif connect (afaik). No one can even truely compare async USB to SPDIF except possibly with dCS Scarlatti Upsampler as I'm unaware of any other async USB device that also has SPDIF. As has been said before, comparing interfaces is ultimately pointless as different companies spend varying effort on them. Really the only question is "on this device, is FireWire better than AES"

 

sorry for my rambling - on iPhone and walking dog

Eloise

 

ps that was nothing to do with clays question which I misread ... I've always thought of the buffer in FireWire to contain 16 or 24 bit packets of data (i.e. a full sample) where as in the dac it store individual bits to be read one by one according to the DACs clock.

 

[cfmsp]

 

Eloise,

 

I think I"m with you. The buffers you're referring to are somewhat, shall I say, gratuitous, or nonobvious, in the sense that they're not needed per se, but are being utilized for a specific purpose, such as the Digital Lens goal of creating a separate data file (from that read by Laser, e.g.) for purposes of applying a 'clean' (read Asynchronous) clock to the data prior to transmission (via I2S, or AES/SBU or its variants).

 

Just a thought,

clay

 

 

 

 

 

[Audio_ELF]

I'm not sure if this was what you were already saying clay ... but I think the buffers in a FireWire (or async USB) interface would not be obvious to the end users ... a few samples in size, however the buffers in the Chord (and similar in the Digital Lens) actually add a couple of seconds latency to the audio - with the Chord it really is that obvious.

 

The difference between the Chord and the Digital Lens (as I see it) is that the Digital Lens sits in the PWT transport (or a separate box) and so is subject to jitter / timing issues between the output of the Digital Lens and the input of the DAC. On the other hand, with the Chord QBD76 (and before) the buffer is part of the DAC after the SPDIF receiver. (More on the Chord DAC Technology - http://www.chordelectronics.co.uk/chord_tech.asp?view=dac - much of it came from dpa I think)

 

I guess I would think of the "music" as it's passed over the FireWire interface, from process to process within the computer, etc to be classed as DATA - that is without any timing information. Once it's converted to SPDIF, then I would refer to it as a SIGNAL and it's subject to jitter, etc as it is timing dependent. My own definitions (of Data and Signal) might not have any meaning to others but it's how I sort it in my mind.

 

Eloise

 

[cfmsp]

 

 

"As has been said before, comparing interfaces is ultimately pointless as different companies spend varying effort on them."

 

Certainly comparing interfaces within a single device is not likely to be comparing the best implementation of an interface with the best implementation of another (unless you're talking dCS prices).

 

Reading the PS Audio forum recently, I'm surprised at how easily Paul McGowan seems able to sidestep concerns about the quality of his (Centrance-based 'adaptive') USB implementation in the Perfect Wave DAC. Admittedly - per Paul and reviewers - it is NOT as good as the other inputs, yet there are still a number of people on the PS Audio forum considering such an expensive device for long term use as a USB DAC. It seems all Paul had to say is that his USB implementation is 'as good as it gets' to calm the restless 'natives' (metaphorically speaking) despite having said (incorrectly in my view) that USB will never be as good as I2S / AES/EBU, et al.

 

clay

 

 

 

 

 

 

[cfmsp]

 

"I think the buffers in a FireWire (or async USB) interface would not be obvious to the end users"

 

I wasn't thinking in terms of obvious to the user, but obvious in the likely possible design scenario. E.g., it's obvious that in Firewire, with a clock telling an upstream source when it needs more/less data, that some sort of buffer is involved. It's not obvious that a buffer is required in the examples of Chord and/or Digital Lens.

 

"My own definitions (of Data and Signal) might not have any meaning to others but it's how I sort it in my mind."

 

I used these same definitions in another thread - in a discussion with Mr. C I think. So, I'm with you.

 

clay

 

 

 

[Audio_ELF]

clay said... "obvious in the likely possible design scenario. E.g., it's obvious that in Firewire, with a clock telling an upstream source when it needs more/less data, that some sort of buffer is involved. It's not obvious that a buffer is required in the examples of Chord and/or Digital Lens."

Do you mean when designing a firewire interface, its obvious that some form of buffer is needed, however in designing a DAC, it's a bit of an intuitive leap that adding a buffer, in the way Chord QBD76 does, is going to allow for an improvement in sound quality?

 

Eloise

 

[cfmsp]

 

"Do you mean when designing a firewire interface, its obvious that some form of buffer is needed, however in designing a DAC, it's a bit of an intuitive leap that adding a buffer, in the way Chord QBD76 does, is going to allow for an improvement in sound quality?"

 

Yes.

 

 

 

[Audio_ELF]

Eloise