New Dichotomy - Async vs. Non-async DACs

[cfmsp]

Is it just me, or are we facing a new dichotomy in audio - asynchronous DACs versus non-asynchronous DACs.

 

In my view, the battle lines are being drawn on either side of this topic of the preferred method of interfacing between computers and DACs.

 

Will this rhetoric grow to the level of the well known audio dichotomies - solid-state versus tubes, analog versus digital, and for computer audiophiles, PC versus Mac?

 

If so, perhaps we will some day trace it's origins to the Alan Taffel article in TAS, in which he famously declared USB as inadequate for audiophile use, while totally ignoring the state-of-the-art USB approach called Asynchronous USB in an article titled "The State of USB Audio", despite prior knowledge of it. He also claimed that there were no audiophile (worthy) Firewire DACs in existence. Amazingly, this article was published only a few months ago. Unintentionally, this article seemed to polarize audiophiles, or more precisely, got the Async believers up in arms and ready for battle, as unsuspecting audiophiles with little knowledge of the true story of computer audio had little reason to do anything other than turn the page soporifically to read the latest advertisement by one of TAS's sponsors.

 

Despite lengthy debates on this forum, and perhaps another forum or two, the theoretical superiority of Asynchronous interfaces (versus non-async) for purposes of transmitting digital audio for playback is largely unknown, although this is starting to change. As it does, the rhetoric will heat up, with those who stand to lose out in the new landscape arguing vociferously that their older, 'tried and true' methods are superior, while the new guard charge forward, dragging the industry kicking and screaming into the future.

 

On the one hand, we have the leading Async USB DACs created by Gordon Rankin of Wavelength & Charles Hansen of Ayre (who licensed Gordon's technology), plus the asynchronous Firewire DACs available from pro audio companies like Weiss, Metric Halo, Apogee and others ... and on the other hand, we have the 'legacy' DACs, which trace their design origins to a time when the primary device for transmitting digital data to the DAC was a transport. These DACs are made by the likes of Berkeley, Bryston, Bel Canto, Benchmark, and many others, some of which even have names starting with a letter other than 'B'. Their primary (read best sounding) interface is AES/EBU and/or Coax S/PDIF, and though many have also added a USB input, these USB inputs use a design approach known as adaptive USB, and do not function asynchronously. Neither do these DACs feature Firewire inputs.

 

Another aspect of this dichotomy is the direct connectability (or lack thereof) between the DACs and the modern computers (being used to replace transports by the new breed called 'computer audiophile'). For their part, the Asynchronous devices allow asynchronous connection to computers via two of the three most ubiquitous computer (audio) interfaces available on today's computers: USB, Firewire and Toslink (this latter of which does not support async communications, being a variant of the S/PDIF spec)

 

The 'legacy' DACs have typically (until recently) only offered connectivity via AES/EBU, Coax S/PDIF and Optical S/PDIF (aka Toslink), of which Toslink is the only interface found routinely on computers. To connect to a DAC via AES/EBU or Coax S/PDIF, the audiophile most often must purchase & install a soundcard, at additional, sometimes considerable, expense.

 

To address this lack of direct (i.e. without soundcard) connectivity, except via the less well received Toslink interface, some manufacturers of non-async DACs have started including USB inputs. While this alleviates the growing consumer demand for ease of connectivity, it does little to minimize the growing dichotomy, and for one simple reason - these USB implementations rarely sound as good as the AES/EBU or Coax S/PDIF implementations on the very same DAC. Neither do they sound as good as the Asynchronous DACs, whether connected via USB or Firewire. To those in the know, these USB implementations are highlighting the advantages of asynchronous communications, which is to say, the schism continues to grow with each new introduction of a non-async USB input.

 

So, are we looking at a new dichotomy, or just the latest fad approach that means little other than to those that prefer it?

 

 

Clay

 

PS, I'll go ahead and stipulate that implementation is more important than any design approach, and that good results can be had either way, same as with the other dichotomies, supposedly even PC versus Mac. ;-)

 

 

 

 

 

[Happy]

There are two ways to deliver digital data; async and sync.

 

Sync requires clock distribution (in-band) or out of band.

 

Async requires flow control (there are several ways of doing this.

 

Sync design with poor clock distribution is poor. Async with poor flow control (several USB implementations) are also poor. Both modes designed well, work very well.

 

The truth is that audio speeds are very slow (almost trivial) compared to LVDS signals, ATM systems (the internet backbone).

 

The confusing thing for new computer audiofiles is that most 'Reference DACS' have been/are designed with sync interfaces - this as clay points out adds cost to computer driven systems.

 

The future, as computer audiofile grows, is surely 'Reference DACs' with async interfaces - people assume USB/F/W but the obvious one is wired and wireless Ethernet. With these interfaces the computer is effectively delivering a file to the DAC - it then relies on the DAC to buffer, clock and flow control efficiently.

 

DACs are quite involved to design (I once taught a whole year course to M.ENG students on DAC design) - they are not all equal - the interface side of the DAC (sync or async) is the easy part - the logic that suggests that AES DACs are better than F/W DACs or vice versa misses the point of the DAC design.

 

People should decide if the 'async dacs' are up to their person definition of reference. Start with the (my guess from worst to best):

Sonos,

squeezebox,

Modified sonos,

Benchmark

Lavry DA11

ULN-2/8

Wiess DAC2,

Minerva

Wavelength

Meitner

dCS

 

I'm sure people will find their definition of reference quality somewhere in this list.

 

For now, personally I chose an Alpha DAC and chose to distribute the clocks properly.

 

/Paul

 

 

[The Computer Audiophile]

Interesting topic.

 

"Sync design with poor clock distribution is poor. Async with poor flow

control (several USB implementations) are also poor. Both modes designed

well, work very well."

 

Very solid statement.

 

[PeterSt]

Ok, I hope this is appreciated to some extend, and at reading this alone, you might skip in advance !

 

My take on this : I don't know (yet);

 

My point is (and let me be alone on this), any really asynchronous DAC can not be influenced from software. Or at least that is to be assumed from technical basics. This, while it is well known that *any* DAC which is not anynchronously operating, can, and for the better. This means that the DAC which can not be influenced is completely on its own, or in other words, it is as it is, and might this not be 100% good, it's over and done with.

 

I can add to this that it is crazily difficult to even choose a best "implementation" of a DAC, when all is in your own hands, like it is with the one I am creating myself. Besides the many jitter rejection implementations - and combinations with the chips themselves - there's the output stage, and even with the same implementation in front of that, all those many output stage designs sound completely different. Not a bit, but completely.

 

From the above follows, assuming that only one such implementation will last in the final product, it is me who decides what sounds best, and "me" is subjective. Of course I try not to, but it just is so. Now :

 

When such an implementation would not be subject to software influence (and I mean explicit, not by accident like the various software players imply such "accidents"), you'd be stuck with that one sound. And this would be the case with really asynchronous.

 

Allright, this is where this post could end, and to most it will be sounding strange enough already. But at this time, let me add a few more even more strange lines, actually contrary to the above;

 

Before a year ago, I have "always" been using a Fireface800 as the SPDIF pass through device in front of my DAC from back then. Today we call this an asynchronous connection for the part from the PC to the Fireface. However, this was the same period XXHighEnd started, and no way that would avoid the software (explicit) influence. I must honestly say that back at the time I didn't get anything from anynchronous interfaces as such (the term didn't exist in audio I guess), but today we may wonder a. the real merits of that term, regarding Firewire and b. if really asynchronous (that assumed) how in the world it is possible the influence siples through.

 

Next I can add that one of the explicit goals for the DAC (which project started almost a year ago by now) was to avoid the software influence, and it hopelessly failed.

 

The real reason of me adding this second chapter in this post, is that lately I am beginning to get under the impression that something very different is going on, never mind my IT background will not allow thinking that. This is about the exact same files, played through the exact same player settings and all measured bit perfect to begin with (loop back the digital input at the DAC), still can sound different.

This is not in the same leage as the asynchrounous connection which keeps on being influenced, but it sure is in the league of something else going on, never mind I would have bet my life it couldn't - a few weeks back.

 

Lastly, I would say that any DAC *needing* an asynchronous connection to perform well (on jitter specs) is inherently not the best on jitter rejection. However, this is not necessarily so because it is just the theory that it will avoid incoming jitter. Uhmm, wrong, it WAS the theory ... perhaps.

If we add this to the first chapter, we might - in a year or so - come to the conclusion that asynchronous is no good at all, or at least doesn't help to solve the problem of which it was thought to be theoretically there.

 

If I am correct that two the same files can sound differently (and I don't talk about "Steve's offsets" which bear a perfectly good explanation IMO), it just *will* mean that jitter can exist in normal computer data, and it can normally be transferred over the internet and all. This also means that any asynchronous connection won't help a single bit.

 

By now this is not even highly speculative anymore, but merely a matter of diving into how computer data really "works" and is transferred. I thought (and actually still think) I know how that is, but I can't be right.

 

Peter, almost ready for the mad house.

 

[sandyk]

"I can add to this that it is crazily difficult to even choose a best "implementation" of a DAC, when all is in your own hands, like it is with the one I am creating myself. Besides the many jitter rejection implementations - and combinations with the chips themselves - there's the output stage, and even with the same implementation in front of that, all those many output stage designs sound completely different. Not a bit, but completely."

 

Hi Peter

To further confuse you, I will add that even fitting a shunt regulator prior to the usual DIGITAL +5V and +3.3V regulators, instead of from a typical higher voltage regulator, will markedly change the overall SQ, typically for the better. Furthermore, even the choice of shunt regulator will affect the final outcome.

Quite a few people have found this to be so with various DACs, particularly the new Buffalo DAC from Twisted Pear.

A "Simplistic Salas Shunt" (DIYAudio) will sound a little different

to an upmarket Paul Hynes regulator, or even a John Linsley Hood PSU Add-on. All better than from a typical 78xx or LM317T.

I am not joking !

Regards

SandyK

 

[PeterSt]

... but yes, you are !

 

Who informed you I have *not* done that eh ?

So I did ...

 

:-)

 

[Wavelength]

Clay, others

 

A basic statement that makes for the understanding of why async is better than others is that:

 

A fixed digital audio based oscillator will always out perform an oscillator that is moving to match some incoming stream.

 

In it self any oscillator that is moving is adding jitter to the system that it is working on and that is not good.

 

Thanks

Gordon

 

[cfmsp]

thanks Paul, for such a cogent reply.

 

"Both modes designed well, work very well."

 

Totally agreed, although one might argue that it should be less costly to reduce the potential impact (jitter, etc.) from the source computer via an asynchronous interface, which theoretically would allow manufacturers to provide (more consistently) better sounding gear (despite the front end in use) for less cost.

 

"The confusing thing for new computer audiofiles is that most 'Reference DACS' have been/are designed with sync interfaces - this as clay points out adds cost to computer driven systems."

 

Agreed on both points, which is why I've become a bit of an evangelist for the new approach, which has worked admirably for me personally, due to great sound at great value.

 

"people assume USB/F/W but the obvious one is wired and wireless Ethernet"

 

Again, totally agreed. Not having seen/heard an Ethernet based system, and not believing them to be as cost effective (yet) as Firewire, I don't make a point of including them in my recommendations to newcomers here.

 

"the logic that suggests that AES DACs are better than F/W DACs or vice versa misses the point of the DAC design."

 

Clearly, there is much, much more to DAC design than the interface used, just as there are much better ways to 'evaluate' DACs than which chip they choose. Indeed, I think the most often overlooked aspect of DACs (at least in discussion here on CA) is the analog section, perhaps followed by the impact of the digital processing ON the simultaneous analog signal processing in the same box.

 

 

"For now, personally I chose an Alpha DAC and chose to distribute the clocks properly."

 

So, you're using the Antelope as master for both the Alpha and Lynx card, or reclocking the signal? Given the superb analog section of the Alpha, it must sound especially spectacular?

 

thanks again for your reply,

clay

 

PS, the ULN-2 is perhaps properly placed on your spectrum, the ULN-8 is in a whole 'nuther league.

 

 

 

 

 

 

[DanRubin]

I don't think Firewire DACs are by definition automatically async, though I may be mistaken. Does anyone here really know what Metric Halo and Weiss are doing with respect to clocking? Are we giving them a pass just because they are Firewire?

 

 

 

[cfmsp]

"My point is (and let me be alone on this), any really asynchronous DAC can not be influenced from software. Or at least that is to be assumed from technical basics. This, while it is well known that *any* DAC which is not anynchronously operating, can, and for the better. This means that the DAC which can not be influenced is completely on its own, or in other words, it is as it is, and might this not be 100% good, it's over and done with."

 

Interesting, even though Ockham's razor would suggest that the issue is simpler (i.e. my hearing, my lack of line conditioning gear, etc.), I had imagined a similar rationale as to why I personally do NOT hear differences that others appear to hear via Amarra to such a large degree as is claimed.

 

There's a lot more going on in the connections between computer and DAC than the mere asynchronous handling of the data, not the least of which is the actual, physical connection which might transfer noise, etc.

 

"Besides the many jitter rejection implementations - and combinations with the chips themselves - there's the output stage, and even with the same implementation in front of that, all those many output stage designs sound completely different. Not a bit, but completely."

 

Barry Diament recently stated here that every software sounds different - and that's just the software part of the equation. Of course, every hardware circuit will sound different.

 

"Allright, this is where this post could end, and to most it will be sounding strange enough already."

 

I'm with you so far.

 

"Today we call this an asynchronous connection for the part from the PC to the Fireface. However, this was the same period XXHighEnd started, and no way that would avoid the software (explicit) influence."

 

Peter, interesting, so you had previously believed that ANY asynchronicity in the entire chain should avoid the software's ability to influence the sound? I'd never considered that, even believing Firewire to S/PDIF converters to be essentially missing the point of allowing the clock in the DAC to be master, although perhaps better than without (if the convertor has a high quality clock itself, such as in Weiss devices).

 

My belief is that the primary advantage of asynchronous connection is to reduce as much as possible any timing related errors in sound by allowing all timing functions to be easily controlled by a very high quality clock IN the DAC.

 

But I hear your assumption, and the change in that belief since.

 

 

"lately I am beginning to get under the impression that something very different is going on, never mind my IT background will not allow thinking that. This is about the exact same files, played through the exact same player settings and all measured bit perfect to begin with (loop back the digital input at the DAC), still can sound different.

This is not in the same leage as the asynchrounous connection which keeps on being influenced, but it sure is in the league of something else going on, never mind I would have bet my life it couldn't - a few weeks back."

 

yep, even Gordon agrees that there is MUCH going on beyond the ability of asynchronous connections to resolve, even to the point that USB cables make a difference even in async USB implementations.

 

Perhaps things digital are NOT nearly as unambiguous as we'd like to believe, indeed, perhaps they are just a rather crude form/ representation on an (unknown?) analog-like spectrum?

 

Perhaps, even we are dealing with metaphysical issues here? :-0

 

"However, this is not necessarily so because it is just the theory that it will avoid incoming jitter. Uhmm, wrong, it WAS the theory ... perhaps."

 

You're comment here seems to assume that jitter is the only possible impact on the sound, or rather, you seem to be saying that if Asynchronous DACs cannot eliminate all software influence that it is NOT having the claimed effect of reducing jitter (and thereby improving the sound). If so, I disagree.

 

Am I misunderstanding your point?

 

 

"If we add this to the first chapter, we might - in a year or so - come to the conclusion that asynchronous is no good at all, or at least doesn't help to solve the problem of which it was thought to be theoretically there."

 

I'l agree to the possibility of your latter point being correct.

 

"If I am correct that two the same files can sound differently, it just *will* mean that jitter can exist in normal computer data, and it can normally be transferred over the internet and all. This also means that any asynchronous connection won't help a single bit."

 

I'll disagree with your use of the word 'jitter' to describe it, but agree that there could be something really insidious going on, that will become more and more obvious as we gain better and better resolution (and the resultant ability to detect differences still unexplainable). As we don't know that it's timing-related, jitter might be the wrong term, and if it's NOT timing related we had improper expectations to believe that Asynchronous connection would prevent it in any event.

 

Peter, as always, thanks much for your (always) lengthy reply.

 

With regards to your research, Godspeed!

And keep us posted.

 

I've an IT background as well, but I try not to let that get in the way. I would have minored in metaphysics, had it been available.

 

clay

 

 

 

 

 

 

[barrows]

Here it is important to understand what Gordon mentioned above. The devices in this thread referred to as Async, allow for a single fixed frequency clock, and will result in the lowest jitter interface possible without resorting to jitter reduction bandaids such as ASRCs and/or re-clockers. That well done Async interfaces will result in the lowest jitter interface possible is a technical given.

Also mentioned is that everything matters in the design of a DAC: power supply design, upsampling/digital filter design, the actual DA converter used, and how it is used, I to V conversion design (for DAC chips with current output), and, perhaps most importantly, analog output stage design.

To think that we can compare DACs based on whether or not they offer an Async interface, without considering the rest of the design's influence on sonic performance would be foolish at best, but we should accept as fact, that the Async interface does result in the lowest possible jitter.

OK, now our discussion is going to get a little controversial, please accept here that I am now just thinking out loud and offering an opinion. Do we want the lowest possible jitter? For me the answer is clearly yes; I have been involved in listening tests of prototype products, and my experiences in those tests indicated that every time we lowered jitter, sonic performance improved. The tests I am referring to kept every aspect of design the same, except for the changes that lowered jitter. These tests were done in a reference system that was relatively well set up, fairly high resolution, and pretty close to neutral tonally. The thing is, I could imagine some people preferring the sound of higher jitter, in some systems. In other words, a low jitter source, if one is used to hearing higher jitter levels, may point out what I would call problems in a system. It appears to me, that some levels/spectrums of jitter may have a euphonic result in some systems. To me, in a good system, the results of lowering jitter are increased detail retrieval (as evidenced by image specificity, decays, more complex harmonic portrayals) accompanied by greater listening ease. Higher levels of jitter result in a hazy sound, obscuring these same lower level details to some extent, but sometimes higher jitter levels also result in the appearance of a larger, billowing, soundstage, that can be somewhat impressive at first listening. I can certainly imagine a system, that is already on the bright/hard side, where a listener might be very impressed by the sound of a higher jitter source and the little bit of haze it brings, along with a big, billowy, soundstage.

I think as listeners/consumers we should demand sonic excellence for the products we purchase, and part of that excellence will be produced by low jitter sources (and hopefully higher resolution music files). The good news is, we have a lot of low jitter choices in computer interfaces right now: Weiss' Firewire and Metric Halo's Firewire products, Wavelength and Ayre's USB products, and Linn's network players are just the tip of the iceberg of high quality, very low jitter, computer audio interfaces that are well engineered and offer great sound. The only way a SPDIF/AES input DAC can offer similar jitter levels is by adding jitter reduction circuitry: ASRCs or reclockers, and personally I find those solutions at the very best less elegant, at the worst sonically compromised, to getting the interface right in the first place.

I have no idea whether there is any reason to consider factors other than jitter when speaking about the sonic performance of different computer audio interfaces. To my mind it is hard to fathom how different interfaces could affect sound (assuming they are all bit perfect) outside of the influence of jitter. I would love to hear if any computer design engineers have any ideas of additional effects on sonic performance produced by different interfaces.

 

[cfmsp]

 

"To think that we can compare DACs based on whether or not they offer an Async interface, without considering the rest of the design's influence on sonic performance would be foolish at best, but we should accept as fact, that the Async interface does result in the lowest possible jitter."

 

Agreed - couldn't have said it better myself.

 

"I think as listeners/consumers we should demand sonic excellence for the products we purchase, and part of that excellence will be produced by low jitter sources (and hopefully higher resolution music files)."

 

Couldn't agree more with this, especially our responsibility to demand (by rewarding the manufacturers providing such with our pocketbook) sonic excellence, rather than let the 'legacy' DAC manufacturers continue to merely tweak there existing products, with the apparently wholehearted endorsement of the audiophile rags unwilling to upset the status quo. This is THE single most important factor in my personal evangelism here on CA.

 

Those coming here for advice deserve to know of the new advances which the 'legacy' DAC manufacturers, even those of reference caliber, seem not yet prepared to provide.

 

thanks for responding,

clay

 

 

 

 

[Thomas J]

One small comment:

 

"... but we should accept as fact, that the Async interface does result in the lowest possible jitter" goes too far. Async perhaps can result in such. I think Charles Hansen says the QB-9's jitter is 120psec. That's not an exemplary figure.

 

[barrows]

I think what Charles was referring to (I think you are referring to a post over at AA?) was that the jitter of the QB-9 was below the threshold of John Atkinson's test equipment, which is 120 pS. In any case, I am not aware of any measurement techniques as used by those who publish measurements (Stereophile and HiFi News) that can actually measure jitter below the 120 pS level, so I am not sure how you could be aware of any products that have been measured to produce below 120 pS of jitter. I have seen JA report measured results below 120 pS, but I assume these are anomalous, because in his own article on measuring jitter he mentions that his test equipment cannot measure below around 120 pS. I suspect this may be why JA no longer seems to give a pS value for jitter on very high end products, but tries to explain how to interpret the jitter spectrum graphs instead.

Perhaps Charles/Gordon might be better able to clear up the measurement of jitter for us.

 

[laurent]

The comments of barrows and Peter are very interesting.

 

Most people agree that theoritically async should be better. But are there other issues?

 

If I understand correctly , Peter and barrows suggest that computers and software may add intrinsic jitter or distorsion. Since async dacs do not use any jitter elimination, are they more "computer and software sensitive" if I may write so?

 

Wavelength refused to take part in the Tas review because they were not to use a Mac with 4 or 8 Gb and ssd. Why does it matter especially with async usb where you do not rely on the clock of the computer?

 

I think that some forumers also mentioned that the Dac2 or the Qb9 revealed their qualities only when coupled with Amarra.

 

I may be totally wrong. But there are so many things I don't understand... so I trust my ears only.

 

Laurent

 

[Wavelength]

Guys,

 

Barrows is right... Paul Miller specifies the Miller device at 120ps but really we have found in experience that this is even a long shot.

 

With the AP2700 that John Atkinson uses now the results or graphs are much better but you would have to hand assemble a number according to the side bands and Julian Dunn's calculations.

 

Thanks

Gordon

 

[Audio_ELF]

I maybe just repeating thougts already expressed, but my belief is tht Ethernet is NOT a suitable system for transmitting digital audio.

 

"But you can buy Ethernet DACs" I hear someone yell in reply, but these are NOT using ethernet to transmit digital audio. These are not Ethernet DACs but are UPnP (or DNLA) streamers with high quality Digital to Analogue Conversion stage. The Ethernet part transmits a digital audio file (such as FLAC or WAV) NOT digitial audio in a form which would be an alternative to SPDIF or USB connection. This is (to my mind) an important distinction and is a streamer and DAc in on box in the same way as an integrated CD player is a transport and DAC in one box. Once the digital audio file gets to the box - transmission from streamer to DAC chip can be acomplished in various ways. There are many reasons why trying to use Ethernet to connect a DAC in an alternate way would not work (easily) but for now I won't go into them.

 

Eloise

 

[Audio_ELF]

I maybe just repeating thougts already expressed, but my belief is tht Ethernet is NOT a suitable system for transmitting digital audio.

 

"But you can buy Ethernet DACs" I hear someone yell in reply, but these are NOT using ethernet to transmit digital audio. These are not Ethernet DACs but are UPnP (or DNLA) streamers with high quality Digital to Analogue Conversion stage. The Ethernet part transmits a digital audio file (such as FLAC or WAV) NOT digitial audio in a form which would be an alternative to SPDIF or USB connection. This is (to my mind) an important distinction and is a streamer and DAc in on box in the same way as an integrated CD player is a transport and DAC in one box. Once the digital audio file gets to the box - transmission from streamer to DAC chip can be acomplished in various ways. There are many reasons why trying to use Ethernet to connect a DAC in an alternate way would not work (easily) but for now I won't go into them.

 

Eloise

 

[CharlyD]

"... my belief is tht Ethernet is NOT a suitable system for transmitting digital audio. "

Ethernet is a standard for the physical layer of TCP/IP and is a perfectly suitable system for transmitting digital audio. UPnP/DLNA defines a set of communication and connectivity standards for consumer electronics devices connected over TCP/IP. Not all audio streamer devices are UPnP/DLNA compatible (e.g. the Squeezebox devices). Streaming of audio content from a UPnP/DLNA Digital Media Server (DMS) to a Digital Media Renderer/Player (DMR/DMP) can be in LPCM format or in another format (e.g. FLAC) if the appropriate codec is present in the target device. All USB/Firewire DACs receive the audio content in LPCM format. The DMR/DMP does not store any persistent copy of the streamed content.

 

[The Computer Audiophile]

Those interested in Network based audio should read AES white paper posted October 6, 2009 titles Best Practices in Network Audio. Here is a link

 

 

http://www.aes.org/technical/documents/AESTD1003V1.pdf

 

[Audio_ELF]

Charley, fundermentally I wouldn't argue with anything you said however I do have a few points.

Yes, Squeeze box is not UPnP, but fundermentally it is the same thing in that it is a streamer. It is not a raw stream of 1s and 0s to be transferrd to a DAC.
IIRC a streamer does not use LPCM - it uses WAV (or AIFF or a supported compressed format) the difference being that there is a wrapper around the pure Data stream.
The fundermental difference between Ethernet and AES/SPDIF if that Ethernet is a packetised system, AES/SPDIF is a pure stream of data in a time critical format. Ethernet has very limited ability to ensure delivery ontime.

 

My point is that a so-called Ethernet DAC (such as Linn DS) is not just a DAC, it's a (very specialised) computer device which translates an audio file into a digital stream to be passed to its (internal) DAC. So far, that I'm aware of, no one has produced a DAC which can have digital audio data (as distinct from a file containing digital audio) direct from a source. And for that matter I'm not sure an Ethernet connection would gain you anything over a point to point connection such as USB, except possibly distance from computer to DAC

 

Eloise

 

[Happy]

 

Firstly people confuse (make synonymous) Ethernet with IP delivery.

 

Clearly IP is an entirely appropriate mechanism for distributing audio .... and video (and increasingly even phone calls).

 

It has the advantage of distance, cost, rate adaption, independence of technology, independent of rate etc...

 

15 Years ago one could have argued; Decnet, Appletalk, IPx, Token Ring, IP would be the best - IP won.

 

In fact because IP delivery is so good we will see the demise of the CD in favour of downloads (high quality and low quality). Itunes is the most successful music distribution scheme (in front of Wall Mart).

 

IP has dominated the way we deliver everything. Networks are now essentially IP based. Homes are IP connected.

 

Using IP one could stream, deliver and even multicast music. One can make delivery completely lossless without the use of cables.

 

I've no idea why audiophiles believe that IP is not suitable?

 

/Paul

 

[The Computer Audiophile]

Hi Paul - I think most people think about the latency of traditional IP devices like switches and routers and discount it as an audio transport mechanism. A big thing is Quality of Service (QoS) and guaranteed bandwidth. The article I linked to above from AES does talk about new ways to address this issue.

 

I think IP is wonderful for audio and it will take a few great products to turn people into believers.

 

[Wavelength]

Guys,

 

You are freaken me out...

 

First Firewire does have an async mode but no operating systems support it. Kind of like the way that Windows does not support Class 2 USB Audio. That being said there are many Async Firewire systems that utilize BULK mode (same as a hard drive) and then write drivers to make it look like and audio device.

 

Ethernet is capable but really at 10/100 speeds it is limited due to the turnaround and the heavy load by IP protocol especially when you consider data grams and the stacks. But it is capable of doing audio well. I am just not sure why none of these audio companies have written a driver to make their Ethernet look like a dac??? instead they have these applications specific for their dac???

 

Anyways.... as always as someone said above. You can have the best interface and screw up the back end and therefore have a poor product.

 

There is a big picture here and this is just part of it.

 

Thanks

Gordon

 

[Audio_ELF]

Happy said "15 Years ago one could have argued; Decnet, Appletalk, IPx, Token Ring, IP would be the best - IP won."

If we're trying to be correct...

 

Ethernet, Tolkien Ring and (I think) DECNet are "Network" / "Data Link" layer protocols and compete against each other.

 

IP (more correctly TCP/IP) and IPX are "Transport" layer protocols.

 

(AppleTalk combines elements of both IIRC)

 

Most LANs run a combination of TCP/IP over Ethernet carried by either UTP or WiFi (defined by the 802 series of documents).

 

My point I was trying to make (badly) was that modern streamers do NOT recieve "digital audio" in a format that would be recognised by a DAC; they recieve files which happen to contain digital audio data. The streamer has to convert those files (WAV, FLAC or MP3) to digital quip stream.

 

Eloise