Firewire cable quality/length influence on sound quality

[TheZephyr]

I have heard a great deal of debate about whether or not digital cables influence the sound. I understand that a bad cable can cause complete failure, but as I am an actual computer engineer I have my doubts that a 'high end' digital cable can provide better sound than a standard fully functional cable.

 

I have a Weiss DAC 202. These DACs feature a bit perfect indicator as well as bitrate and depth display, so it is easy to determine whether or not the DAC is receiving perfect data, this makes it easy to determine whether or not your digital cable is fully functional.

 

I am happy to say that with this DAC (which can use it's internal clock for timing), that an el-cheapo 30 foot long cable works perfectly at every rate including 24/192. Be aware that the firewire spec requires that cables be a maximum of 15 feet long, so the cable I used is out of spec to begin with, but it still works perfectly.

 

[AudioExplorations]

In theory the cable should not play a role however in practice we find that it does and that there are audible differences between different cables. As the stream is bit-perfect current best knowledge is that it is due to cable's effects on jitter (which is difficult to believe due to the way weiss dac's handle/suppress jitter).

 

Additionally the removal of the power transmission within the cable has been said to improve the sound (achieved either through use of a 4-6pin firewire adapter, covering up of the power terminal with electrical tape, or snipping of the power wire within the cable).

 

I am sure any firewire cable "works perfectly" in the sense that the signal is transmitted and we get sound of the DAC, however some cables work more "perfectly" than others . There are numerous threads on this topic on this site.

 

[wgscott]

Apart from +/- galvanic isolation, is there a clear physical reason why one firewire cable might trump another?

 

I was rather surprised that different optical cables, all of which "worked", had genuine differences. I still don't really grasp why this might be the case.

 

[TheZephyr]

I have seen the numerous threads on this site, I understand the nature of the debate. What may not be understood by some is the nature of an asynchronous connection. In an asynchronous connection the sink receives data in chuncks, not in a stream, and plays them at it's own rate. Much like filling up a gas tank and then emptying it by driving, the jitter of the gas pump has no influence on the driving performance. Jitter of the cable in this case is 100% irrellevant, to hear the influence of the cable in this case is to have an active imagination.

 

[wgscott]

There are also those who make a case for jitter being inaudible.

 

[AudioExplorations]

You are exactly right about the workings of an asynch connection, I was aware of this and jumped the gun on that post...

 

Anyway, have you tried different cables or are just just dismissing differences based on reason?

 

[TheZephyr]

"Anyway, have you tried different cables or are just just dismissing differences based on reason?"

 

Yes, the audiophile in me enjoys all manner testing and tweeking. I have spent time and money on interconnects and noticed huge differences there and ended up with some fairly exotic cables. I have side by side home auditioned sets of speaker cables worth $6k and found a $60 pair as having the best sound.

 

For firewire I obtained a short length of a high end cable just to be sure the DAC would be usable as soon as I got it home. I set up the source computer next to the DAC for a short while.

 

I could perceive no difference in sound between the 'nice' cable and the cheapo on my very revealing system. Just as I believe that in some scenarios people are imagining improvements which do not exist, I realize that I may not have noticed improvements that did exist, so my listening test does not prove anything.

 

That said, the logic of the asynchronous connection in conjunction with my listening experience leads me to understand that for the specific case of the Weiss DAC 202 (and very likey other asynch capable devices) which is immune to cable/source jitter over firewire, a high end cable gives no benefit beyond that offered by a basic fully functional cable.

 

No doubt cables do have much influence on some other equipment. Even devices like USB printers can be rendered unusable by poor cable.

 

 

[elcorso]

TheZephyr,

 

Yes we 'audiophiles' have a very active imagination, but you must also consider the placebo effect, and I feel like you there are very expensive 'audiophile' cables with the worst SQ than some inexpensive ones. Then, I don't like to use cables as filters or equalization.

 

In the case of the Weiss DAC, you have a very good one, but his Firewire interfase is no asynchronous because of the Firewire cheap (Dice II interface), the only asynchronous is Metric Halo.

 

You can read this in this forum, from Charles Hansen of Ayre fame:

 

http://www.computeraudiophile.com/content/Asynchronous-USB-overhyped-solution#comment-76352

 

The firewire cables I use ('just to be sure') are inexpensive, but with very good construction, are the GOLD X from:

 

 

http://www.firewiredirect.com/product/89/

 

You will listen 'everything' with the CLX, I have the same speakers.

 

I have no interest nor connection with Firewire Direct, but they has good products and an excellent and fast service.

 

Happy listening,

 

Roch

 

[SteveChicago]

FWIW, I've been using the FW cables that came with my Glyph external and they work just fine. As long as the FW cable has decent shielding, I can't see the point in spending $$ on these cables. That's one nice thing about FW...

 

[losingmyreligion]

"...for the specific case of the Weiss DAC 202 (and very likey other asynch capable devices)..."

 

The early beliefs (on CA) that most Firewire devices were Asynchronous in nature have been found to be incorrect.

 

Given the DAC202's lack of fixed rate oscillators for each frequency set (one for 44.1 & multiples and another for 48k & multiples), and it's concommitant use of PLLs for syncing of clocks (rather than reliance on a fixed rate oscillator in the DAC as master clock which is a hallmark of truly asynchronous devices), it is debatable whether it should be considered asynchronous.

 

There's also another flaw in your assumption that Asynchronous devices are immune to jitter from ca ble, esp, that asynchronous USB devices remain quite cable dependent.

 

Perhaps your DAC is immune to jitter (aren't they all claimed to be?), but claiming immunity by dint of an Asynchronous transmission is suspect.

 

 

 

 

 

 

 

[TheZephyr]

"Given the DAC202's lack of fixed rate oscillators for each frequency set (one for 44.1 & multiples and another for 48k & multiples), and it's concommitant use of PLLs for syncing of clocks (rather than reliance on a fixed rate oscillator in the DAC as master clock which is a hallmark of truly asynchronous devices), it is debatable whether it should be considered asynchronous."

 

It has an internal clock for use with the firewire interface, it does not use a PLL for that interface.

 

"There's also another flaw in your assumption that Asynchronous devices are immune to jitter from ca ble, esp, that asynchronous USB devices remain quite cable dependent."

 

So are you saying that a device which fills a buffer in bursts and then empties it by a clock will conserve the information of input jitter in the buffer?

 

"Perhaps your DAC is immune to jitter (aren't they all claimed to be?), but claiming immunity by dint of an Asynchronous transmission is suspect."

 

Perhaps I am not familiar with all the details of implementation of the DAC 202, and perhaps I am misinformed about the implementation being asynchronous (I will send an email to Mr. Weiss to find out). But I am an actual computer engineer, and I am quite certain that a buffer will not preserve jitter unless it is specifically designed to do so.

 

 

 

[losingmyreligion]

You probably want to refer to this thread for the online debate about this topic

 

http://www.computeraudiophile.com/content/Weiss-Engineering-DAC202-Review

 

My understanding is that while one could perhaps debate whether the Weiss Firewire interface is asynchronous in name (use of clock in DAC as Master), the primary advantages of such an interface are effectively lost by the Weiss's use of the PLLs in the DICE chip.

 

 

There are particularly relevant comments from Bob Stern, Gordon, Daniel, and an aside by BJ Buchalter (which I posted) in the review. Of those, only Daniel (seems to) believe that the Weiss interface is Asynchronous by the definition that CA has settled on. Daniel specifically mentions the use of PLLs in order to use only a single fixed frequency oscillator.

 

Below are Bob Stern's matter of fact comments.

 

"DICE II technical paper

 

The TC Electronic DICE II PLL chip used by the DAC2 and DAC202 is described in US patent 7,495,516 and in the following AES technical paper (which is easier to understand than the patent):

http://www.tcelectronic.com/Media/frandsen_travis_2006_clean_clocks_tc(1).pdf

 

The paper clarifies that the DICE II chip is a PLL that performs the same function as any other PLL. It is a specific PLL design, not a scheme for avoiding the PLL.

 

Any use of a PLL to extract a clock from an incoming Firewire or AES audio stream is completely different from the flow control and fixed master clock used by asynchronous USB DAC’s from Wavelength, Ayre and dCS.

 

Specifically, the paper states the purpose of the DICE II chip is to synchronize a local clock to the clock of an input stream, such as a Firewire 1394 isosynchronous input stream (see Abstract; sec. 1.1, last paragraph; sec. 2.3). The DICE II chip uses two cascaded PLL’s: (1) a digital PLL with a fixed master clock and numerically-controlled digital frequency divider, followed by (2) an analog PLL with a voltage-controlled oscillator. One of the stated advantages of the DICE II chip is to avoid the need for multiple fixed frequency clock chips (sec. 2.7).

 

This supports Gordon Rankin’s interpretation that, in Internal Clock mode, the Weiss DAC202 acts like an external master clock that sends a clock to the computer to regulate the timing of the Firewire audio signal, but the DAC202 then treats the incoming Firewire audio no differently than an AES signal. That is, the DAC202 uses the DICE II PLL to extract the clock from the Firewire audio signal the same way it extracts the clock from an AES audio signal.

 

(This interpretation is further supported by the existence of the Operation Mode / Stability setting in the DAC202 control panel software. This appears to control the parameters of the PLL. It would not be needed if the DAC202 were using a fixed master clock instead of a PLL.)"

 

 

If you refer to the review, you should skip the first 50 or so posts, and pick up with Gordon's post questioning whether the Weiss DAC202 is asynchronous.

 

You'll note that in multiple instances in this thread, Daniel refers to use of PLL.

 

I only responded to correct the common misconception (esp. among computer engineers) that Asynchronous interfaces eliminate the possibility for cables, or computers, to impact the sound. No one really knows why yet, but even with Async interfaces, both can make a difference.

 

Rest assured, you have a great sounding DAC.

 

enjoy

 

 

[TheZephyr]

"I only responded to correct the common misconception (esp. among computer engineers) that Asynchronous interfaces eliminate the possibility for cables, or computers, to impact the sound. No one really knows why yet, but even with Async interfaces, both can make a difference."

 

Thanks :-)

 

[TheZephyr]

Ok, so I got a response from the man Daniel Weiss himself and the 202 firewire interface is truly asynchronous. It reads blocks of data from the source into a buffer and then reads the words out of the buffer into the D/A converter clocked by the 202's internal clock. Since the buffer does not maintain any jitter information, all the jitter information is lost, and the DAC is immune to jitter on that interface. If the cable is able to pass the transparency test (not drop bits) then it is functionaly eqivalent to any other cable which can also pass the transparency test.

 

[snark]If you can hear differences of firewire cables on this DAC then you can probably also hear differences in music bits stored on different brands of hard drive on the source computer.[/snark]

 

[Audio_ELF]

Hopefully not putting words into anyone's mouth but I think maybe the "confusion" is that the definitions for asynchronous FireWire are different from asynchronous USB.

 

To be honest though... At the end of the day the terms and technologies used are irrelevant: the question is what sounds good.

 

People using facts like if a device is asynchronous or not usually use them to some way promote one device over another in irrelevant ways.

 

Eloise

 

[DaveLew]

So, if the way Weiss achieves low jitter is by buffering the data stream and clocking it out to the dac with a local zero jitter clock, why should USB be any different. Both interfaces can deliver data much faster then you need to keep a dac full. It seems to me that USB and FireWire can both deliver equally low jitter data.

 

[TheZephyr]

If I were to design a USB DAC today (and I actually did design and build a DAC before the CD was on the market) I would definately implement a jitter free input buffer. I do not know whether or not any of the current crop do this, I have not researched the market. I agree that there should be no difference in input performance at all between properly designed buffered systems.

 

[losingmyreligion]

"maybe the "confusion" is..."

 

The confusion has been discussed in detail in the thread on the Weiss DAC202 review.

 

In multiple instances, Daniel refers to use of PLLs to accommodate for use of a single fixed frequency oscillator in direct contrast to what Gordon (and others, e.g. Barrows, Bob Stern, et al) feel is a requirement for being considered a "truly" Asynchronous interface, specifically, the use of dual fixed frequency oscillators - one for 44.1kHz & multiples and another for 48kHz and multiples.

 

note: PLLs introduce their own jitter - above and beyond that of the oscillators - and therefore are undesirable.

 

 

Gordon asks:

"All async systems would require some sort of flow control so the use of a selected (dual) fixed oscillators can be applied to the dac. The dual frequencies required for the two separate sampling rate groups:

 

a) 44.1/88.2/176.4 = 22.5792Mhz or 2x, 4x depending on dac.

b) 48/96/192 = 24.576Mhz or 2x, 4x depending on dac.

 

One or the other oscillator would have to be selected when the node is told of a sample rate change.

 

Am I correct in my interpretation?"

 

Daniel replied:

 

"Gordon, if in that context "async" means that the DAC contains the master clock (for the sampling rate) and that the audio source is somehow slaved to that clock, then the Firewire scheme used in the DAC202 is an "async" one. [...] Also, the sampling rates, be it 44.1 and multiples or 48.0 and multiples, can be generated out of a single crystal oscillator with high precision and low jitter. Provided a proper PLL is employed. And that is what is used in the DAC202."

 

 

 

In any event, as I said earlier, the reason I posted in the first instance was to point out that Zephyr's claim that Asynchronous interfaces eliminate the possibility for cables to impact sound is direct contradiction with the (reported) experience of many folks here on CA, including Gordon Rankin, despite that their initial belief was consistent with Zephyr's.

 

Moreover, even if the Weiss DAC202 is truly asynchronous, it doesn't prove that it is immune to potential effects of cables, or software for that matter.

 

 

As you are perhaps aware, Zephyr's view is a common misconception, esp. for those arriving here at CA with computer/software backgrounds.

 

 

 

 

 

 

 

 

 

 

 

[TheZephyr]

"As you are perhaps aware, Zephyr's view is a common misconception, esp. for those arriving here at CA with computer/software backgrounds."

 

Zephyr is not suffering from a misconception, he knows exactly what he is talking about. Perhaps there is a misconception about how the PLL is used and how the buffer is used in the specific case cited. Perhaps an analogy would be of assistance. Consider the creation of a digital document; the amount of time required to create the document has no bearing on how long it takes to read the document or individual objects in the document. There is no timing information stored in the document, it does not exist, and therfore is unable to influence the reading process.

 

And Zephyr did not suggest that cables do not influence other (non buffered) input designs.

 

[DaveLew]

If you had a double buffered USB DAC where data from the PC to the dac fills one buffer and the actual dac gets data from the other buffer, with that data clocked with the zero jitter that you can get from local memory and an good clock, why would there be any jitter? Why don't DAC vendors design their products to buffer their input, memory is cheap and USB is many times faster than is needed for audio.

 

Oh, the "reported" experience you talk about. Every double blind test I've ever seen has shown that cables don't make any difference. Can you point be to any controled studies that show different results?

 

[losingmyreligion]

 

"And Zephyr did not suggest that cables do not influence other (non buffered) input designs."

 

No one said that you did. I was referring to the numerous examples of cables making a difference WITH truly asynchronous interfaces, which, again, is in direct contradiction to your (theoretical) claim.

 

In other words, the experience of many others here - who believed as you (still) do, that async interfaces would render cable differences impossible - directly contradicts your claim. As I said earlier, no one knows why.

 

welcome to the forum, read some other threads, share your views and see if others agree. ;0

 

have a great day*

 

 

 

 

 

 

[TheZephyr]

Ah yes, listening tests which contradict simple principles of physics and engineering. Ever heard of the Mpingo Disc or the green pen?

 

Perhaps the engineers who design things do not understand that which they are designing? What are the odds that if they did not understand what they are doing that they would be able to make these devices function to begin with?

 

Buffering is a very widely applied principle in engineering and broader sciences in general. One type of application of buffering is to decouple time related influence from the input process and make sure that the output process is never starved. It is well understood and if implemented correctly it works correctly, it is physically impossible to recall any time related input information because it does not exist. If it does not exist then you cannot hear it.

 

Are you asserting that time related information from the input process to the buffer is somehow preserved through the output process from the buffer?

 

[elcorso]

TheZephyr Mpingo Disc or the green pen?

 

Of course I do, Mpingo's works like heaven to my ears, and a lot of other people!

 

The 'green pen' worked fine in the time CD players was very bad units, and even today under certain CD's. I remember a Krell CD player that has green LED's at the edge where the CD was playing!

 

But, of course, by listening test, since I don't buy anything for their 'specs' or design: I found a lot of gear with 'super' specs that doesn't sound like music (to my ears).

 

And then (again) please consider the placebo effect, even in medicine placebo is working 60% better than the regular one.

 

My last words in this tread.

 

Happy listening,

 

Roch

 

[losingmyreligion]

"Are you asserting that time related information from the input process to the buffer is somehow preserved through the output process from the buffer?"

 

Nope.

 

I'm saying that use of a buffer (even when implemented in asynchronous manner with fixed frequency oscillators) has not shown to completely eliminate the possibility that cables and/or software players can influence the sound.

 

as you said earlier, this is getting ridiculous.

 

looks like we'll have to agree to disagree.

 

as I said earlier, check out the other threads on this topic, assuming you're interested in learning more. pretty much any thread on USB cables oughta do.

 

and as Roch said...

 

"My last words in this thread."

 

 

 

 

[TheZephyr]

Perhaps there is something to Mpingo disks after all. Two years ago I went to Machu Picchu and I sat my Zune down on the chair at the center of the convergance zone. I swear, from that moment on, there was a dramatic expansion of the sound stage and increased complexity of the timbral hues in the upper mide-bass. :-P