LAN Input DACs

[bmoura]

which of your products supports multichannel files

 

The best hope in that area may be exaSound - they made the first home Multichannel DSD DAC and certainly could add a bridge to that offering down the road.

[wadeh911]

The best hope in that area may be exaSound - they made the first home Multichannel DSD DAC and certainly could add a bridge to that offering down the road.

 

exactly what I am hoping. If I am going to upgrade to another LAN MCH DAC from my Oppo 105, the e28 with an LAN bridge would be my upgrade. Time will tell if they offer a bridge. From reading everything I can find, almost every forward thinking DAC manufacturer sees this as a great sales opportunity. Of course the 2CH DAC manufacturers see their market differently. Low jitter Buggy whips are still sold at a premium today.

[sandab]

Take a small controller board, like an Olimex LPC one with ethernet (I like the LPC2400 series) and host USB ports, then create custom firmware to run it as a USB-over-TCP tunnel endpoint. At the other end create a tunnel USB host controller (driver) that can discover network-tunneled USB devices. (Zeroconf is excellent for this.) Then just use the regular old OS async USB audio drivers with the tunnel. Stick the board inside something like a Gustard U12, add a separate attenuated 12V DC power supply. Hook it up to whatever quality DAC you wish. Looks like there's a similar project already - USB/IP Project, so there's at least Linux/OSX code to start with, but the uC end needs a bit of effort (but could be prototyped with a Beagleboard or something running Linux for simplicity).

[tranz]

Just spotted this:

 

http://www.msbtech.com/products/serverComp.php?Page=analogDac

 

It sounds like a potential way to bypass USB (and SPDIF?) once and for all. No more dicking around with OS, iTunes, NightMarra, and perhaps even computer tweaking, etc. Almost sounds too good to be true.

 

Looks intriguing! Has anyone heard one either through a tweaked computer or direct through a NAS?

 

Cheers

[davide256]

reading the article a bit more closely, MSB is jumping on the UPNP bandwagon by offering a renderer module that integrates with their DAC... competing with things like Auralic Aries + DAC, Naim NDX. The remote control app isn't mentioned, it can make or break how useable a renderer is.

[Superdad]

It sounds like a potential way to bypass USB (and SPDIF?) once and for all. No more dicking around with OS, iTunes, NightMarra, and perhaps even computer tweaking, etc. Almost sounds too good to be true.

 

Have been friends with the MSB folks for years and they are terrific people. Dustin is a very talented engineer.

But Dave is right, it is just a DLNA renderer option for their DAC. $2K to add DLNA to a $7K DAC--ouch. There are cheaper ways to get into DLNA, but yes, it gets integrated with their DAC so you skip USB and S/PDIF. However, as with all DLNA solutions, you are shut out of using certain players such as Audirvana, HQPlayer, XXHigh-End, and iTunes.

[Cebolla]

However, as with all DLNA solutions, you are shut out of using certain players such as Audirvana, HQPlayer, XXHigh-End, and iTunes.

Only in that the UPnP/DLNA device won't be able to use their music libararies to access the music files, if they have one and the music playing software can't provide them because they don't support UPnP/DLNA. Certainly it doesn't matter about the music player software's actual music file playing functionality, because that's built into the UPnP renderer and no reason why it can't be designed to be every bit as good.

[Superdad]

Certainly it doesn't matter about the music player software's actual music file playing functionality, because that's built into the UPnP renderer and no reason why it can't be designed to be every bit as good.

 

My best laugh of the day so far. You ought to look closer at what it takes to implement a DLNA renderer. The processor and processing it goes through is immense. And from the s/w side, the architecture sucks as well (for just one developer's screed see: Why do I hate DLNA protocol so much ? | Ben's Lost World - Diary of a GeeXboX developer). Sorry, but to me, DLNA and purist audio are like oil and water.

[Cebolla]

I have and by the looks of it nothing much. I don't see 'tinkerers' software like the excellent Foobar2000 music player application struggle with the UPnP extensions available for it nor even JRiver, on pretty low spec'd computers. I certainly don't see any issues with it on dedicated purpose built bits of kit. Problems with UPnP/DLNA, like the ones you've linked to, are down to the implementation. No one's suggesting you embrace all UPnP/DLNA devices and just like music player software there are good as well as bad examples.

 

Does that mean that you don't believe UPnP devices like the any of the ones mentioned in the above posts, can be considered purist audio ones?

[Superdad]

Does that mean that you don't believe UPnP devices like the any of the ones mentioned in the above posts, can be considered purist audio ones?

 

No, I did not mean that. But I also don't want people to think that the Ethernet input/renderer hardware to offer UPnP/DLNA is a walk in the park or all the same. There is just as much affecting the SQ of such inputs as there was/is with USB. And remember all the crappy USB inputs that were/are added to DACs or players in the rush to include USB?

By no means am I saying that MSB's Ethernet/DLNA input module is crap, but I am certain if you asked Dustin what it took to do it right he would tell you a long and tortured story.

There are a VERY few properly done Ethernet/DLNA audio input modules available for OEMs to use in their products. Here is one example: Network Audio Renderer | ABC PCB 100 piece OEM wholesale price for it was almost $400 in 2012.

 

As for the s/w side of things: Yes, some of the player people seem to manage, but ask them if they like the architecture. DLNA is by no means an elegant or universally compatible solution.

[Audio_ELF]

Alex (Superdad) I think you need to be very careful as there are some excellent UPnP implemented devices which are "purist audio".

 

I'm not suggesting they are easy to implement; but surely no harder than than building a USB interface from scratch.

 

Eloise

[Miska]

I'm not suggesting they are easy to implement; but surely no harder than than building a USB interface from scratch.

 

Not commenting so much about difficulty, but the two are at completely different protocol level. USB audio interface is much much lower level interface than UPnP/AV.

 

For UAC you have three layers:

1) USB PHY

2) USB packet level (URB)

3) UAC packet protocol

 

For UPnP AV you have six:

1) Ethernet PHY

2) IP

3) TCP/UDP

4) mDNS/HTTP

5) XML

6) UPnP

 

What you have after each of these steps is also different. In UAC case you would have samples that suit as-is your DAC. In case of UPnP you could have blocks of MP3 or FLAC data that you still need to decode and play... I don't know any case where you would send MP3 or FLAC packets for DAC to be decoded over USB...

 

Usually in neither case the "one implementation" is entire stack. For UAC implementations usually (3) and for UPnP/AV implementations (6)... Rest of the stack is coming from elsewhere.

[Cebolla]

My ancient and very rarely used electronics knowledge is telling me that Alex's concern was more about the difficulty in designing hardware that deals any noise isolation vs supressing EMI and similar issues affecting sound quality that may come from using the high frequency components contained in the network input (and music player presumably) in proximity to the DAC section, especially if the design dictates (for good SQ) that all should be on the same board.

[Superdad]

Well my concern is that some people seem to think that an Ethernet input using DLNA is not much more complicated than a USB input, when in fact it is. A DLNA renderer is a whole s/w and h/w processor system. As such, it requires careful design and ongiong support. The file decoding occurs at the renderer. If people want to believe that such devices are a walk in the park and will all sound good and the same, then that is their choice. But belief does not make it so.

[jabbr]

Well my concern is that some people seem to think that an Ethernet input using DLNA is not much more complicated than a USB input, when in fact it is. A DLNA renderer is a whole s/w and h/w processor system. As such, it requires careful design and ongiong support. The file decoding occurs at the renderer. If people want to believe that such devices are a walk in the park and will all sound good and the same, then that is their choice. But belief does not make it so.

 

+2

 

I like to encourage people to consider Ethernet as more akin to a remote memory access protocol than a serial communications protocol. In the same way a filesystem's job it to load (parts of) a file into RAM whether that file be connected by SATA, SAS or Ethernet. Just because you *can* access files via USB doesn't mean its a good thing to do and likewise just because you might wrap the I2S protocol in Ethernet doesn't mean that its a good thing to do either ... Ethernet hardware companies are already incorporating rDMA onto the PCI-e cards/hardware/drivers. Don't expect Intel to incorporate an I2S driver onto its ethernet cards/chips etc. within the lifespan of this universe. Ethernet is not fundamentally a synchronous streaming protocol, rather packet driven.

[jabbr]

Alex (Superdad) I think you need to be very careful as there are some excellent UPnP implemented devices which are "purist audio".

 

I'm not suggesting they are easy to implement; but surely no harder than than building a USB interface from scratch.

 

Eloise

 

Depends on what you mean by "from scratch" ... when you build a uPNP device from scratch you really mean that you go out and buy a cheap computer (arduino, raspberry-pi, volumio etc) which comes with a built in software (e.g. a linux os ) and perhaps I2S output. Buying a DAC which comes with an async USB driver is easier and in both cases *someone else* has done the work for you.

 

uPNP/DLNA is just another protocol layered *on top of* Ethernet. I just use SMB myself.

[davide256]

+1 to SMB. better sound than UPNP

[Mike Mcsweeney]

Yes, it is pure hardware solution (but no extra computer processor or OS involved). Your computer sends audio from ANY application, player, radio, etc. just as if the DAC was directly attached.

 

I have been going crazy looking for something like this.

Any player will work?

 

I would think it would be a driver requirement?

 

I just want a nice little box that will allow you to play whatever is playing on your pc to an avr over ethernet. Why can't just a windows driver allow you to output over ethernet the binary stream to an AVR's network jack and let the avr decode it. Many cheap avr's can handle dsd over ethernet now....the problem is how to get the binary bits to the avr without DLNA. DLNA SUCKS, and although it is a standard...it is not standardized (grin).

[Audio_ELF]

Well my concern is that some people seem to think that an Ethernet input using DLNA is not much more complicated than a USB input, when in fact it is.

Alex... My concern is that as a respected member which people pay attention to you make such sweeping statement (but to me, DLNA and purist audio are like oil and water) which wipe away Auralic, Linn, Naim and many others. People pay attention to what you say and you may have no intention as a commercial entity of producing a streamer but many "purist audio" streamers do exist.

 

While at a theoretical level a streamer may be more complicated: does that necessarily mean they are more complicated to build / design; and even if they are more complicated if the end result for the consumer is a better sounding device then sorry but that's all the better.

 

Eloise

[tranz]

Alex... My concern is that as a respected member which people pay attention to you make such sweeping statement (but to me, DLNA and purist audio are like oil and water) which wipe away Auralic, Linn, Naim and many others. People pay attention to what you say and you may have no intention as a commercial entity of producing a streamer but many "purist audio" streamers do exist.

 

While at a theoretical level a streamer may be more complicated: does that necessarily mean they are more complicated to build / design; and even if they are more complicated if the end result for the consumer is a better sounding device then sorry but that's all the better.

 

Eloise

 

And in addition, if this allows a user to bypass noise from USB, avoid jitter from SPDIF conversion and use the accurate (femto in MSB's case) clock as a master, plus the ease of use of DLNA, what is not to like.

 

Yes, it will just play back a file (most any file) without being able to do room correction or Miska's upsampling algorithms, or the various playback software programs. But that for many, including me, is more of an additional benefit. Least hassle for optimal sound.

[Superdad]

...but many "purist audio" streamers do exist.

 

While at a theoretical level a streamer may be more complicated: does that necessarily mean they are more complicated to build / design; and even if they are more complicated if the end result for the consumer is a better sounding device then sorry but that's all the better.

 

Eloise

 

You are right Eloise. And I don't intend to disparage anyone or any company. Indeed Linn, Naim, and many smaller firms have worked hard to provide convenient Ethernet-based audio solutions, and that is great. And I am glad if they have many satisfied users.

 

But despite being based on the open "standard" of DLNA (which I am sorry, I personally will never be a fan of), many of those products lock people into their brand solutions with both their hardware and software--possibly by necessity since no company can afford to provide technical support for a whole universe of s/w and h/w.

And as for the notion of plug-and-play and it just works, it seems to me that present Ethernet/DLNA systems don't truly fit that billing. If anyone thinks I am making this up, just visit the forums for Linn and Naim and read the countless threads on getting and keeping things working right.

 

Whereas despite being less flexible (for distance, multi-room, etc.), USB generally just works. And it works with ANY s/w player and ANY DAC, with most any file format that can be decoded by the player.

 

All that aside, it is no secret that present day Ethernet/DLNA renderers require more complexity at the DAC end, and limit the choice of player s/w. It is not really "computer audio" at that point, rather it become "appliance audio" with the user buying into a particular system solution. That is okay for many, and I am sure it can be done in a "purist" manner. For myself and my business I would just rather work towards something new and more universally compatible (and affordable for DAC designers to incorporate into their products without having to plan for a software development and technical support staff.).

 

Cheers,

 

--Alex C.

[Habanero Monk]

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

 

 

 

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

 

 

 

 

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

 

Sounds like you are doing the HD Home Run but for audio. The unit acts as a bridge in this scenario. On one side sits the Antenna (source) and then it ties into the network.

 

Computer finds it as a Media Center Tuner using a default class and Voila you have your Terrestrial broadcast packetized.

 

Not sure what you guys are doing that Dante isn't or Crown or Meridian.

 

Curious as to how you are going to supersede I2S (if I'm reading your post correctly). That would require custom sand I believe.

[Habanero Monk]

 

Whereas despite being less flexible (for distance, multi-room, etc.), USB generally just works. And it works with ANY s/w player and ANY DAC, with most any file format that can be decoded by the player.

 

--Alex C.

 

USB not being routable, also being realtime does present problems. However distance limitations for many a home need not apply with USB Balluns that use CAT5 cabling to extend the run.

 

I have one particular way to send out a configured box: I pre-assign a 172.16.xxx.xxx/24 address and the master computer that is used on the customer network is multi-homed NIC.

 

Just point the customer to a 5 minute YouTube video to get it connected / self configured. Hardly ever get a call. On the occasional call it takes me about 3 minutes to tell them it's working and have a nice day.

 

If I can't do it in 3 minutes I get to charge them for fixing their network!

[rodrigaj]

I'm not sure what is meant by being "locked into a solution".

 

I have DLNA/upnp. I have a choice of NAS. I have a choice of server software. I have a choice of DAC. I have a choice of controller. I have a choice of controller software. I picked the Rendu renderer. I had other choices as well. And all of this came in for less $$ than my 2003 analog VPI front end. The sound so good that I hardly ever play LP's anymore.

 

I have had this system for 4 months now and I have no issues. Never.

 

So, my point is not to dispute what has been said. It's just that if you are a newbie like I was, DLNA/upnp is painless, not too expensive and extremely reliable.

 

I also have for my subscription to the Berlin Philharmonic Digital Streaming service a USB implementation with an Audiophilleo spdf converter and a little parasound zdac attached to my iMac. I can definitely see that choices are greater, but that is not necessarily a good thing.

[Distinctive]

Re: DLNA/uPnP - Another approach would be to spread the OH standard to make renderers interoperable and thus less tied up to proprietary solutions.