Jump to content
IGNORED

High-Speed or Low-Power?


Recommended Posts

Ziggyzack commented... "As I said earlier on, the model Chris reviewed is their integrated model, and has spdif inputs to manage all dac and pre duties in a multi-source setup. None of the others have anything but an ethernet input, and they've gone down so well that the company ceased making CD players (the general view seems to be that a DS player outperforms the CD player from at least the next range up)."

 

You are right that the other Linn DS devices are pure Ethernet input, but just because they have gone down well doesn't prove that Ethernet / UPnP that they use is the best methodology. All it proves is that Linn have made a device better than their previous CD players. The fact that Chris' opinion is that when offered choice between SPDIF and Ethernet input, the device sounds better with the SPDIF input does ask questions about how good Ethernet is in the real world - though we don't know how the device works internally to pipe the output of the music file into the DAC section.

 

Yes they have "ceased making CD players" but there have not been pure CD players in Linn's range for a long time. At the time they issued the Press Release, they had the Magik player - a CD player which also played 2-channel SACD and DVD-A; the Unidisk 1.1 - a "universal DVD/DVD-A/SACD/CD player and the Unidisk SC - same as Unidisk but with SPDIF input and 5.1 decoder. After their press release they dropped the Magik player - a poorly performing and reviewed device.

 

As I commented, no one is writing off Ethernet as having a place within a computer audio system, just it seams that at the current time there are other options which offer as good, or better, possibilities.

 

As an off the top of my head example (and ignoring the 24/96 limit of the USB implementation which is another issue) ... which sounds better - a Mac Mini plugged via (async) USB into a dCS Debbusey; or a Linn Klimax DS? Both are going to cost around £11,000 all in - so which will give you better results??

 

Eloise

 

Eloise

---

...in my opinion / experience...

While I agree "Everything may matter" working out what actually affects the sound is a trickier thing.

And I agree "Trust your ears" but equally don't allow them to fool you - trust them with a bit of skepticism.

keep your mind open... But mind your brain doesn't fall out.

Link to comment

Eloise said : Yes they have "ceased making CD players" but there have not been pure CD players in Linn's range for a long time. At the time they issued the Press Release, they had the Magik player - a CD player which also played 2-channel SACD and DVD-A; the Unidisk 1.1 - a "universal DVD/DVD-A/SACD/CD player and the Unidisk SC - same as Unidisk but with SPDIF input and 5.1 decoder. After their press release they dropped the Magik player - a poorly performing and reviewed device.

 

Actually, they do have others cd players.

Here in France, I can remember of the Akurate one, another line of products, which was sold for 7000€ (glups).

 

Both are going to cost around £11,000 all in - so which will give you better results??

 

I vote for the Debussy :)

Note that I am biased towards dCS products, but all listening sessions with the Klimax DS sounded like s...

 

Back on topic.

 

I'm experimenting with strong cpu underclocking.

The main motivation was the reduction of noise (as the fan is coupled with the cpu temperature), which worked fine. The old p4 2.6c underclocked at 1.73 just takes between 0 to 1 percent of cpu (according to windows 7 monitoring tool) to run JRiver MC15 and decode flac files, to the BelCanto Usb Link (so it could be lowered even more).

Alas, the sound is far worst than with the netbook connected to the Link directly, and pulling data from the very same (old) pc.

Will try back to 2.6 for the sole goal of testing.

 

Still, have to test this combination (old pc) with the int202, but this one is not isolating its outputs from the power source (either firewire or external), and I suspect the pc power supply has something to do with it.

 

@Mani Just when you think you've reached the pinnacle, the world of computer audio just opens up to reveal higher vistas to set your sights on...

 

I never thought I had reached the pinnacle, but I definitely agree with the rest of your comment :(

 

Elp

 

Link to comment

You are right that there were other players but IIRC most had been dropped a while before their big "we believe so much in our DS players we aren't going to build CD players any more" statement. They also (a long time ago) had the excellent CD12.

 

I just think Linn's statement had more to do with "free" advertising than anything else...

 

Eloise

 

Eloise

---

...in my opinion / experience...

While I agree "Everything may matter" working out what actually affects the sound is a trickier thing.

And I agree "Trust your ears" but equally don't allow them to fool you - trust them with a bit of skepticism.

keep your mind open... But mind your brain doesn't fall out.

Link to comment

to each their own when it comes to the sound, although I always like to understand the technical story.

 

The Akurate CD was also discontinued this year, apparently. You'll also hear that dedicated followers of the Linn LP12 turntable rather rate the Klimax DS.

 

I'm not knocking the dCS, I don't know much about it, and I imagine that in well set up systems, both would be pretty bloody marvellous. But some practical considerations:

 

When listening quietly, at night, will you hear the mac mini's fan?

Does the mac mini play nice with the power supply?

What happens if you have a really large collection - is there room on the mac mini?

How do you listen to the music stored on the mac mini in another room? Two other rooms? In the bath? On the patio? :)

 

As I commented, no one is writing off Ethernet as having a place within a computer audio system, just it seams that at the current time there are other options which offer as good, or better, possibilities.

 

I don't think any of the other options have been established as better, Eloise? When did that happen? I really am open to it, but come on - for most of this thread I've been painstakingly explaining what an ethernet dac / network dac / UPnP AV renderer / thingummy is, you might want to give it some more consideration - not about whether it has a place, but about the potential of the architecture to be superlative.

 

Then, the OP, who asked a question which will be sensibly asked by anyone using a short-range interface, is spared a big headache. His question becomes irrelevant. Get the cheapest, nastiest NAS you can find, stick it in the garage, and forget about it. Or use an existing PC in a study. Etc. The only, only, only thing that affects the sound is the network dac (I've settled on that). Then listen to music and stop f'ing about with computers. There's extra initial setup - you have to set up a network. Once that's done, you're home free.

 

ZZ

 

p.s. this bit: though we don't know how the [DS] device works internally to pipe the output of the music file into the DAC section - I think I was editing my previous post to include an explanation of exactly that, as you were typing, so sorry about that.

 

Link to comment

Alright, Clay, let's see about this. Describing Swenson's 3 box approach, you said:

 

FWIW, 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.

 

If the DAC clock is master, then the link isn't async, is it? It's synchronous. No opinions here, it's either one, or the other.

 

The whole point of the three box design must be to provide as much isolation of the dac chip as possible. That means the absolute minimum is going on inside the last box, aside from its key purpose of digital to audio conversion. That has to mean that the link from the streamer (the second box) to the last box is synchronous, which the dac can feed on directly, with no further processing. Otherwise, what's the point of having an intermediate box?

 

ZZ

 

Link to comment

Eloise says (and with which I wholeheartedly agree):

 

"As I commented, no one is writing off Ethernet as having a place within a computer audio system, just it seams that at the current time there are other options which offer as good, or better, possibilities."

 

ZZ replies:

"I don't think any of the other options have been established as better, Eloise? When did that happen? I really am open to it, but come on - for most of this thread I've been painstakingly explaining what an ethernet dac / network dac / UPnP AV renderer / thingummy is, you might want to give it some more consideration - not about whether it has a place, but about the potential of the architecture to be superlative."

 

re your two questions, Firewire and Async USB interfaces have established themselves in the marketplace (and in the hearts & minds of Computer Audiophiles here) over the course of the last year or more due to delivering on the promises of their architectural advantages, as espoused by their supporters, and even creators (e.g. Gordon Rankin of Wavelength Audio, who originated the very idea of USB-based DACs for computer audiophile playback).

 

Despite your apparent (and erroneous, IMO) belief that Firewire and USB are emulating (the advantages of) Ethernet, computer audio interfaces offering Ethernet are quite LATE to the party - well behind even Async USB, which is well behind devices such as the original Metric Halo Digital audio interfaces - and now will have to offer quite good performance to be considered other than an also ran, or niche product.

 

Also, you are quite late to the party as well, missing out on the discussions ad nauseum about Async interfaces, in which Ethernet was often allowed to ride on the coattails of discussions of the theoretical superiority of Async USB/Firewire interfaces, despite that there were/are precious few (if any) available at the time.

 

That I've not seen/heard any theoretical advantage of Ethernet that I believe is (significantly) superior (sonically) to the advantages I and others have reported for Firewire based interfaces is the basis for my agreement with Eloise that "at the current time there are other options which [already] offer as good, or better, possibilities" [as Ethernet-based interfaces].

 

In rapidly changing marketplaces, fast followers (i.e. Async USB on the coattails of Firewire) can do well - often better than earliest adopters (witness Apple) - but being late to the party can be a problem, as the bar has already been set (i.e. expectations are high), and turf (i.e. mindshare) has been claimed.

 

Like Eloise, I've not written off Ethernet, but will admit that it will take a lot for an Ethernet-based device to move me from my preferred Firewire interface as now served by the Metric Halo LIO-8.

 

And this movement will have to come from firms who lead and deliver with solid engineering advantages, not those who make marketing proclamations like "we're so thrilled with our new whatzit, that we're no longer making our former whatwazzit".

 

Again, I'll repeat what I've said in every post thus far, show us Ethernet-based DACs that bests the incumbent Firewire / Async USB DACs.

 

Absent that, all this talk about architectural advantages is just that, talk.

 

Just my opinion, and I don't expect it to become yours or anyone elses.

 

 

cheers,

clay

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Link to comment

"Alright, Clay, let's see about this. Describing Swenson's 3 box approach, you said:

 

FWIW, 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."

 

While I did post those exact words, they were not a description specific to John Swenson's 3 box approach. They apply universally, IMO, to interface types being used for computer audiophiles.

 

OTOH, for purposes of this reply, let's supppose I did intend them to describe John's Swenson (as you did) in your post.

 

You say:

 

"If the DAC clock is master, then the link isn't async, is it? It's synchronous. No opinions here, it's either one, or the other."

 

Definitions of async interfaces might vary I suppose, but, in my mind, having the DAC clock as the master is the defining characteristic of an asynchronous interface (for computer audio playback), i.e. the data flow is now being delivered asynchronously of any upstream clock, allowing the clock in the DAC to function as the Master. Keeping an upstream clock in sync with a separate clock in the DAC (i.e. the master clock) is the condition to be avoided (and is the definition of a synchronous interface commonly accepted here on CA) if one wants the least engineering obstacles to good sound.

 

 

 

you also say: "The whole point of the three box design must be to provide as much isolation of the dac chip as possible."

 

possibly, but you'd have to ask John Swenson as the 3 box design is his. Perhaps I could agree with you if you said that the point of the three box design is provide the ideal amount of isolation, which is different from providing 'as much as possible'.

 

"That means the absolute minimum is going on inside the last box, aside from its key purpose of digital to audio conversion."

 

Assumption noted, but it's an erroneous one, IMO, if taken to the extreme - as you seem to do - of removing the clocking from the last box. OTOH, it is an important engineering principle agreed upon by many, which ironically, is the reason I believe that DACs with Ethernet inputs create as many (possibly more) problems than they solve (about which more in a separate post).

 

"That has to mean that the link from the streamer (the second box) to the last box is synchronous, which the dac can feed on directly, with no further processing."

 

Assumption based on previous assumption noted.

 

As I understand it, the 3 box design is NOT designed to provide the least amount of processing in the final 'box' as you surmise.

 

More importantly, however, most every DAC designer whom I respect believes that it is very important that clocking be done by the DAC's clock to avoid synchronous clocking issues, and the resultant jitter.

 

In this thread, http://www.computeraudiophile.com/content/New-Dichotomy-Async-vs-Non-async-DACs ... and countless threads elsewhere in CA, Gordon Rankin offers the central advantage of asynchronous interfaces (for computer audio playback, i.e. DACs):

 

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

 

 

You might pick up a thing or two from the thread noted above.

 

Cheers,

Clay

 

 

 

Link to comment

"Does anyone see the logic in what I'm going on about in this thread?"

 

 

here's a view - as seen from my perspective.

 

One of the points of your argument for Ethernet inputs on DACs is the provision for asynchronous transmission of data. Yet you seem not to realize that Firewire and Async USB already provide this in a large and growing number of high-quality DACs. Ergo, this is not an advantage for Ethernet, it is merely the price of entry (aka table stakes).

 

Another purported benefit of the Ethernet input DACs is that by taking a portion of the processing that now occurs within the computer and placing it in the same box as the DAC, we can move the remainder of the computer farther away.

 

Here's a thought on that:

If the computer environment is so bad that we need to move it so much farther away, why would we want to mix any of that in with our DAC (where the sensitive conversion and clocking of data occurs)? It seems a bit like saying, let's take a small bit of the cancer and implant it in one's head as that will allow us to place the remainder of the cancer as far away as possible, our foot for example. ;0

 

Better just to reduce the cancer overall, IMHO.

 

Whether this (movement of processing into the DAC is actually an advantage remains to be proven, by ANYONE, in practice (or even in theory, as far as I'm concerned)

 

While it might make philosophical sense to some, I'm not convinced that it follows any 'logic'. It's basically just a different architectural approach. Were I a product designer needing a new approach in order to position myself as providing a unique solution it might have some value. But as an obvious 'win-win' solution, with benefits anyone can see, I don't think so.

 

 

There are several non-architectural factors that impact the likelihood of selling this claimed architectural advantage to the audiophile community.

 

For starters, the companies that make such DACs will need knowledge of not only high quality analog, high quality digital and digital to analog conversion, but also the company will need to know how to include ethernet processing into the same box without any possibility of negative impact, lest it take two steps backward while attempting to march forward. All this is required, as I said, just to reach entry level of providing async data to the DAC, as the bulk of the Ethernet advantages (as seen from here) are already provided elsewhere.

 

More importantly, we will also have to rely on these companies to provide a user interface & user experience that is equivalent to what is provided now with, e.g., iTunes, Amarra, Pure Vinyl/Pure Music, Wave Editor, Play and an entire ecosystem of world class audio applications - and these just for the Mac interface alone (barring any hocus-pocus that will make Ethernet transmission look & behave EXACTLY like current data streaming approaches from the point of view of the music players).

 

Either that, or this ecosystem has to be convinced to provide versions of their software which will support transmission via Ethernet. Irrespective of any protocols such as uPnP that are available, each of these companies would need to see the advantages of providing support for Ethernet.

 

Or thirdly, the Ethernet-based DAC manufacturers have to convince a significant number of users (in order to reach critical mass) to give up the(ir) current ecosystem for a brand new one - with little more being offered in return (IMO) than being different than the others. [of course, that alone will attract more than a few, but not likely enough to remain solvent, let alone change the paradigm].

 

 

Eloise, please correct any mischaracterizations I might have made with respect to what will be required of a new Ethernet-centric ecosystem that would seem to be needed. I know you're 'up' on all these topics.

 

 

cheers,

clay

 

 

 

 

 

 

 

 

 

Link to comment

clay comments... "Either that, or this ecosystem has to be convinced to provide versions of their software which will support transmission via Ethernet. Irrespective of any protocols such as uPnP that are available, each of these companies would need to see the advantages of providing support for Ethernet."

 

You make a good point that the implementation of an "Ethernet DAC" is beyond the experiences of most audio companies. As you comment, even where UPnP is available for use as the underlying protocol there is much work to be done on the "computer" side of the DAC.

 

Do you stick with the basic UPnP protocols which are fully supported, but generally are limited to WAV, FLAC, MP3 and AAC, have no support for gapless playback, require the playlist to be maintained on the controller so this needs to be connected for play to continue, etc. Or you can follow Linn's example and build extensions for on device playlists, gapless playback, control of Pre-amp, etc. and support a wider range of formats including AIFF and ALAC.

 

Or head off in a different direction like Micromega who have built an "Airport Express on Steroids" by adapting the standard Apple hardware. (And get criticised for it's extravagant pricing!!)

 

Or the third route of building a complete "Hard Disk Player" like Naim did with their HDX - but which has the problem of being basically a computer in a pretty box (though with solid software built in). Incidentally Naim - a great proponent of upgrading via power supplies - stick with quite a basic PSU for their HDX and include the DAC in the box (though this can have an upgraded PSU) and don't seam to feel there is a problem.

 

Ziggyzack asked the question about noise levels of a MacMini. To me a MacMini has never had noise beyond normal background noise of a room - though living in a town the place is never silent. On the other hand Chris' C.A.P.S. server is literally silent having no moving parts (no fans and utilising a SSD).

 

Eloise

 

Eloise

---

...in my opinion / experience...

While I agree "Everything may matter" working out what actually affects the sound is a trickier thing.

And I agree "Trust your ears" but equally don't allow them to fool you - trust them with a bit of skepticism.

keep your mind open... But mind your brain doesn't fall out.

Link to comment

Thanks Eloise

 

 

"Ziggyzack asked the question about noise levels of a MacMini. To me a MacMini has never had noise beyond normal background noise of a room - though living in a town the place is never silent."

 

Good point, when listening in a city, the Mac Mini cannot even be heard. But in a completely quiet environment, their is a bit of fan noise that could be heard.

 

The most significant advantage claimed by ZZ is that you could put the nastiest PC available in a closet somewhere and it wouldn't matter (i.e. it wouldn't effect sonics) IF you were transmitting data via Ethernet to the DAC.

 

 

Firstly, this assumes, as I stated previously, that an audiophile manufacturer can add the additional processing required INTO the DAC without creating even a trace (no pun intended) of negative influence on the sonics.

 

Secondly, it also assumes that the Ethernet connection mechanism is not also an entry point for electromechanical noise into the DAC. It's often stated that wireless tranmission of any kind can impact sonics of sensitive circuitry. Mechanical connections allow for vibrations or worse to go along for a ride to the DAC. note: this is not any different than with other wired tranmissions, just making the point that the 'nastiest' PC would likely take better advantage of this entry point.

 

As those of us who have followed the advent of Async USB know, it was assumed that Async transmission would eliminate the effects of upstream processing. This has not turned out to be the case, and we do not yet know precisely why. It appears that the 'everything matters' principle comes strongly into play here.

 

The factors impacting sonics are NOT just the generic noise components of the computer environment, but rather each bit of processing (including the rather miniscule processing required by software players for bit-perfect transmission) seems to impact sonics (even when separated from the DAC by Async transmission).

 

Let me repeat that - even the miniscule processing required to simply decode and transmit bit perfect data to the DAC impacts sonics.

 

Are we sure we want to put this same sort of processing INTO the DAC?

 

In my opinion, adding and optimizing ANY processing like this INTO the DAC without impacting it's clocking (and other circuitry quite sensitive to adverse impacts) seems much more challenging a task than minimizing it's impact on the other end of a USB or Firewire cable.

 

Back to the nastiest computer in a closet scenario, a computer will impact any AC circuit its connected to by injecting noise which will ride up and down the line to (and perhaps beyond) the circuit breaker box, as well as up and down other circuits connected at the breaker box (or so say minds much more knowledgeable about this than mine). So we still need to 'minimize' the negative contributions of the computer, even if stuffed in a closet.

 

 

Just my perspective, your opinion may vary, and frankly, it should.

 

Clay

 

 

 

 

 

 

 

Link to comment

If you want to buy yourself some peace and quiet, pointing me to a 150-odd post thread is probably not a bad way to do it. ;) I've read it, and some of the links it referenced. Thanks.

 

@Eloise

 

I think that you are not saying that UPnP places a limitation on file formats, but let me clarify further. From the UPnP AV spec (note we are not talking about UPnP throughout this discussion, but UPnP AV):

 

The AV Architecture defines the general interaction between UPnP Control

Points and UPnP AV devices. It is independent of any particular device type, content format, and transfer

protocol. It supports a variety of devices such as TVs, VCRs, CD/DVD players/jukeboxes, settop boxes,

stereos systems, MP3 players, still-image cameras, camcorders, electronic picture frames (EPFs), and the

PC. The AV Architecture allows devices to support different types of formats for the entertainment

content (such as MPEG2, MPEG4, JPEG, MP3, Windows Media Architecture (WMA), bitmaps (BMP),

NTSC, PAL, ATSC, etc.) and multiple types of transfer protocols (such as IEC-61883/IEEE-1394, HTTP

GET, RTP, HTTP PUT/POST, TCP/IP, etc.).

 

Here's a link to the spec (well, more of an overview). It's not too long. The quote above is from the intro. If anyone is interested, Sections 5, 5.1, 5.2 and 5.3 explain the three-way split between servers, control points and renders (you can skip the subsections, like 5.1.1 etc.)

http://upnp.org/specs/av/UPnP-av-AVArchitecture-v1-20020625.pdf

 

Note that UPnP AV is entirely agnostic of the file format, and indeed of the transfer protocol (I didn't realise the latter point until now). You can run UPnP AV over firewire - who knew? It is down to the renderer to support flac, lpcm, aiff, etc.

 

UPnP AV has some flaws, but is extendable. Linn have open-sourced their extensions, so anyone can implement them. The Linn extensions, as you say correctly, permit gapless playback (how on earth did the UPnP AV lot miss that???), on device playlists (which means that if you shut down your control point software, the music keeps playing beyond the end of the current track), and allow multiple control points and players. But they have nothing to do with wider format support (your post could be read as suggesting that they do, although I don't think that's what you meant).

 

As I say, the extensions have been opensourced, so anyone can build a player (or renderer, in UPnP AV parlance) and/or a UPnP AV control point with this functionality. The extensions don't apply to UPnP AV servers. Any control point will work with a Linn DS player, but only those implementing the Linn extensions can take advantage of the associated features in the player. I understand Linn are making efforts to have their extensions incorporated into a future version of the UPnP AV spec.

 

@Clay

 

Regarding the UPnP AV ecosystem, try wikipedia! Have a click - I was surprised by the extent of it, and it's far from comprehensive. I can think of at least six developers who provide UPnP AV control points with Linn extensions, each supporting at least one of Windows, Mac, iPhone, iPad, Linux, Nokia MIDs, Windows pdas, with many talking about Android support to come.

 

UPnP AV is an open standard. Software developers can design control points that comply with it, and adapt existing software to become compatible with it (you won't see iTunes going that way though, although I think I've heard talk of someone building an iTunes library adaptor software ;)). This is happening.

 

That long thread you pointed me to had several people popping up and saying 'well, what about ethernet?' It was a considerably more open minded and well-informed thread than this one. Summoning up the courage to quote you from your ZZ redux post: Firewire and Async USB interfaces have established themselves in the marketplace (and in the hearts & minds of Computer Audiophiles here) over the course of the last year or more... Well, great! But this website is called Computer Audiophile, not Mac and Firewire/USB audiophile, and you wouldn't think that having read this thread.

 

By the way, you're not off the hook about your very suspect definition of async (you are NOT saying what Gordon Rankin is saying, even if you think you are;) and what constitutes a computer (those firewire and async usb interfaces are doing more work than you may wish to believe, which will be interesting for you too, Eloise!) But that will have to be for a later instalment. Not trying to change your mind, or opinions, but to give some balance for the three people who are still reading.

 

:)

 

 

 

Link to comment

ZiggyZack commented... "It was a considerably more open minded and well-informed thread than this one. Summoning up the courage to quote you from your ZZ redux post: Firewire and Async USB interfaces have established themselves in the marketplace (and in the hearts & minds of Computer Audiophiles here) over the course of the last year or more... Well, great! But this website is called Computer Audiophile, not Mac and Firewire/USB audiophile, and you wouldn't think that having read this thread."

Erm ... neither is is called Ethernet Audiophile yet the way you are preaching you seam to feel that using Ethernet and UPnP AV is the only way. What I (and clay) have stated lots of times is that Ethernet does have the potential, but apart from a small number of devices, it has not proven to be a winner over having a computer (off the shelf or custom) connected to a DAC, either via async (USB or FireWire) interface or even via a dinosaur^h^h^h^h^h^h^h^hSPDIF connection.

 

The early question was about influence of the computer on sound quality - one thing you've not commented on is how the software influences sound quality even when the hardware stays the same. This is true of a UPnP AV device just as much as with a computer.

 

At the end of the day, what is really important is the sound quality - something that (currently) few UPnP devices offer vs. a traditional computer and DAC situation.

 

Eloise

---

...in my opinion / experience...

While I agree "Everything may matter" working out what actually affects the sound is a trickier thing.

And I agree "Trust your ears" but equally don't allow them to fool you - trust them with a bit of skepticism.

keep your mind open... But mind your brain doesn't fall out.

Link to comment

 

 

Thanks for the pointer to wikipedia on uPnP. When time permits, I'll be there.

 

Re the quoting of my comment about Firewire/Async USB, the message intended by that comment is a LOT of discussion/debate/inquiry occured here on CA, including even folks like Gordon Rankin. I was not trying to suggest, as you imply, that this forum is all about those interfaces, only that there is a body of work here adapted over hours and countless threads. This includes even the definition of Asynchronous interfaces (as applied to DACs). IOW, the definition you call suspect is the consensus definition of the group here.

 

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.

 

For the life of me, I cannot understand why you have issues with the definition of Async that I provided, esp. after reading the thread. Perhaps you can provide your own different definition?

 

It seems to me that you're stuck on a model that requires a clock other than in the DAC, but I could be wrong. FWIW, this is my impression due to your apparent insistence on a 3 box solution requiring a Synchronous link (i.e., two clocks needing to remain in sync).

 

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. The point of Gordon's quote is that we want to avoid an oscillator in the DAC having to remain in sync with a moving clock upstream.

 

 

 

"But that will have to be for a later instalment. Not trying to change your mind, or opinions, but to give some balance for the three people who are still reading."

 

Looking forward to the later installment. For better perceived 'balance' you'll need more people who support your contentions. ;0

 

As someone who helped carve out the Firewire/Async USB turf (aka mindshare), I'm capable & willing to provide debate fodder for those with different ideas. That's how ideas are advanced, here and elsewhere. OTOH, true advancement comes in the marketplace.

 

RIght now the Klimax appears to be 3 to 4 times more expensive than the established Firewire/Async USB/S-PDIF market leaders, and there's all that work to do creating music players that offer advantages over the incumbents, who (other than iTunes) are NOT standing still.

 

There are three major Mac OS X software providers working on SOTA music playing software (Sonic Studio / ChannelD / Audiofile Engineering), and a dark horse candidate that sounds better than all of them (to my ears).

 

IOW, Lots of catchup for the uPnP providers.

 

cheers,

clay

 

 

 

 

 

 

 

 

 

 

 

 

Link to comment

This includes even the definition of Asynchronous interfaces (as applied to DACs). IOW, the definition you call suspect is the consensus definition of the group here.

 

...

 

 

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.

 

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

 

Synchronous, in this context, has nothing whatsoever to do with synchronising clocks. It is a relative term, indicating that a signal is being sent at the rate expected by a receiver. 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.

 

One way to do that would be to use two clocks, one for the sender, and one for the DAC, timed as identically as possible. Then, use a PLL near the DAC clock to lock on to the signal received and fine tune the DAC clock.

 

Another way is to send the clock signal from the DAC clock up to the sender, so that both the sender and the DAC are clocked identically. This way, the phasing and frequency of the signal reaching the DAC are more in step with the DAC, no PLL is required, and a more accurate fixed frequency clock can be used.

 

In both cases, the signal is a synchronous signal. The difference is that the implementation in the latter case is much better suited to a hi-fi DAC. When you say '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', you are incorrectly conflating the use of a master clock with asynchronous transmission.

 

There is asynchronous transmission going on, but for a USB DAC, it's happening across the USB interface. A given version of USB operates at a fixed signal rate, and its physical interface will have its own clocking, I imagine using a clock at each end, and a PLL. As a curiosity, Wikipedia gives clock tolerance figures of ±500 ppm for USB 2.0, aiming for 480.000Mbps, and ±2500 ppm for USB 1.1, aiming for 12.000Mbps. However, these timings have little to do with the timings of the music data moving across the interface.

 

The asynchronous USB interface in the DAC will be programmed to request data from the computer. How does it know when to do this? Via a buffer, which can store the short, sharp bursts of data sent over the USB interface, ready to be read out at a rate controlled by the DAC clock. The buffer sits just after the USB interface and before the DAC chip. The interface's control program monitors the buffer, and when it gets low, it requests a top up, which the computer delivers.

 

Note that there are two logically separate signal paths. One from the buffer output to the DAC, controlled by a single clock, which is synchronous. Another across the USB interface, which is asynchronous. In between is the buffer, which has an asynchronous (with respect to the DAC) feed in, and a synchronous (with respect to the DAC) output. If we were talking about the USB interface sender and receiver, operating at say 480Mbps, we'd say the link between them was synchronous - it's a relative term.

 

Why use asynchronous across the interface? Prior to Gordon Rankin's work, USB DACs could at best use adaptive mode, in which data was 'pushed' from the computer at a given rate dictated by a clock in the computer, and the clocking had to be recovered on the DAC side. In this case, the link between buffer and DAC is still synchronous, but so is the link across the interface. I don't think there's any argument about why this is sub-optimal, but the down-sides include: the accuracy of the computer's clock, the computer's electrical and RF environment, the accuracy of the USB interface's clocking, the need to use a variable DAC clock, and the need to synchronise the DAC's clock to the incoming stream with a PLL.

 

The reason I've gone to such length to clarify 'synchronous' and 'asynchronous' is because it reveals the architecture of the USB DAC, particularly with regard to the buffer. Please read once more the two approaches to running a synchronous link, which I described at the beginning, but considering the buffer to be the sender (and keeping the DAC chip as the receiver). Hopefully this will help explain why you're confused about my understanding of Matan's and Swenson's three box model:

 

It seems to me that you're stuck on a model that requires a clock other than in the DAC, but I could be wrong. FWIW, this is my impression due to your apparent insistence on a 3 box solution requiring a Synchronous link (i.e., two clocks needing to remain in sync).

 

You also said it's an erroneous [assumption], IMO, if taken to the extreme - as you seem to do - of removing the clocking from the last box.

 

For the sake of brevity, I didn't list everything which would need to be included in the last box of a three box system. The DAC chip would probably need power and an output stage for one thing - so you've read a bit too much into that. In fact, looking back at my 'general agreement' post, I said this:

 

It sounds like [Matan] has done something along the lines of splitting the second box in the Linn system between the buffer (box 2) and the dac (box 3), so there must be a clock signal running from the dac box back to the buffer/streaming box, to keep those in sync.

 

Perhaps that will now make more sense to you. It is my educated guess that the intermediate box will contain the interface, which could be ethernet, USB, Firewire, or something custom. But it will definitely be buffered, as that is an essential ingredient of an async interface. The DAC will be in the last box. Between the buffer and the DAC, the link MUST be synchronous. You could put the clock in its own box - what's another box when you already have three? - or put it with the dac and run a sync cable to the buffer, or put it with the buffer and run a sync cable to the DAC. Having the buffer, DAC and clock in close proximity would be a benefit, so maybe just the interface and control logic should be in the intermediate box. Or have amazing isolating case design, and achieve good isolation with the short signal paths only possible in a combined box. You can begin to see how these decisions become rather fine.

 

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.

 

I'll add that on the first page, I see that I said 'buffer' 12 times. Eloise mentioned it once. That accounts for all the mentions in this thread, this post aside. Please give me the benefit of the doubt to begin with, instead of focusing on picking holes.

 

Last point - that USB interface was rather busy, wasn't it? Here's two links to wikipedia, on what USB gets up to. Just have a glance - it should be enough to make you reconsider the notion that USB is somehow more benign than other interfaces.

 

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

http://en.wikipedia.org/wiki/Non-Return-to-Zero_Inverted#Non-Return-to-Zero_Inverted_.28NRZI.29

 

I'll finish with a couple of quotes from Gordon Rankin, from the long thread, only to show that what I've written here is consistent with them:

 

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.

 

and

 

if the interface is not asynchronous then the clocks have to move and that creates jitter. Any Adaptive and any Firewire using native device drivers would fall into this category as well as any SPDIF.

 

 

Link to comment

Can I point you in the direction of dCS (who know a thing or two about DACs) for their definition of Asyncronous USB

 

In USB, there are numerous modes for synchronising the audio between the PC (the host ), and an audio device. The most popular of these, Adaptive, is where the audio device synchronises itself to the USB "frame" provided by the PC. This tends to be relatively poor in terms of both absolute frequency and jitter. The one used by the upsampler is called "Asynchronous" (NOT to be confused with asynchronous rate conversion). In this scenario, the audio device synchronises the audio by providing a feedback pipe to the PC. The PC then is effectively locked to the audio device, which can have a much more accurate clock and much lower jitter. In our case, the use of a master clock can mean excellent absolute frequency as well.

 

They also have an opinion on the USB vs. Ethernet question we're discussing here...

 

USB is isochronous. This means that the host & client both know how much bandwidth is available at the outset, and the host can guarantee that bandwidth will be available all the time. Ethernet/wifi cannot guarantee bandwidth - there is a concept of "Quality of Service", but this is not set in stone - especially with wifi. The mechanism for transmitting real-time audio over Ethernet is not especially well defined.

 

Eloise

---

...in my opinion / experience...

While I agree "Everything may matter" working out what actually affects the sound is a trickier thing.

And I agree "Trust your ears" but equally don't allow them to fool you - trust them with a bit of skepticism.

keep your mind open... But mind your brain doesn't fall out.

Link to comment

"And how is that inconsistent with what I have put? Show that you've at least tried to understand my explanation, Eloise. At best, you have your head in the sand."

 

Your explanation is wooly and long winded and in some places (I believe) inaccurate - it's difficult to follow. My post was attempting to offer a concise definition for the help of all (and also in support of Clay who offered a similar explanation / definition). I added the Ethernet comment as an aside as to why connecting a DAC via Ethernet (without using UPnP AV which -IMO- turns the DAC into a computer as I've stated) may be a bad idea.

 

Edit: Your own definition (for example) begins by saying (at east to me it implies) that the opposite of an asynchronous USB link is a synchronous one -- you use the term synchronous several times -- it isn't the opposite (alternative) to an asynchronous USB connection is an adaptive connection.

 

On the other hand dCS definition I posted is the generally accepted (layman's) definition of Asynchronous USB connection (for audio) using Class 1.0 Audio specification created by the USB Consortium. The definition of Asynchronous USB Audio has nothing to do with the definition of the word "asynchronous" as defined by the Oxford English Dictionary (and leave the Queen out of it!!) as it is a technical definition used in a specific way for this purpose.

 

Eloise

 

Eloise

---

...in my opinion / experience...

While I agree "Everything may matter" working out what actually affects the sound is a trickier thing.

And I agree "Trust your ears" but equally don't allow them to fool you - trust them with a bit of skepticism.

keep your mind open... But mind your brain doesn't fall out.

Link to comment

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

 

ZZ - It's really hard to give you the benefit of the doubt based on the language you use. Plus, it's really hard to believe anything you say because you seem to be learning as you go. I could be totally wrong, but you've called yourself a punter previously.

 

I think there is so much speculation and theory being discussed that there is little to be gained in this thread.

 

I wish someone who has designed a DAC with a USB interface, preferably asynchronous, would jump in and offer some information.

 

Founder of Audiophile Style | My Audio Systems AudiophileStyleStickerWhite2.0.png AudiophileStyleStickerWhite7.1.4.png

Link to comment

Count me on the 3 readers, but I'm getting bored about the tone.

 

I've been having this very discussion on a french forum, and it led to nowhere. I was the defender of the usb/firewire camp.

 

All in all, the uPnP AV protocol is having a great advantage : this you can contribute easily, in many forms, so that every kind of composition is conceivable. From the UI point of view, you could start with MC15 (sorry mac geeks).

 

But, at the moment, the correct ratio price/(performance + ergonomy) rather lies on the usb/firewire/computer side.

 

You can even mix both to your needs.

Please, put an end to this nightmare ! ;)

 

Elp

 

Link to comment

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

As I commented ... the definitions of Asyncronous USB have nothing to do with QED or general English definitions. Asyncronous USB is defined as part of the USB Consortium Class 1.0 Audio definitions (I think I have referred to it correctly). It is not defined by this group, or created by Gordon or dCS - though they were the first to implement it (not sure who came first).

 

Synchronous, in this context, has nothing whatsoever to do with synchronising clocks. It is a relative term, indicating that a signal is being sent at the rate expected by a receiver. 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 are correct here...

 

One way to do that would be to use two clocks, one for the sender, and one for the DAC, timed as identically as possible. Then, use a PLL near the DAC clock to lock on to the signal received and fine tune the DAC clock.

This describes Adaptive USB. Only from the PLL to the DAC is the system synchronized.

 

Another way is to send the clock signal from the DAC clock up to the sender, so that both the sender and the DAC are clocked identically. This way, the phasing and frequency of the signal reaching the DAC are more in step with the DAC, no PLL is required, and a more accurate fixed frequency clock can be used.

This situation would describe using a DAC with a word clock output (or a separate word clock connected to both) and PCI (or other interface) with a word clock input.

 

In both cases, the signal is a synchronous signal.

No they are not both synchronous. One is adaptive, the other is synchronous.

The difference is that the implementation in the latter case is much better suited to a hi-fi DAC. When you say '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', you are incorrectly conflating the use of a master clock with asynchronous transmission.

I don't think anyone IS considering using a Master Clock as being anything to do with Asyncronous.

 

There is asynchronous transmission going on, but for a USB DAC, it's happening across the USB interface. A given version of USB operates at a fixed signal rate, and its physical interface will have its own clocking, I imagine using a clock at each end, and a PLL. As a curiosity, Wikipedia gives clock tolerance figures of ±500 ppm for USB 2.0, aiming for 480.000Mbps, and ±2500 ppm for USB 1.1, aiming for 12.000Mbps. However, these timings have little to do with the timings of the music data moving across the interface.

Now you are baffling with science. With Asynchronous USB the clock rate of the USB interface is no longer relevant.

 

The asynchronous USB interface in the DAC will be programmed to request data from the computer. How does it know when to do this? Via a buffer, which can store the short, sharp bursts of data sent over the USB interface, ready to be read out at a rate controlled by the DAC clock. The buffer sits just after the USB interface and before the DAC chip. The interface's control program monitors the buffer, and when it gets low, it requests a top up, which the computer delivers.

Exactly - creating a system where the output of the buffer is 100% independent of the input. They two are not completely asynchronous - both in USB Audio definition of the word asynchronous and OED definition.

 

Note that there are two logically separate signal paths. One from the buffer output to the DAC, controlled by a single clock, which is synchronous. Another across the USB interface, which is asynchronous. In between is the buffer, which has an asynchronous (with respect to the DAC) feed in, and a synchronous (with respect to the DAC) output. If we were talking about the USB interface sender and receiver, operating at say 480Mbps, we'd say the link between them was synchronous - it's a relative term.

Repeating your previous comment!

 

Why use asynchronous across the interface? Prior to Gordon Rankin's work, USB DACs could at best use adaptive mode, in which data was 'pushed' from the computer at a given rate dictated by a clock in the computer, and the clocking had to be recovered on the DAC side. In this case, the link between buffer and DAC is still synchronous, but so is the link across the interface. I don't think there's any argument about why this is sub-optimal, but the down-sides include: the accuracy of the computer's clock, the computer's electrical and RF environment, the accuracy of the USB interface's clocking, the need to use a variable DAC clock, and the need to synchronise the DAC's clock to the incoming stream with a PLL.

 

The reason I've gone to such length to clarify 'synchronous' and 'asynchronous' is because it reveals the architecture of the USB DAC, particularly with regard to the buffer. Please read once more the two approaches to running a synchronous link, which I described at the beginning, but considering the buffer to be the sender (and keeping the DAC chip as the receiver). Hopefully this will help explain why you're confused about my understanding of Matan's and Swenson's three box model:

Now you're preaching ... and I know clay understands this. As I say nothing in USB (or FireWire) is synchronous back to the computer.

 

It seems to me that you're stuck on a model that requires a clock other than in the DAC, but I could be wrong. FWIW, this is my impression due to your apparent insistence on a 3 box solution requiring a Synchronous link (i.e., two clocks needing to remain in sync).

I think you are missing the definition of Matan and Swenson's 3-box setup (this is as I remember it so may be incorrect).

 

Box 1 is the computer which stores the music and controls the playback - this is a "full" power device. This is connected via Ethernet to Box 2 which is a low (processing) power, single purpose box which converts the data sent via Ethernet into a signal which can be transferred to Box 3 via an optical (therefore electrically isolated) - box 3 is a stand alone DAC.

 

The idea of the 3-box setup is that you are isolating the physical noise of the computer (box 1) from the listening room and isolating the electrically noisy environment of box 2 from the DAC. The link between Box 2 and Box 3 is designed to be synchronous (clock is in the DAC, fed back to Box 2) IIRC.

 

You also said it's an erroneous [assumption], IMO, if taken to the extreme - as you seem to do - of removing the clocking from the last box.

Thats a matter of argument if a separate Word Clock is better than having the Master Clock as part of the DAC. dCS and Essoteric (to mention 2 experienced companies) certainly seam to feel separating the Word Clock improves the performance of their DACs.

 

For the sake of brevity, I didn't list everything which would need to be included in the last box of a three box system. The DAC chip would probably need power and an output stage for one thing - so you've read a bit too much into that. In fact, looking back at my 'general agreement' post, I said this:

By calling Box 3 a DAC - I considered it contained all the parts as per any other DAC device (rather than DAC chip) though the input would be custom rather than SPDIF or USB, etc.

 

It sounds like [Matan] has done something along the lines of splitting the second box in the Linn system between the buffer (box 2) and the dac (box 3), so there must be a clock signal running from the dac box back to the buffer/streaming box, to keep those in sync.

Actually you are quite accurate (at least to how I read it) in suggesting thats exactly what Matan's system is, however IIRC there is more processing of the signal in Box 1 and less in Box 2. I would compare it more to having iTunes running on Box 1, Box 2 is the equivalent of an AirPort Express and Box 3 is the DAC connected to the AirPort express - though everything built and programmed for more single purpose rather than general use.

 

Perhaps that will now make more sense to you. It is my educated guess that the intermediate box will contain the interface, which could be ethernet, USB, Firewire, or something custom. But it will definitely be buffered, as that is an essential ingredient of an async interface. The DAC will be in the last box. Between the buffer and the DAC, the link MUST be synchronous. You could put the clock in its own box - what's another box when you already have three? - or put it with the dac and run a sync cable to the buffer, or put it with the buffer and run a sync cable to the DAC. Having the buffer, DAC and clock in close proximity would be a benefit, so maybe just the interface and control logic should be in the intermediate box. Or have amazing isolating case design, and achieve good isolation with the short signal paths only possible in a combined box. You can begin to see how these decisions become rather fine.

 

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.

Really you just repeated and restated everything you had commented before about the 3-box setup.

 

I'll add that on the first page, I see that I said 'buffer' 12 times. Eloise mentioned it once. That accounts for all the mentions in this thread, this post aside. Please give me the benefit of the doubt to begin with, instead of focusing on picking holes.

Yes, all DACs require some buffer - however for most this is only a few samples worth IIRC. They are not large FIFO buffer such as used by the Chord QBD76 - this is a completely different issue!

 

Last point - that USB interface was rather busy, wasn't it? Here's two links to wikipedia, on what USB gets up to. Just have a glance - it should be enough to make you reconsider the notion that USB is somehow more benign than other interfaces.

I don't think anyone is saying that USB is somehow benign. However it is no worse than Ethernet is many cases.

 

I'll finish with a couple of quotes from Gordon Rankin, from the long thread, only to show that what I've written here is consistent with them:

No one is disagreeing asynchronous transfer is best - its how that asyncronous transfer is implemented.

 

Eloise

 

Eloise

---

...in my opinion / experience...

While I agree "Everything may matter" working out what actually affects the sound is a trickier thing.

And I agree "Trust your ears" but equally don't allow them to fool you - trust them with a bit of skepticism.

keep your mind open... But mind your brain doesn't fall out.

Link to comment

Thankyou for those words of sanity Elp ... you've summed up in a few words...

 

All in all, the uPnP AV protocol is having a great advantage : this you can contribute easily, in many forms, so that every kind of composition is conceivable. From the UI point of view, you could start with MC15 (sorry mac geeks).

But, at the moment, the correct ratio price/(performance + ergonomy) rather lies on the usb/firewire/computer side.

 

... what it's taken everyone else 70-odd posts to say!

 

Eloise

 

Eloise

---

...in my opinion / experience...

While I agree "Everything may matter" working out what actually affects the sound is a trickier thing.

And I agree "Trust your ears" but equally don't allow them to fool you - trust them with a bit of skepticism.

keep your mind open... But mind your brain doesn't fall out.

Link to comment

I am just a punter, I've said so every time you've asked. So is Clay. So is Eloise. So are you. I could be a retired astrophysisist, or the worst DAC designer in the world, and with your attitude (edit: to prejudging the value of contributor's opinions), you do risk following the latter.

 

You missed the significance of the architecture of the Linn system, and preferred the sound of the jittery spdif input (your prerogative, and it has to be said, a good chance of expectation bias). And fair enough, there was a lot to cover. But when an oversight is brought to your attention, surely you have to deal with it differently to the way you have? And then perhaps some of the guys on this thread will give the idea the time of day (cannot knock Clay for this, he hasn't responded yet, as I type. He said he would debate, and has been outspoken himself...;) edit: and see I have an Eloise post too... :) )

 

I've spent a fair amount of time finding a way to try to explain these concepts, and the explanation really should not be discounted out of hand. I'm not saying anything is better or worse in that post - just offering explanation.

 

Having said that, for expediency, some third-party corroboration (or otherwise) would help.

 

ZZ

 

P.S. Thanks to Elp for reading - I will keep it palatable!

 

Link to comment

@Eloise : U're welcome, it's always a pleasure to read your post, so I thought a little break would be appreciated.

 

@ZZ : I think you made your point. uPnP av is of great interest and might become a must have, if great products can make it to a maximum of people. Now, you are being a bit aggressive in the way you promote it. Especially against Chris that has delivered a huge review of the Linn product, with very comprehensive diagrams as to how to use it. I think Chris is on your side by doing so, and it is still ok (IMO) that he finds the spdif input better.

As for Eloise and Clay, there are always very helpful in trying to arise the debate (bad english, don't know how to say that). I do not always agree, but have learnt a lot from them.

 

Elp

 

Link to comment

All I'd say is that in the first part of my post, I wasn't describing Asynchronous USB or Adaptive USB. I was describing, generically, what a synchronous link is. I didn't mention USB until the sixth paragraph.

 

The reason I posted this at all was to follow up Clay's earlier post, where he had said, and stuck to when challenged, 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. Clearly, and as you seem to agree, this connection is not a USB connection, and it IS synchronous. So I needed to establish earlier on what a synchronous connection was.

 

Perhaps if read like this - moving from the generic to the particular - it will be less repetitive.

 

As for this bit coming up, I don't quite understand, but I should emphasise that this is not what I think, it was me quoting Clay telling me what he thinks I think! Here it is:

 

It seems to me that you're stuck on a model that requires a clock other than in the DAC, but I could be wrong. FWIW, this is my impression due to your apparent insistence on a 3 box solution requiring a Synchronous link (i.e., two clocks needing to remain in sync).

 

You also said it's an erroneous [assumption], IMO, if taken to the extreme - as you seem to do - of removing the clocking from the last box.

 

Which I think explains why you think I'm repeating myself again. Do keep up!!! :)

 

So, it seems to me like we're very close.

 

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.

 

I hope I'm not putting words into your mouth - we'll see :)

 

ZZ

 

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...