LAN Input DACs

[tranz]

Is anyone using a solution whereby the music source output ( computer, NAS, renderer, etc.) is going into a DAC via an ethernet connection?

 

Cheers

[4est]

Well, yes- sort of... I am running an SOtM sMS 100 via HQPlayer NAA and a RaspberryPi I2S directly into a DAC, but methinks that is not what you meant. Maybe you could give some more detail as to what you are looking to learn.

[Superdad]

Hi Forrest: I think Tranz is asking about DACs with direct Ethernet connection. And to qualify that even further, ones that don't have a whole computer running an OS (no matter how small) acting as a host. Thus, devices like sMS-100, Aeries, RasberryPi, and CuBox-i are all just scaled down or purpose-built variations of a Mac mini or CAPS--they just run a Linux-variant and sometimes act more as end-point for a stream than being the player itself. Software such as LMS, NAA, Vortex, or any DLNA set up are mostly what enable those "computers" to play via Ethernet. Yet they are not really perfect in that similar problems and issues still exist--sometimes just scaled down. USB, clocking, power supply, processing and ground plane noise, lack of transparency in s/w-- none of those thinks go away completely.

 

So Ethernet input DACs without a computer inside are still a rare beast. Even more so if you want one that does not require DLNA. The Sonore Rendu (and Logitech Squeezebox and the like) as an Ethernet>S/PDIF or >I2S device comes pretty close, as the processor that acts as its "renderer" has embedded code and is not running an OS. But one still has to think about server and controller s/w to feed it (if using DLNA).

 

Of course what a lot of us want is just to be able to use our favorite player s/w--be it A+, JRiver, Amarra, iTunes, HQ Player, XBMC, Foobar, whatever--and to direct its output to a port that looks to the OS exactly like a USB "sound card" so regular Windows or Mac drivers work (ASIO, Wasapi, CoreAudio, integer mode, etc.), but is actually sending it out over Ethernet (through the LAN switch, hi-res, DSD, etc.) to a DAC that just plays it.

 

Sounds good, eh? A pipe dream? No actually. Bur it can not be done entirely in sofware.

John Swenson and I have been working on just such a solution for a very long time. We are trying to move it closer (its been idling on the back burner this year but is moving again), and it is a solution that may take three forms business wise: as a licensed module, as a DIY board set, and as a retail product (but it won't output USB--that requrires it be a host and thus a computer processor involved; and our own crazy DAC ambitions are going to take a LOT of money to capitalize). I can't reveal more of the details at this time, and honestly you may not see anything for at least 6 months more.

Plus I am told that others may be woking along the same lines. So keep your eyes peeled. We are all watching for that unicorn-- the elusive Ethernet DAC!

 

Regards,

Alex C.

[wadeh911]

Is anyone using a solution whereby the music source output ( computer, NAS, renderer, etc.) is going into a DAC via an ethernet connection?

 

Cheers

 

Yes. I output my from my upstairs Win7PC Server running JRiver 19 to my downstairs Oppo BDP-105 via an Ethernet connection for MCH and 2CH DSD and other lossless music formats. The Oppo 105 is also a multichannel DAC.

[wadeh911]

Hi Forrest: I think Tranz is asking about DACs with direct Ethernet connection. And to qualify that even further, ones that don't have a whole computer running an OS (no matter how small) acting as a host. Thus, devices like sMS-100, Aeries, RasberryPi, and CuBox-i are all just scaled down or purpose-built variations of a Mac mini or CAPS--they just run a Linux-variant and sometimes act more as end-point for a stream than being the player itself. Software such as LMS, NAA, Vortex, or any DLNA set up are mostly what enable those "computers" to play via Ethernet. Yet they are not really perfect in that similar problems and issues still exist--sometimes just scaled down. USB, clocking, power supply, processing and ground plane noise, lack of transparency in s/w-- none of those thinks go away completely.

 

So Ethernet input DACs without a computer inside are still a rare beast. Even more so if you want one that does not require DLNA. The Sonore Rendu (and Logitech Squeezebox and the like) as an Ethernet>S/PDIF or >I2S device comes pretty close, as the processor that acts as its "renderer" has embedded code and is not running an OS. But one still has to think about server and controller s/w to feed it (if using DLNA).

 

Of course what a lot of us want is just to be able to use our favorite player s/w--be it A+, JRiver, Amarra, iTunes, HQ Player, XBMC, Foobar, whatever--and to direct its output to a port that looks to the OS exactly like a USB "sound card" so regular Windows or Mac drivers work (ASIO, Wasapi, CoreAudio, integer mode, etc.), but is actually sending it out over Ethernet (through the LAN switch, hi-res, DSD, etc.) to a DAC that just plays it.

 

Sounds good, eh? A pipe dream? No actually. Bur it can not be done entirely in sofware.

John Swenson and I have been working on just such a solution for a very long time. We are trying to move it closer (its been idling on the back burner this year but is moving again), and it is a solution that may take three forms business wise: as a licensed module, as a DIY board set, and as a retail product (but it won't output USB--that requrires it be a host and thus a computer processor involved; and our own crazy DAC ambitions are going to take a LOT of money to capitalize). I can't reveal more of the details at this time, and honestly you may not see anything for at least 6 months more.

Plus I am told that others may be woking along the same lines. So keep your eyes peeled. We are all watching for that unicorn-- the elusive Ethernet DAC!

 

Regards,

Alex C.

 

That concept is absolutely what I am looking for. Have you considered kickstarter or something similar to get he needed funding? Right now I am considering the exaSound e28 to handle my MCH music files from my JRiver and JRemote. But the e28 currently does not provide an Ethernet LAN capability for this.

[jabbr]

Hi Forrest: I think Tranz is asking about DACs with direct Ethernet connection. And to qualify that even further, ones that don't have a whole computer running an OS (no matter how small) acting as a host. Thus, devices like sMS-100, Aeries, RasberryPi, and CuBox-i are all just scaled down or purpose-built variations of a Mac mini or CAPS--they just run a Linux-variant and sometimes act more as end-point for a stream than being the player itself. ...

So Ethernet input DACs without a computer inside are still a rare beast. Even more so if you want one that does not require DLNA. ....

Sounds good, eh? A pipe dream? No actually.

 

You'd be better off putting something really good in your pipe, sitting back and listening to hi-res Pink Floyd.

 

:-)

 

Seriously, all modern digital design these days uses some type of internal processor (somethings got to interpret the firmware) ... so exactly how is this better than designing a "better" Cubox or mac mini type box that you'd actually be able to run whatever your preferred software is ... or becomes?

[boatheelmusic]

PS Audio PWD or DS with Bridge.

[Elberoth]

Linn, naim, lumin etc.

[CatManDo]

I think it all depends on how people define a "DAC". Every computer with a sound card is also a DAC.

[Superdad]

PS Audio PWD or DS with Bridge.

 

Expensive. Works only with their DACs. Clocks in the wrong place (should us DAC's clocks as master). Requires messing about with UPnP/DLNA, so certain audio player software gets ruled out. All the usual limitations of a DLNA "renderer.". Quite fine for some, but not what I am chasing.

[Superdad]

Linn, naim, lumin etc.

Yep, nice also. But again, a bit closed on software that can be used--iTunes, Audirvana, HQ Player all ruled out. I'm just not a UPnP/ DLNA fan.

We think people would enjoy a DAC (or device for a DAC) that lets you use ANY favorite player s/w, outputting to a USB port seen as a super-standard UAC2 sound card, but have the data then go out onto the LAN and find a waiting DAC or device. And that device will not have to have a big microprocessor or any reliance on the server/controller/renderer model and its layers.

[Superdad]

 

 

Seriously, all modern digital design these days uses some type of internal processor (somethings got to interpret the firmware) ... so exactly how is this better than designing a "better" Cubox or mac mini type box that you'd actually be able to run whatever your preferred software is ... or becomes?

 

Because I think the split model--computer sending stream over galvanicly isolated Ethernet to a DAC where it is received without further processing or conversion back to a problematic USB output/input--sounds better. (I'm not going into details of actual circuit implementation here, but we are talking something done right with extremly low jitter and timing based on the DAC's master clocks as it should be.)

And it vastly reduces the sonic impact of much that goes on in the sending computer.

 

We think a lot of people don't want to have a computer with their music library right in the room/on the shelf with their audio gear. Keep and manage/rip/download your music on the big family computer in the den, use your favorite player s/w and remote control for it (even if that is just Apple Remote app on iPad/iPhone, or a screen sharing VNC app), and sit in front of your speakers with complete wireless playback control.

 

I respect Linn, Naim, Lumin, Auralic, SOtM, Sonos, Squeezbox, etc. for what they have done. But we think a more open, simple, compatible, and sonicly transparent solution is possible. Equal to or better sounding than the best direct computer>USB DAC implementations. A tall order we know. We'll just have to wait and see how it turns out.

[jabbr]

Perhaps a raspberry-pi-ish board that pretends to be both an airplay device and UPnP receiver but has a nice DAC with direct attached via I2S?

 

Not sure how this would work with Audirvana unless you write an OS X device driver that streams... for example how logmein sends sound to the remote viewer.

[tranz]

Thank you for all the suggestions so far.

 

The one thing I am hoping is that with a LAN input we would not have to go nuts with all the electrical noise filtering that is required with USB due to no ground and inbuilt transformers in ethernet connections. Also no power running next to signal issues like the USB either.

 

Now perhaps a completely different for-audio-designed connection is needed, but good luck getting acceptance there, if it would even technically/electrically provide a benefit over LAN.

 

Now USB cards like SoTM also clean up noise on the PCIe pins and signal (d+/d-) lines, so would the inbuilt LAN transformers in e.g. hospital/audio isolation units (EMO, Acoustic Revive, Giso) be enough to clean electrical noise on the LAN signal lines?

 

Many of the currently available units with LAN inputs seem to be self-contained units with DAC and pre-amps as well. Lumin and Devialet for example. Very nice as well.

 

Not opposed to streamers with LAN outputs either as you would feed the file to the DAC (or DAC buffer), and use its filters. 'All' that is needed then is a super low electrical noise file server. An audiophile NAS, as opposed to all the work required with OS optimization (Win server/AO, CAD scripts, etc.) and playback software (Amarra, A+, JRiver, etc.), which granted have their own filter set and sound that people prefer.

 

Or we just use our CAPS and MacCAPS running DLNA servers with ethernet outputs.

 

But DAC manufacturers would also have to agree to provide LAN inputs and/or at least confirm that there are better ways to implement a better sounding (low jitter and low electrical noise) connection.

 

Cheers

[jabbr]

...

'All' that is needed then is a super low electrical noise file server. An audiophile NAS, as opposed to all the work required with OS optimization (Win server/AO, CAD scripts, etc.) and playback software (Amarra, A+, JRiver, etc.), which granted have their own filter set and sound that people prefer.

 

That won't in and of itself solve the problem. Consider the NAS as as nothing more than a remote disc. It remains the function of the ethernet card with its driver to load remote data into the client's RAM afterwhich its sent to the DAC. It remains the client's responsibility to properly buffer, clock and output the data.

 

Just because there are 'faulty' clients doesn't alter that. In the same fashion a well designed USB DAC reclocks its input. (i.e. async)

[tranz]

That won't in and of itself solve the problem. Consider the NAS as as nothing more than a remote disc. It remains the function of the ethernet card with its driver to load remote data into the client's RAM afterwhich its sent to the DAC. It remains the client's responsibility to properly buffer, clock and output the data.

 

Just because there are 'faulty' clients doesn't alter that. In the same fashion a well designed USB DAC reclocks its input. (i.e. async)

 

Good point.

 

The LAN input will need to also be used to slave the source to the DAC's clock. Remember USB before asynch....bloody hell did that sound bad. Naturally we need to maintain the DAC-as-clock-source methodology.

 

There are threads discussing the audio benefits of certain NIC cards over the one embedded on the motherboard, so the implementation of this LAN path from source to destination is crucial. If DAC manufacturers just view it as a marketing element as opposed to properly engineering it than we are no better off.

 

The key benefits I would like to hear:

 

1. Lowest electrical noise possible on any point with the connection to the DAC. Source, cabling and destination.

2. Skip the SPDIF translation step to lower jitter

3. Ability to playback all file formats and streams (From DSD,DXD,PCM to internet radio) gapless

4. DAC as clock source

 

Cheers

[Miska]

Software such as LMS, NAA, Vortex, or any DLNA set up are mostly what enable those "computers" to play via Ethernet.

 

You shouldn't put LMS or UPnP/DLNA in the same sentence with NAA, because those are vastly different... NAA is closer to AirPlay than LMS or UPnP/AV.

 

So Ethernet input DACs without a computer inside are still a rare beast. Even more so if you want one that does not require DLNA. The Sonore Rendu (and Logitech Squeezebox and the like) as an Ethernet>S/PDIF or >I2S device comes pretty close, as the processor that acts as its "renderer" has embedded code and is not running an OS. But one still has to think about server and controller s/w to feed it (if using DLNA).

 

UPnP is horribly complex and bad design and DLNA spec on top of it makes it even worse. So that's ruled out. Anything that is based on IP protocol on top of ethernet requires a computer, one form or another. Doing anything above IP protocol without proper OS is extremely bad idea, because you'll spend a decade trying just to perfect IP stack implementation while you end up building OS of your own while doing so which would end up being much worse implementation than anything already existing (unless you have thousands on man years to spend)...

 

We are all watching for that unicorn-- the elusive Ethernet DAC!

 

In addition to NAA and building a NAA inside a DAC you have bunch of pro-audio gear (with ADC too) already on this area. So nothing new, but depends on what you want.

[Superdad]

Miska,

What we are working on is much simpler and elegant. No DLNA, no computer processor or OS at the DAC end, automatic pairing over the LAN (not even requiring DHCP IP assignment--somthing I wish you would eliminate in your NAA).

It just works and is completely compatibile with ANY computer application (not just music players) that output sound to a USB port as supported by the operating system's normal audio drivers (ASIO, WASAPI, ALSA, CoreAudio, whatever).

I really can't say more. But some well-known firms have already come to us to ask about licensing, so we are trying to move this along faster.

--Alex

[Superdad]

P.S. I did not intend to malign HQ Player's NAA component by mentioning it in the same breath as DLNA. I was just speaking about existing solutions that run under an OS on a general purpose processor (yes there are exceptions). Actually, I'd like to see Miska have more embedded NAA licensees with products in the market. It would still be a somewhat closed system, in that it requires use of HQ Player, but I love his Polysinc filters so that would not bother me.

[Miska]

What we are working on is much simpler and elegant. No DLNA, no computer processor or OS at the DAC end, automatic pairing over the LAN (not even requiring DHCP IP assignment--somthing I wish you would eliminate in your NAA).

It just works and is completely compatibile with ANY computer application (not just music players) that output sound to a USB port as supported by the operating system's normal audio drivers (ASIO, WASAPI, ALSA, CoreAudio, whatever).

 

Sounds like a USB port reflector... But you may want to avoid any of the USB packet stuff because it's unnecessary extra (packets on packets).

 

When streaming is done properly, ethernet adapters on computers (especially the server models) have much more powerful hardware offloading capabilities than any USB interface I'm aware of.

[tranz]

 

UPnP is horribly complex and bad design and DLNA spec on top of it makes it even worse. So that's ruled out....

 

In addition to NAA and building a NAA inside a DAC you have bunch of pro-audio gear (with ADC too) already on this area. So nothing new, but depends on what you want.

 

Hi Miska,

 

Always enjoy reading your input. Do you have examples of the pro-audio gear?

 

Do you have a little more background on the DLNA issues, and why that would be bad for the 'perfect' audio path?

 

Cheers

[Miska]

Always enjoy reading your input. Do you have examples of the pro-audio gear?

 

For example:

Merging Horus

Focusrite RedNet

Both work with ASIO capable applications.

 

Do you have a little more background on the DLNA issues, and why that would be bad for the 'perfect' audio path?

 

UPnP is based on complex three-party handshake based on mDNS, HTTP and XML. In UPnP, Renderer is the instance that actually performs audio reproduction is also the actual player. So it doesn't provide means for isolating audio recording/reproduction from the player functionality. Also the media streaming is based on HTTP which is really inefficient for the purpose. UPnP Media Server is pretty much just a web server with optionally media transcoding capabilities and the Renderer is player that makes requests to that web server. Control Point tells the Renderer what it should fetch from the Media Server.

 

Control Point doesn't really have any control over "how" the actual playback is performed, only "what".

 

When you want to play FLAC from MinimServer, Renderer is the one that performs all decoding and playback, MinimServer just provides the FLAC file as-is over HTTP when asked by the Renderer. If Renderer doesn't know how to play FLAC, playback fails. With more advanced Media Server, it could figure out it needs to convert 192/24 FLAC to something supported by Renderer for playback, but it's all up to black magic between the two what that intermediate format would happen to be. It could be for example MP3...

 

Because UPnP/AV spec doesn't define any media formats, Media Server and Renderer could have nothing in common. For that reason, there's DLNA that defines restricted small subset of formats that are "mandatory" or "optional". DLNA part doesn't cover such things as DSD at all, so a DSD and DLNA are completely unrelated. So a strictly DLNA compliant system could transfer your DSD files as MP3 or 44.1/16 WAV (mandatory) between the systems, and you wouldn't even know... (other than wonder why it sounds bad)

 

Renderer doesn't really support multiple alternative outputs per renderer either.

 

 

For example NAA makes remote audio devices appear just as if they were locally connected, player behaves the same as if the playback would happen locally. So it's more like the Merging/Focusrite devices above.

[Superdad]

Sounds like a USB port reflector... But you may want to avoid any of the USB packet stuff because it's unnecessary extra (packets on packets).

 

Sorry, that's not what we are doing at ALL.

 

For example NAA makes remote audio devices appear just as if they were locally connected, player behaves the same as if the playback would happen locally. So it's more like the Merging/Focusrite devices above.

 

That's actually a little closer to what we are doing.

 

 

When you want to play FLAC from MinimServer, Renderer is the one that performs all decoding and playback, MinimServer just provides the FLAC file as-is over HTTP when asked by the Renderer. If Renderer doesn't know how to play FLAC, playback fails. With more advanced Media Server, it could figure out it needs to convert 192/24 FLAC to something supported by Renderer for playback, but it's all up to black magic between the two what that intermediate format would happen to be.

 

Yes, aside from all the other software weaknesses of the joke called DLNA (the main of which you enumerated), the other big limitation is just as you say:

The renderer (stream and format decoder) duties all have to be in the DAC--requiring it to incorporate much more processing. Let's keep the bulk of the processing (and attendant software writing/support) out of the DAC! Too many variables of SQ and compatibility happen with the "renderer" model.

For all their electrical flaws, at least USB and S/PDIF do not burden the DAC designer with layers and protocols of computer h/w and s/w development, and they allow them to focus on the DAC and its isolation, clocking, PS, filtering, output, etc.

 

We are just trying to bridge the divide between USB and Ethernet and to produce an output format equal to or better that I2S to feed the DAC. That's about a plain a hint that I will give at the moment.

 

It is funny though Miska, you could easily beat us to the punch in a different way with your all s/w approach. If you were to somehow make your HQP>NAA code into a licensable "transport" module that other players could plug into, directing their player output to it instead of the USB port, and then have your Linux/NAA image on a compatible NAA device connected to the LAN and DAC (a CuBox-i or better)--people would then be able to use a wider array of s/w players. Yes, it might take sales away from HQ Player, but you would essentially creating your own AirPlay standard--without the resolution or licensing limitations.

Just a thought from a hardware guy…

 

Best,

 

ALEX

[Audio_ELF]

Resolution Audio did something similar I think. And Devialet's Air implementation as well I think?

[Superdad]

Resolution Audio did something similar I think. And Devialet's Air implementation as well I think?

 

Eloise, thanks for pointing those out.

 

Yes, Jeff Kalt's Pont Neuf is about the closest in concept to what we are doing. Our solution is both a more modern implementation, and more open. The point being to license it for other DAC makers to use, as well as having DIY and retail box versions. Plus it works with ALL s/w, supports very high rates, and does not require any DHCP LAN router to give an IP address for pairing. That and the hardware interface from our DAC-side module to DAC main board will use techniques and format never used by anyone else for audio. John is trying to make this surpass other USB input options and even I2S.

 

I am not familiar at all with how Devialet's Air solution works. From what I read it functions wonderfully, but I guess just on their own drool-worthy gear. I can't tell anything about how their s/w implementation works.