High-Speed or Low-Power?

[ggking7]

Is a discussion like this about how much noise a computer makes irrelevant if the DAC is properly isolated from the computer and the computer is on a power filter? It seems like filtering and isolation would be the easier and better route to take compared to minimizing the noise a computer makes.

 

[ziggyzack]

completely off the topic of "Low power or high power computers for best SQ?

 

Hopefully the OP isn't ticked off with this discussion. I think it's relevant, because we're acknowledging that computers aren't ideal environments for analogue electronics, and talking about strategies to keep analogue processes physically separate from highly desirable computer tasks.

 

I do really wish you would stop calling it an Ethernet DAC as it's not, it's a UPnP renderer or simply an Ethernet streamer.

 

I use that term because people also talk about USB dacs and firewire dacs, and people don't seem to be all that familiar with the term UPnP AV renderer.

 

When people talk about a streamer, this suggests something which is outputting a stream. Linn refer to their players as digital stream players, to make clear the fact that they receive a stream. They output analogue line-level audio.

 

I think you're a little confused about what UPnP AV is Eloise. It governs how UPnP AV devices communicate with each other, and interoperate. It's a protocol which sits on top of ethernet networks. But, you could quite happily stream a flac/wav/aiff file to a dac via ethernet without invoking UPnP AV.

 

In many cases people are connecting a UPnP streamer (such as the lower end Linn DS devices) to a secondary DAC via SPDIF.

 

The higher-end Linn DS devices don't have spdif outputs. Ethernet in, analogue stereo out. That's it. The reason being that a major point of the DS is that the synchronous stream between buffer output and dac input is managed by the same high precision and local clock. The lower end devices have spdif outputs, and people can use them if they wish - they will have to have a damn good secondary dac to improve on the analogue outputs though.

 

If you take a brief look at the Naim forum, many people have given up trying to get their NaimUnity to stream audio as UPnP is temperamental.

 

Naim, afaik, have more recently adopted UPnP, and don't make a pure UPnP renderer, but do make all-in-ones, with integrated amps and wifi. A pared down wired-ethernet-only renderer must be coming though. Perhaps they have some gremlins to iron out with their current implementations, but I'm sure they will.

 

On the topic of convenience, by the way, Mac minis don't have an hdmi output - but connect it with an ethernet cable into a upnp av TV and you should be in business.

 

But I would think very few people are actually worried abut such high quality audio in multiple rooms.

 

Doesn't have to be high quality audio. You can get cheap UPnP renderers, connected by wifi if so desired, and put them around the house - ever single one has access to your music library and can be remote controlled.

 

One of the original criteria of FireWire was for the real time transfer of digital audio from ADC to Computer and back to DACs. Nothing is "trying to emulate what Ethernet was built for" - UPnP works in a completely different manner from SPDIF / Async USB / FireWire connections. Infact is anything was "designed for audio" it would be FireWire where one of its original design briefs was to provide interface between DAC/ADC and a computer. Anyway they are pretty much all not better, not worse, just different and presenting different problems and issues.

 

Now that's just a cop-out! Taking UPnP to mean ethernet... well the main point is that ethernet delivers data asynchronously. Firewire (and I could really be wrong here, but I think...) was not originally developed to support asynchronous AV streams. USB I understand was designed for this originally, but drivers supporting USB's asynch capabilities aren't included with standard OSs. Spdif doesn't do asynch. So yes, there has been a lot of tweaking to firewire and usb to get them to do async. I would hazard a guess that in studio use, firewire isn't running in asynch mode, but the DACs and ADCs communicating over firewire interfaces are designed ground up for realtime data transfer, so wouldn't use asynch.

 

The whole point about ethernet is that it wasn't designed for audio. It was designed for robust networked data transfer. Treat music files as data, and in ethernet you have the perfect medium for distributing it and controlling it. UPnP AV provides an open standard sitting on top of this, where any UPnP AV devices on your network automatically find each other, know each others capabilities, and can communicate. Then, UPnP AV renderers will play media streamed by the UPnP AV servers, controlled by UPnP AV controllers. Key for the OP, the UPnP AV renderer is the only device that is concerned with analogue conversion. All the aspects that may need computer power, such as storage, cataloguing, retrieval, streaming, control, presentation and user interfaces, are entirely separate. All a UPnP AV renderer needs is an ethernet port, a dac, control logic, an analogue output stage and a power supply (prob missed a few things) - truly minimal design.

 

[ziggyzack]

Is this irrevelant if the computer is isolated? Is a discussion like this about how much noise a computer makes irrelevant if the DAC is properly isolated from the computer and the computer is on a power filter? It seems like filtering and isolation would be the easier and better route to take compared to minimizing the noise a computer makes.

 

Well, stating the obvious a bit, you don't want to hear the computer humming and whirring, but supposing that wasn't an issue: then the rest is down to getting the best performance from the dac and amps. Both these things benefit from clean power, and so if the computer is on the same circuit, it may be good to put a filter between the computer and the mains. But these things are very tricky - their worth will be determined by the capacity of the power supplies on the dac and amps to handle sub-optimal power conditions, as well as what else you have running on the circuit (dimmed low-voltage lighting is notorious). Some people run a dedicated spur from their distribution box to the hifi, but I never found out how this isolates the spur from the rest of the house.

 

Then, you have to get the music out of the computer and into the dac, which is when the debates about different connections start up. What are the maximum physical ranges of the connections, in case you do want to keep the computer box and dac box apart to some extent. How well isolated are the connections? And so on...

 

[BobH]

That none of all this hypothesizing and hand- wringing amounts to anything other than audiophile OCD if your system is silent when it's not playing anything.

 

[ggking7]

ziggyzack,

You quoted my question but I don't think you addressed it. I don't mean noise like "humming and whirring" but noise like electrical interference. If the computer is plugged into a good power filter and the DAC is galvanically isolated from the computer:

 

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

 

any and all hardware and software optimizations made to the computer (such as all those discussed in this thread) should be irrelevant as long as the computer is outputting bit-perfect. In that case, the computer can make as much electrical noise as it wants and it won't affect the sound whatsoever. Would you agree?

 

[ziggyzack]

I do agree with you, very much! Let a computer be a computer and a DAC be a DAC (Prince?). It really does come down to implementation though.

 

It's not just the DAC that is sensitive to noise, but so is any synchronous signal, including digital signals, so ideally clocking would not be managed within the PC. This is one reason why I'm so in favour of the PC 'output' being asynchronous.

 

Secondly, how well do the filters work? I've truly no idea, just posing the question, but it may be that there are benefits to having the hi-fi on a separate circuit (which is when the range of the connection between computer and dac may come into play).

 

Thirdly, I of course have to mention that galvanic isolation is mandated by the ethernet spec, to the tune of 1.5KV I believe.

 

ZZ

 

[vortecjr]

would this do the trick to provide galvanic isolation?

 

see attached picture

 

Jesus R

www.sonore.us

 

update: actually, it will not work as it needs drivers and the other end will not know what to do with it....

 

[cfmsp]

"ZiggyZack ... you are right ... back at the start you did say that a computer (or NAS) is still needed but your fundermental argument is about getting the computer out of the listening room"

 

The issue with Ethernet is that you will still need a 'computer' between the Ethernet and the DAC (i.e., INSIDE the Dac if it has Ethernet inputs, and therefore still in the listening room ;0) ) ...and the main value of Ethernet is that you get the data asynchronously and can clock it using the local (DACs) clock as master.

 

Better just to minimize the computing power on the computer and use Firewire (or Async USB) to drive the DAC, IMO, as it provides the same benefit. NOTE: this IS the topic of the OP!!!

 

Ethernet DACs have the potential to equal Firewire/Async USB I suppose, but with the current implementations one is left with only a handful of brands to consider, none of which are interesting to me personally (iow, I would not likely ever buy their products).

 

Wake me when an "ethernet DAC" improves upon the sound (for equivalent price) of the ULN-8/LIO-8 boxes, the top Weiss DACs *such as 202), or the Berkeley DAC (or even Mani's Model Two).

 

YMMV, IMHO, etc, etc,

 

clay

 

 

 

 

 

 

 

 

[vortecjr]

I have to agree with my buddy Clay! BTW how are things Clay?

 

Jesus R

www.sonore.us

 

[Audio_ELF]

I hope entitling your post with my name wasn't shooting the messenger ...

 

"The issue with Ethernet is that you will still need a 'computer' between the Ethernet and the DAC (i.e., INSIDE the Dac if it has Ethernet inputs, and therefore still in the listening room ;0)"

 

That was my whole point!! It maybe custom chips and OS, but it's still a computer. With Linn you don't even eliminate SMPS (another point raised) as they use SMPS in their devices.

 

Eloise

 

[cfmsp]

 

Eloise,

Not to worry, I was agreeing with you!

 

FWIW, if one truly believes the 'computer' (however small and embedded it might be) shouldn't be in the same listening room as the DAC, then one should consider a configuration (such as espoused by John Swenson well over a year ago) in which the music server serves files via Ethernet to mini-linux box (i.e., a very small footprint computer) which in turn streams music data (asynchronously) to the DAC - IOW, 3 boxes.

 

IMHO, and as stated above, putting an Ethernet Input on a DAC actually cause as many (and perhaps more) problems as it solves. ;0

 

For the one-box proponents, one is perhaps better served with something like the super isolated boxes, e.g., the Matan server.

 

 

 

 

...and JR, hope all is well. You seem busy with Sonore! I'm busy with other interests these days.

 

cheers,

clay

 

 

 

 

[ziggyzack]

Ethernet DACs have the potential to equal Firewire/Async USB I suppose, but with the current implementations one is left with only a handful of brands to consider, none of which are interesting to me personally (iow, I would not likely ever buy their products).

 

Heart ruling head, Clay?

 

Interesting notion of the computer continuum though. Who knows where it ends, but you seem to have it going via a PC, and starting just at the point of something which can run an ethernet port. But running a firewire port, or an spdif receiver... that's not a computer. Running ethernet is a computer, running firewire isn't. Gotcha.

Better just to minimize the computing power on the computer and use Firewire (or Async USB) to drive the DAC, IMO, as it provides the same benefit. NOTE: this IS the topic of the OP!!!

I mean, how wrong can you be? You can get things wrong, no worries there, but underscore them with three exclamation marks and there's a risk it may mislead people. It is utter, utter tosh to suggest that ethernet is somehow needy of more grunt that the others. In fact, check your cpu usage when you use your USB interface, vs fw or ethernet - USB is notorious for leaning rather heavily on the cpu.

 

As for the three box thing - well I'm proposing two boxes, using good case design to protect the analogue signal path in the second box, so not too far off how it should be done then. But I really don't see what you'd achieve, splitting the second box the way you suggest.

the music server serves files via Ethernet to mini-linux box (i.e., a very small footprint computer) which in turn streams music data (asynchronously) to the DAC

That would necessitate extra digital electronics in the third box to clock the signal to the dac, doing a very similar thing to the electronics in the second box.

 

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

 

ZZ

 

[matan]

Hi Clay et al,

 

 

Clay wrote: "For the one-box proponents, one is perhaps better served with something like the super isolated boxes, e.g., the Matan server."

 

 

I totally second John Swenson's philosophy and arguments in favor of the three box design. In fact, my server is indeed a three box gig: one box for the media/gui/processing, one for the DAC and one super lightweight, realtime, no moving parts, etc box that streams the Ethernet data to the DAC at maximum quality and while being locked to the DAC's clock. I truly believe, based on a long series of experiments, that this is the optimal path to the best sound quality. The topology that I've chosen galvanically isolates the DAC/streamer from the storage/processing components (via a non-Toslink optical connection), and attempts to maximally isolate everything mechanically, electrically, and thermally.

 

The one box system that Magico showed at CES was not the top-of-the-line version of the technology I've been working on, but rather a prototype that was meant to accommodate the Mykernios card running on Windows. The "proper" version of my server (as shown during the CA Symposium exactly a year ago) is the three box design and running Linux.

 

Eloise, I totally agree with you that having the CPU circuitry to decode the Ethernet stack in close proximity to the DAC chips can be rather undesirable as far as audio quality is concerned.

 

I also want to stress that not all "bit perfect" output is created equal - even if the DAC turns on the HDCD LED, it doesn't mean that no additional noise has entered the circuit via the digital audio interface, or that the PLL circuitry inside the DAC didn't miss a sample. Looking at the HDCD spec, one can see that it is quite tolerant of signal corruption, and even leaves the HDCD light on for at least 1/10th of a second (almost 4,500 samples at Redbook!) after losing the HDCD bitsteam in the input signal.

 

As mentioned during the CA Symposium, bit perfect is a stepping stone rather than the goal towards achieving audio nirvana. We should certainly appreciate its necessity, but shouldn't rest on our laurels once we achieve it. There is still a ways to go.

 

Matan

 

 

 

[ldolse]

People are sort of skating around the obvious, but an Ethernet DAC would require several things AES, SPDIF, Firewire, and USB will never require:

 

- A TCP Stack

- An 'operating system' to participate on the network

- 'Applications' running on that operating system

 

Those three things work together to create a raw PCM data stream which is then passed to a DAC chip somewhere inside this 'Ethernet DAC' we're discussing.

 

That's a world of difference from the traditional interfaces above which deliver a raw stream of PCM data and clock information - the DAC just needs to decode that from digital and convert it to analog.

 

One comment back a bit more on-topic. If you check the cics cmp/cplay thread on audioasylum you'll find a wealth of data regarding underclocking, lowering power, etc.. The thread is a bit overwhelming, but there is some good stuff hidden in there.

 

[matan]

 

ldolse wrote:

[...] an Ethernet DAC would require several things AES, SPDIF, Firewire, and USB will never require:

- A TCP Stack

- An 'operating system' to participate on the network

- 'Applications' running on that operating system

 

 

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

 

I do not believe that any one interface is always inherently better than the others (and have I've spent a lot of resources testing many different interfaces / implementations / topologies in my manic quest for 'the best'). Each has its advantages and disadvantages, and is more or less suitable for specific design requirements, but at the end of the day a well-engineered system using an 'inferior' interface will sound better than a poorly-engineered one that boasts a 'superior' one.

 

Quoth the old analog engineering adage: "Everything matters" and so it is such in the digital domain. Our only hope is to corrupt the signal as minimally as possible.

 

Matan

 

[ldolse]

I think my post was really meant as a response to the one before Matan's. If I understand correctly the Matan server is using Ethernet as a transport at some points, but not using TCP/IP. I think using Ethernet as a transport layer is perfectly reasonable, and I really couldn't comment on the pros and cons of Ethernet as a Transport vs. traditional interfaces.

 

I think that for most of this thread people are using the term 'Ethernet DAC', but 'TCP/IP DAC' would be more appropriate. Anything that participates on an IP network is basically a computer is the point I was trying to make. A true Ethernet DAC would use ethernet at the transport layer and something else further up the OSI Stack.

 

[cfmsp]

The opening poster says:

"...but now I'm wondering if decreasing the amount of power a computer uses could be more important. Has anyone experimented with an ultra-low power music server?"

 

Clay posts (in response to ZZ's off topic post about Ethernet DACs):

"Better just to minimize the computing power on the computer and use Firewire (or Async USB) to drive the DAC, IMO, as it provides the same benefit [as the proposed Ethernet solution]. NOTE: this IS the topic of the OP!!!"

 

ZZ posts:

"I mean, how wrong can you be? You can get things wrong, no worries there, but underscore them with three exclamation marks and there's a risk it may mislead people."

 

Actually, a better question is - how wrong can YOU be?

 

First you claim that my comment "better just to minimize the computing power on the computer and..." is NOT on topic re: the OP.

 

Secondly, your comments about Firewire throughout this thread are laughable.

 

thanks for the laugh,

clay

 

 

 

PS, proof is in the pudding. As I said earlier, wake me when an "ethernet DAC" improves upon the sound (for equivalent price) of the ULN-8/LIO-8 boxes, the top Weiss DACs (such as 202), or the Berkeley DAC (or even Mani's Model Two).

 

 

 

 

 

 

 

 

[cfmsp]

 

Matan,

 

Good to read your posts here, and glad I didn't butcher the basic premise of your music server.

 

I knew you had isolation between components - didn't know it was actually a 3 piece setup a la John Swenson.

 

One could learn a lot by reading comments about your experiences. I hope you'll post more here.

 

cheers,

clay

 

 

 

 

 

[ziggyzack]

Hi Idolse,

 

I of course don't know how Matan has implemented the interface in his system, but I'd be surprised if it's not using TCP/IP. One of the main benefits of ethernet is easy access to protocols like TCP/IP. TCP/IP is a robust way of getting data from the server to 'close to' the dac, and is ideal for this part of the task. You need a system which guarantees delivery of the data, can handle data loss, corruption, duplication, and all the very real world issues that occur during signal transmission. TCP/IP was designed for this task decades ago.

 

What you express afterwards is a very common misconception - that something is or is not a computer, and that computers are not hifi. I tend to agree with the latter, but it depends on how you define a computer. I wouldn't necessarily draw the line at something which can communicate over IP. I guess the real question is, does a thing have power requirements and EMI emissions which would disturb the more sensitive parts of a dac, and how can that be addressed? You could use hard-core case design to provide isolation, or put it in a separate box, but then there needs to be a relatively long synchronous signal carrier out of the ethernet+decoder box and into the dac box, and you cannot avoid having a converter at the input of the dac box. I'm absolutely not saying it's the wrong thing to do, but that there are engineering decisions to be made either way.

 

I wouldn't have a hard drive near a dac, but there is not a significant step between driving a firewire interface (which has its own software specification) and an ethernet interface and software stack. Also the decoding of flac/wav to pcm is relatively trivial. Consider tiny portable mp3 players, which do this with very low power draw and in a tiny amount of space. It's also a misconception to think that the data that comes over firewire or usb is in a form which can go directly into a dac - this has still been encoded for transfer over the connection medium, and needs decoding on the other side. I appreciate the purist mentality, but using TCP/IP, flac, and so on is no less pure than alternative computer interfaces. I would say turntables are purer, on that reckoning, but that's not really the name of this game.

 

[ziggyzack]

1) We're having a good technical discussion here, but you seem to think we should stop, because you can just tell us which dac you like best.

 

2) I quoted you in full so that readers could get the context. You didn't do the same, which is a classic symptom of someone who is struggling to make a point. I'll quote it in full below for you - as you can see, I am not saying you were off topic, but that you were talking nonsense. Which you've now done twice.

 

I mean, how wrong can you be? You can get things wrong, no worries there, but underscore them with three exclamation marks and there's a risk it may mislead people. It is utter, utter tosh to suggest that ethernet is somehow needy of more grunt that the others. In fact, check your cpu usage when you use your USB interface, vs fw or ethernet - USB is notorious for leaning rather heavily on the cpu.

 

As far as firewire is concerned, I'm happy to be educated - you'll find I've made very few unqualified comments about firewire, and said early on that I'm not that familiar with it. If anyone can point me to a good resource which explains the usage of isochronous and asynchronous transfers, both in studio use and in consumer dacs, and perhaps a bit of the history of the interface, I'd appreciate it.

 

ZZ

 

Oh, and Clay, seeing as we're talking, you did butcher your assessment of Matan's server. To suggest that there would be an async link between the last two boxes - and you've now had an opportunity to correct yourself - shows that you really don't understand the topic in any depth.

 

[ldolse]

I'm no expert on Matan's server, maybe he'll comment, but from what I've read it doesn't use TCP/IP for the critical bits:

http://www.computeraudiophile.com/content/Matan-Arazis-music-server

http://db.audioasylum.com/cgi/m.mpl?forum=pcaudio&n=55668&highlight=matanarazi&r=

 

That and the fact that he's talking about Ethernet PHY implementations above - i.e. physical layer ethernet.

 

Note I never said a computer is not hifi - I think a computer is perfectly fine as a hifi source - I just prefer the isolationist route of separating the source from the actual Digital to Analog conversion (along with separating GUIs and HDs from the source). That's not to say you won't get decent audio from systems that do it all in one, and all your points are valid, but I doubt that will ever be the pinnacle. Chris's experience with the Linn box and similar reviews of the Logitech systems and others of their ilk all seem to support this.

 

[manisandher]

"... wake me when an 'ethernet DAC' improves upon the sound (for equivalent price) of the ULN-8/LIO-8 boxes, the top Weiss DACs (such as 202), or the Berkeley DAC (or even Mani's Model Two)."

 

Well, I feel honoured being included in such exhalted company ;-)

 

FWIW, I think PeterSt's 'Phasure NOS1' DAC, might employ some of the techniques that have been discussed here so far. Having heard a prototype over at his place, I really think it will be a game changer.

 

In an attempt to stay OT (I got reprimanded last time I didn't), I'm not hearing much of a difference in sound when I underclock/'undervolt' my CPU. But I think any potential improvements might be clouded with the AES issues I'm currently having.

 

In any event, this thread has evolved into a really interesting discussion. 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...

 

Mani.

 

 

 

[cfmsp]

ZZ,

 

 

"...which is a classic symptom of someone who is struggling to make a point."

 

Actually, ZZ, the classic symptom of someone struggling to make a point is the strawman argument (usu. done intentionally) - or simply totally misunderstanding the points that others are making and then responding to the misrepresentation as if one's own opinion was 'attacked' (the more common, non-self-aware version of a strawman). ;0

 

IOW, you misunderstand or misrepresent what someone else says and then criticze it.

 

You've done that with pretty much every comment I've made here.

 

ZZ, you made an explicit point to criticize my use of three exclamation points. I used these only once - in the comment about being "on topic". Then you went on about something I hadn't said, and therefore I thought it was not germane to your criticism, since I'd not said it. That's why I cut it out. Thanks for clarifying what you were criticizing, i.e. another strawman.

 

"It is utter, utter tosh to suggest that ethernet is somehow needy of more grunt that the others. In fact, check your cpu usage when you use your USB interface, vs fw or ethernet - USB is notorious for leaning rather heavily on the cpu."

 

I never said anything remotely like the words you put in my mouth here. Although several others here HAVE stated your, shall we say, oversimplification of the 'grunt' needed by Ethernet.

 

 

 

Neither have I interrupted a good technical discussion to tell people what DAC to use. The OP did NOT ask about Ethernet solutions - you raised the point, so I shared my opinion of preferred Firewire approach, stating a rather simple, non controversial opinion (IMO) that the OP should concentrate on reducing the power consumed by the comuputer and use either a Firewire or Async USB DAC (as they also use the DACs clock as master, and thereby offer the most significant benefit of an Ethernet solution).

 

 

As for learning about Firewire, there are thousands of posts here. And wikipedia is your friend.

 

 

and finally, again, I'll repeat myself - what DAC with ethernet input are you suggesting is of the caliber of the ones I mentioned earlier? We should include Gordon's Async USB and Charlie's Async USB Dacs in the mix as well.

 

 

 

"..I am not saying you were off topic, but that you were talking nonsense. Which you've now done twice."

 

It's all just opinions here, some ARE just more well baked than others.

 

However, Ad hominem attacks - as you've made and continue to make - have no place here. Clearly, you've taken my sharing of an contrary opinion a bit too personally, despite that I addressed my original comments to Eloise.

 

 

"Oh, and Clay, seeing as we're talking, you did butcher your assessment of Matan's server. To suggest that there would be an async link between the last two boxes - and you've now had an opportunity to correct yourself - shows that you really don't understand the topic in any depth."

 

ZZ, once again, you create a strawman agrument, I was describing the John Swenson approach with the 3 box solution.

 

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.

YMMV, and apparently does, since you used disagreement with this comment as your evidence that I 'don't understand'.

 

BTW... Matan didn't seem to believe that I butchered anything.

 

Interestingly, for someone who really doesn't have any depth in the topic, I seem to have a few people agreeing with me!

 

have a great day *

 

clay

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

[The Computer Audiophile]

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

 

No.

 

[ziggyzack]

Note I never said a computer is not hifi - I think a computer is perfectly fine as a hifi source - I just prefer the isolationist route of separating the source from the actual Digital to Analog conversion (along with separating GUIs and HDs from the source).

 

Absolutely agree with this, we're just using different terms, I think. When I say computers are not hifi, I don't mean that they shouldn't be used at all, but that they should be separated along the lines you describe. See the last paragraph of this post, for example.

 

Matan referred to Ethernet PHY + stack, rather than the physical layer alone, in the comment above. But it sounds like he's done something very custom for his three box implementation (if I've read it right). Hopefully he'll embellish a little, it sounds cool.

 

I was disappointed with Chris' review of the Linn box. It explained UPnP AV pretty well, but didn't 'get' the ethernet connectivity point. The whole raison d'etre of the DS players is the ethernet connection. They have a buffer (a couple of seconds' worth), a dac chip or two, and an accurate clock, all very close to one another. Music data is pulled down via ethernet, at an average rate to keep the buffer topped up. The precision clocking of this music data is completely irrelevant at this stage, as long as it's within the tolerances needed by ethernet, it gets there. It's just data. There are radio stations experimenting with 16/44 wav streams - that could be the source. The Fast Ethernet interface can comfortably transfer data at least 15 times as fast as that needed to play a 24/192 flac in realtime, so there's no strain there on home network. Conversely, once in the buffer (having been converted to PCM), the music is pulled out of the buffer according to a very precise beat. Not only is the beat very precise, it's also exactly the same beat that the dac(s) work to. Compare spdif, where the incoming signal is clocked by a sound card, and the dac has it's own clock - as accurate as they may be, the two clocks must be marginally out of sync. There are strategies to resolve this, but none as good as designing the problem out altogether.

 

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 their CD player from at least the next range up).

 

So, you could call those a two-box system: a bog-standard computer or NAS (box 1), and a DS player (box 2), connected by ethernet, using the UPnP AV protocol, which itself sits on an IP network. I wonder what Matan's does? It sounds like he 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. Then it sounds like he's built a custom server (box 1), connected to the streaming box by fiber, using a custom protocol - so a departure from a bog-standard computer/nas. I can more immediately see the reasons for splitting the Linn box 2, into Matan boxes 2 and 3, than I can for the changing from a bog standard computer and connectivity, to something custom, but I defer to the guy who built it!

 

The question for the OP, then, is 'where's my f***ing thread gone???' Well, hopefully there'll be some insight into a very hardcore-sounding isolation job, and that kind of stuff should trickle down