High-Speed or Low-Power?

[Audio_ELF]

The really key point I wanted to get over was that USB interfaces in Asynch mode have to do a fair amount of work, in order to maintain the buffer and sustain a synchronous link to the DAC, and that this is not really of a different order of magnitude to the amount of work that must be done if the interface of choice is ethernet or firewire. Finer arguments can be had here, but as you again seem to agree, there is little to choose between interfaces on this specific ground.

 

This is where our thoughts differ ... to my mind ... there is a huge difference in the "processing" needed to buffer and process what is already a simple stream of data (bits), compared with accepting the packets of data from the Ethernet, moving it up through the stages of the 7-layer OSI reference model to the application layer where the FLAC file data is then decoded to PCM and the PCM data then sent out to the buffer for "collection" by the time-sensitive DAC.

 

Eloise.

 

PS. FireWire is more akin to USB than to Ethernet. My comments about async USB would equally apply to async FireWire.

 

[ziggyzack]

I thought you'd come round on that too, when you said 'I don't think anyone is saying that USB is somehow benign. However it is no worse than Ethernet is many cases.'

 

A few facts though:

 

1) USB and Firewire are both packetised, so are just like ethernet in that respect. USB/FW do not supply a more 'simple stream of data' than ethernet. I did provide a couple of wikipedia links about USB, here they are again:

http://en.wikipedia.org/wiki/USB#Signaling

http://en.wikipedia.org/wiki/Non-Return-to-Zero_Inverted

If you just glance at those, you will see the complexity. USB and FW are clever interfaces, like ethernet, and with that comes unavoidable overhead.

 

2) Async connections necessitate a buffer, which needs control software to keep it topped up but not overfull - so that's another tie, in terms of processing requirements, between interfaces implemented in Ethernet, FW and USB.

 

3) FLAC decode is lightweight (portable players can do it no sweat) but as established earlier on, you can always send LPCM if you prefer.

 

Matan did comment on this subject earlier on:

 

There are many SoC [system on Chip] implementations of an Ethernet PHY + stack available today in a very small, highly integrated package, really no different than the USB/Firewire chipsets. I really think that we've reached equilibrium there, with the differences (again) boiling down to implementation and engineering.

 

ZZ

 

[cfmsp]

clay said:

 

"An Asynchronous DAC interface (by the forum's definition) is one in which the Clock in the DAC clocks asynchronously of any other upstream clock, and eliminates the synchronous clocking required in non-Async."

 

 

ZZ said:

 

"The consensus definition of the group here? The forum's definition? Have the Oxford English Dictionary heard about this? Quick, somebody tell the Queen!"

 

attempted derision noted.

 

http://en.wikipedia.org/wiki/Asynchronous_communication

 

"Asynchronous communication is transmission of data without the use of an external clock signal. Any timing required to recover data from the communication symbols is encoded within the symbols. The most significant aspect of asynchronous communications is variable bit rate, or that the transmitter and receiver clock generators do not have to be exactly synchronized."

 

 

back to ZZ:

 

"Synchronous, in this context, has nothing whatsoever to do with synchronising clocks."

 

says who? (I believe) every comment I"ve made here using the word asynchronous has also included the word clocking, which should clarify the context in which I am referring to Asynchronous transmission.

 

"To say a signal is synchronous is to say it is ready for consumption by its receiver - it needs no further buffering and reclocking, for example. The input to a DAC chip MUST be synchronous, i.e. at a rate the DAC chip expects."

 

You state only a couple of sentences previously that (in your mind) synchronous has nothing to do with synchronizing clocking.

 

Whereas, I've stated that the forum consensus (as I understand it) is to refer to interfaces that do NOT require synchronizing the clock in the DAC to other (upstream or external) as Asynchronous interfaces.

 

You also say that a synchronous signal "needs no further buffering and reclocking". In the signal transmission that I am referring to as characteristic of Asynchronous interfaces to DACs, the ONLY clocking is happening in the DAC.

 

 

Re Gordon's quote you include this;

 

"Any Adaptive and any Firewire using native device drivers would fall into this category as well as any SPDIF."

 

Since you don't know a lot about Firewire and may believe that Gordon is saying Firewire can not behave asynchronously, please allow me to clarify. The point of Gordon's comment is that native device drivers of Firewire do not support async mode. this comment is a bit of a red herring in that thread, as in all known (to me) digital audio applications, custom built drivers are required, and it is more common than not for Firewire interfaces to (allow) clocking of incoming data using only the local Master clock (in the DAC), which is (incorrectly to your mind) referred to on CA as an Asynchronous interface.

 

WHile we're on the topic of Gordon's quote, let my repeat something I said earlier:

 

"Gordon's quote is to make the point that - (arguing about) the definition of Asynchronous is NOT the issue - the benefits (of so-called Async transmission) are being able to employ fixed oscillators in the DAC which do NOT have to 'sync' with upstream devices."

 

And yet YOU continue to argue about the definition of asynchronous ad nauseum.

 

IF you want to refer to a message sent upstream to the sending device to either ask for more (or less) data as synchronous clocking, that's your prerogative I suppose, but please don't continue to try to sell this definition to me - you're wasting your time to do so. AFAIC (and Wikipedia seems to agree), if we're NOT trying to keep two clocks in 'sync', the interface is behaving asynchronously (i.e. independently) of any upstream clock (which is what I've stated all along).

 

 

"Hopefully you'll now acknowledge why this statement:

an async link to the last box (i.e. the DAC) is the preferred method which allows use of the DAC clock as Master, which is the most significant 'interface' criteria in creating optimal sound, IMHO.

led me to believe that you haven't properly considered all the issues and cannot pronounce on which interface is best."

 

who are you to declare that I (or anyone) "cannot pronounce on which interface is best" talk about hubris!

 

...and why should I need to acknowledge which of my words might have led you astray? I'm not responsible for your interpretations of my words. The issue here is that you are not looking for commonalities of understanding or consensus, but rather for anything you can point to as being disagreeable (with your position) or incorrect (to your way of thinking).

 

 

and finally,

 

"Please give me the benefit of the doubt to begin with, instead of focusing on picking holes."

 

How fucking hypocritical can one asshole be?

 

 

 

 

clay

 

 

PS, ZZ says: "Eloise. At best, you have your head in the sand."

 

Nice 'tude!

 

 

 

 

 

[ziggyzack]

Don't rely on it, Clay. Wikipedia's all over the place on this stuff. The page you're directing me to warns 'this article does not cite any references or sources' at the top - they're not even confident in it themselves!

 

Ask someone who's answer you'll take seriously. But also, use a little common sense. So wikipedia says 'Asynchronous communication is transmission of data without the use of an external clock signal. Any timing required to recover data from the communication symbols is encoded within the symbols.'

 

By this logic, everything we're talking about is always async, as we haven't been talking about using external clock signals (Matan's system aside, I'd better put). Don't believe everything you read in wikipedia!

 

I think you're on your own now, sticking to this line. You're also totally off-base with what you think I'm trying to do - I'm not rubbishing other systems or approaches, I'm explaining the benefits and trying to dispel some of the fears around ethernet and UPnP AV.

 

Edit - I think Eloise and I are chilled now.

 

ZZ

 

[cfmsp]

 

 

My point remains quite simple. 1) Optimal sound seems more easily provided by devices which use the DAC's local clock as master. 2) IMO, the type of interface that best supports the use of the DAC's clock as master is commonly referred to here on CA as an asynchronous interface. 3) My use of the word 'asynchronous' is due to the fact that "the transmitter and receiver clock (generators) do not have to be exactly synchronized." (as described by Wikipedia)

 

I don't know how to describe it any more simply. If you have a disagreement with those words, we'll have to agree to disagree.

 

Anything else you are disagreeing with is a strawman - i.e. a misunderstanding (of my position).

 

end of discussion.

 

Clay

 

 

 

[cfmsp]

"You're also totally off-base with what you think I'm trying to do."

 

My recent responses to your posts here are NOT about your Ethernet points. They are entirely due to your 'challenges' directed to me personally, and your decision to continue to be disagreeable over the definition of Asynchronous.

 

If that and your attitude disappears, all will be well.

 

 

clay

 

[The Computer Audiophile]

"I'm explaining the benefits and trying to dispel some of the fears around ethernet and UPnP AV."

 

Maybe we can make this easier for you ZZ. Nobody here has any fears around Ethernet and UPnP AV. Everyone has shown interest in the technology.

 

Also, the fact that you keep endlessly pushing this topic really makes it seem like you have a vested interest somehow.

 

[BobH]

I don't think any one interface has any intrinsic advantage over another. I been around these parts for quite some time now and have read all of the arguments in favour of A over B over C. None of them have ever impressed me.

 

A good engineer will engineer a good product. That's it.

 

USB, Firewire, Ethernet, Async, SPDIF, Jitter - it's all just something to argue about.

 

[ziggyzack]

So yeah Clay, I agree!

 

It will be a pleasure to read about you on occasion, perhaps to learn how to perform incantations over server software to make it sound better, or something else deeply rooted in irrationality. I do love a good fanboi. I don't often get into nasty internet spats, but showing up your obnoxious self was the Lord's work.

 

Chris, I didn't tell you, I own ethernet! That's the only reason I could possibly be pro the damn thing, I suppose. To suggest that no-one has fears about ethernet in audio is disingenuous - it's clearly associated with computers, in a way that other interfaces aren't, as expressed eloquently in the thread. Your wider readers are only missing out as a result. Also, thanks for the offer of help, but why don't you come down as hard on your mate Clay as you came down on me? He was rude! Escalatingly so! I've provided quite a lot of new information and clarity on this thread, and cleared up a few misconceptions, so it's a little late now to offer to make things easier. I must say, my strong suspicion is that you have a vested interest against ethernet and uPnP. Given that, we probably both have the wrong end of the stick.

 

The UPnP AV guys are looking on, at people fiddling around with special USB cables, isolation devices and living room computers, while they have music around the home, whether from hi-fi of the highest quality (really high end, if you want it), merely cheap and excellent quality, or a mixture, and universal whole house remote control. Internet radio available from any player in the house, with virtually any station you want, an increasing number in decent quality. No format problems, resolution limitations, driver issues. With the infrastructure in place to do just the same with video too, if you so wish. I agree, there isn't as much choice in UPnP DACs as there is for other interfaces at the moment, and they can be pricey, but as soon as you consider that you may want multi-room, a world opens up, surprisingly inexpensively, that was hitherto inaccessible to all but people who could afford custom installs.

 

You pays your money...

 

I'll leave you in peace.

 

ZZ

 

[BobH]

Would you mind, awfully, paraphrasing those cleared up misconceptions for me? I must have missed them and it seems such a shame to lose out on such well-meaning misconception clearing - it doesn't happen every day, you know.

 

Here's what I think I may have learned:

 

[The Computer Audiophile]

"A good engineer will engineer a good product. That's it."

 

Well said Bob.

 

[cfmsp]

 

 

"Here's what I think I may have learned: "

 

well said, Bob

 

 

clay

 

 

 

[cfmsp]

"To suggest that no-one has fears about ethernet in audio is disingenuous - it's clearly associated with computers, in a way that other interfaces aren't, as expressed eloquently in the thread."

 

here's a starter list of my fears related to interfacing to a DAC via Ethernet-input for purposes of high quality digital audio playback.

 

I fear that:

 

1) Ethernet as a DAC interface is too late to the party, and offers nothing of significant value above and beyond what Firewire and Async USB DACs already offer, and therefore will never become more than a niche product.

 

2) The user interface options will never equal the user experience and/or the preferred library management that users currently enjoy from OS-specific music playing software, such as XXHE, cMP, Amarra, Pure Music, or what's behind door number 3.

 

3) Ethernet-based DACs will never catchup with, let alone surpass, the quality of software reproduction currently offered by less nascent computer audio playback technologies such as Firewire and Async USB interfaces.

 

4) The prices for Ethernet-based audiophile quality DACs will never be cost-competitive with currently more widespread technologies.

 

5) Ethernet-based DACs will only be offered by companies who make engineering decisions based on how they will fare in the marketplace and/or who spend significant chunks of their money, time & energy on Marketing.

 

and most importantly to me personally, 6) I fear that Ethernet-based DACs will never equal the quality I currently enjoy with either of my DACs, including the Metric Halo LIO-8 and the $900 Wavelength Proton.

 

 

clay

 

 

 

 

 

 

 

[CharlyD]

ZiggyZack summed up my position pretty well:

The UPnP AV guys are looking on, at people fiddling around with special USB cables, isolation devices and living room computers, while they have music around the home, whether from hi-fi of the highest quality (really high end, if you want it), merely cheap and excellent quality, or a mixture, and universal whole house remote control. Internet radio available from any player in the house, with virtually any station you want, an increasing number in decent quality. No format problems, resolution limitations, driver issues. With the infrastructure in place to do just the same with video too, if you so wish.

 

I'm a user of both an async DAC (office) as well as a UPnP media rendering system (living room). Both use the same library hosted on a NAS. The NAS also has a UPnP server to provide directory services and stream content to the living room system. In short, I've got experience in both courts and gotta say UPnP is the future. Once you have a reliable network running and your renderer correctly playing, there isn't much of anything else to be done that affects the sound quality.

 

I occasionally cruise this forum looking for new music sources/reviews and the very occasional discussion of topics relevant to UPnP.

 

Found this interesting press release today from ABI Research, a leading market research firm, which predicts a surprisingly strong future for networked audio - http://www.abiresearch.com/press/1669-Revenue+from+Networked+Audio+Devices+Expected+to+Top+%2410+Billion+in+2015. All the players in this upcoming market described in the research are purveyors of TCP/IP networked systems.

 

I agree that the software used UPnP/DLNA systems is a work in progress, but there are several major software companies who realize the opportunity of networked home systems. I'm confident that software systems will soon be available for UPnP systems which offer feature sets far beyond those available in the current PC or Mac players.

 

[The Computer Audiophile]

Characterizing companies as "UPnP AV guys" suggests an us v. them type of mentality. It's really not that way when you talk to all the companies.

 

The talk about fiddling with USB cables and isolation devices is a common marketing theme among people who support UPnP above other methods. There is plenty of fiddling to be done with a UPnP device. Audiophiles will always fiddle. Just wait until UPnP users are fiddling with their network infrastructure to prioritize packets, setting up UPnP specific VLANs, isolating Ethernet devices, stopping power from flowing over Ethernet etc... Plus there is a dirty little UPnP secret that most people ignore and that's conversion of the Ethernet traffic to S/PDIF internally. This approach doesn't have to be taken, but it certainly is.

 

We must be careful not to compare the most simplistic UPnP approach versus a complicated tweaked out USB approach.

 

Plus, there is a middle ground here. A Windows system running J RIver Media Center uses UPnP for control and sending music throughout a house. The music can be sent to other computers with USB or FireWire DACs etc...

 

UPnP AV is one more tool in the engineers toolbox to create a great product. We are in for a rough time when we start an us v. them war and separate people / manufacturers into different camps. I know many manufacturers looking to implement both USB and UPnP AV into products.

 

I like UPnP and the associated components as much as the next guy, but I would never discount any of the other interfaces like USB, FireWire, AES/EBU, S/PDIF (optical or electrical). This comes from my personal experience with the imited number of high end UPnP devices and a plethora of USB, FireWire etc... devices. I can't wait for more high end companies to release UPnP products. It will be wonderful.

 

 

 

 

 

 

 

 

[cfmsp]

 

"We must be careful not to compare the most simplistic UPnP approach versus a complicated tweaked out USB approach."

 

Agreed, and also touting the whole house capabilities on a audiophile forum seems rather out of place as well. No one I know of expects to have highest quality audiophile sound in all the rooms in their house, for the simple reason that highest quality speakers are not typically installed in multiple rooms.

 

All the fuss about differences in software players will fall on deaf ears to folks listening to their bedroom system (except maybe Lucy's bedroom system).

 

While we're on the topic of simplistic approach, one can already set up a 'distributed' system today very easily and quickly using Airport Express Stations in each room, and controlling it all with iTunes on a Mac (or any number of Macs/iphones/iPads) - and with little to no network experience / setup required, and NO installation expert required either.

 

The quality of this sort of setup is inline with the quality typically provided by distributed systems, IMO.

 

For my part, I do NOT fiddle with special Firewire cables, except to eliminate the power leg, but I'd much rather tweak a cable than deal with network setup & support issues. ;0

 

 

clay

 

PS, as for more fiddling, not sure whether these 'whole house' capabilities being touted are wireless or not - but if they are wireless, you've gotta do something to eliminate/isolate the effects of the Wifi signals all over the place (which could impact audiophile-caliber systems), and if they're NOT, you're gotta run cable through the walls throughout the house. Not sure which is the lesser of the two evils there.

 

 

 

 

 

[Elprior]

Chris said There is plenty of fiddling to be done with a UPnP device.

 

What I am about to add is not my own experience, since I don't have any with UPnP, but reviewers of the Klimax DS are oftenly mentionning that the cable, the router and the nas are all making a difference.

 

Either there is something wrong with the use of UPnP, or there will be a lot of new "optimized" products coming to the market in this field. That could also just be that those reviewers are silly folks

 

Clay said you're gotta run cable through the walls throughout the house.

 

Yep, did so. Since I was about to destroy all the walls, I decided for high quality cat7 cables (that can cost a harm, wall connectors included). I'm not even using it for UPnP applications, but thought that would be the best thing to do (kind of future proof approach).

Now I can comment on something unsual, but the sound of my system is better when the music is streamed from the network - from the pc server to the netbook, then to the dac - than directly fed from the pc server to the dac. That might just have to do with the pc server being crappy. Time will tell...

 

Elp

 

[cfmsp]

 

"What I am about to add is not my own experience, since I don't have any with UPnP, but reviewers of the Klimax DS are oftenly mentionning that the cable, the router and the nas are all making a difference."

 

Wow, that makes NO sense to me, but then neither does the fact that the computer passing data via async Firewire or USB cables has an impact make sense, at least it didn't in the beginning.

 

The one promise of Ethernet interesting to me is that it could potentially take the upstream components completely OUT of the sonic equation. Sad to hear that this might not be true.

 

Thanks for sharing

Clay

 

 

 

[ggking7]

"The one promise of Ethernet interesting to me is that it could potentially take the upstream components completely OUT of the sonic equation."

 

Wouldn't a galvanically isolated and asynchronous USB DAC be just as effective at removing upstream components from the equation?

 

[cfmsp]

"Wouldn't a galvanically isolated and asynchronous USB DAC be just as effective at removing upstream components from the equation?"

 

that's a loaded question. Let me parse it a bit. If you're asking whether Async USB DACs could totally remove upstream components from the equation, then my response is this: That's what many thought should be the case, but it's apparently not turning out that way. Witness the extravagant USB cables being employed by some.

 

If you're asking if Async USB can be just as effective as Ethernet, one might argue that Ethernet has not yet proven to be as effective as Async USB! ;0

 

 

THere are also software player influences on the sound (with Async USB and Firewire), even with bit perfect playback.

 

Gordon admits to not (yet) knowing why USB cables influence the sound of his Async USB DACs. Mercman (aka Lars) tried the optical USB approach, but felt that it was not as good as an RSA Enopius (sp?) cable.

 

I use Firewire for my primary DAC. I'm encouraged by the absence of improvements needed/observed by the use of 'up-market' Firewire cables and also the dearth of same.

 

clay

 

 

 

 

 

 

 

 

[Elprior]

I remember Charles Hansen (Ayre Acoustics) stating that the cable matters for the qb9 (in the no longer available white paper ?).

 

As for firewire, Oyaide is having a dedicated line for audio application. Oyaide are far from overpricing their products and are delivering rather good products.

 

Clay that might just mean this matters for some firewire interfaces too

 

Elp

 

[cfmsp]

 

Good point about Charles Hansen's observations. Not only does he use Gordon's Streamlength Async USB, he is will known for great isolation in his devices.

 

 

"Clay that might just mean this matters for some firewire interfaces too ;)"

 

yes, it might. OTOH, no one I know has found any advantage in expensive Firewire cables. That they might exist does not in and of itself mean that it matters.

 

If it turns out that it does, I'll be upgrading!

 

UPDATE:

 

The Oyaide cables seem relatively inexpensive (by audiophile standards, and are not made out of mysterium, treated cryogenically and dipped in unobtanium.

 

Rather their products generally are in the solid engineering, with highest quality materials and, as you say, without excessive margins we see in some audiophile products.

 

thanks much for the heads-up. A quick Google search and I notice that Kent Poon has selected them for his Weiss DACs, which is a good endorsement. $700 HK equals about $90 US if I did the FX conversion properly.

 

I'll be giving these a try with the LIO-8 soon.

 

cheers,

 

 

clay

 

 

 

[The Computer Audiophile]

HI Clay - I've been using the Weiss DAC202 for many weeks now. Mostly via FireWire. During this time I've been researching isolation technology as an extra step of separating the computer based noise from the audio components. I am really interested in the FireWire to optical to FireWire conversion boxes, but the cost is about $800 for the boxes. Have you or anyone you know using FireWire tried anything like this? Here is one device I've been looking at Opticis Optical FireWire Repeater Set (M4-200). I wish there was a simpler device. Maybe there is and I just don't know about it.

 

Common non-audiophile thinking would suggest isolation inside the DAC is enough. But, is it really? I wonder if there are better levels of isolation. I actually talked to Ayre yesterday afternoon and discussed isolation in the QB-9. The DAC has an optical (not S/PDIF) isolation step built-in before sending data to the chip.

 

[ggking7]

If you're asking whether Async USB DACs could totally remove upstream components from the equation, then my response is this: That's what many thought should be the case, but it's apparently not turning out that way. Witness the extravagant USB cables being employed by some.

 

I'm asking about the combination of async and galvanic isolation. That should do it.

 

 

 

[cfmsp]

 

 

I'm not aware of anyone using a Firewire to optical converter, nor of anyone who thinks this would be an improvement.

 

Lars used the Opticis USB - to Optical - to USB converter, as I mentioned earlier, and it was displaced by as RSA USB cable.

 

clay