LAN Input DACs

[wadeh911]

This is a fascinating exchange of ideas. Thanks for giving a glimpse into a very complex project. Can't wait for these Ethernet Multichannel DAC's to become reality.

[Miska]

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.

 

Good... Of course half of the beef in NAA is that the approach also completely bypasses any OS audio stack and goes straight from the player to the remote device.

 

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.

 

USB has the burden that driver software needs to generate packets that comply with USB specification, in case of UAC there's also additional burden that the packets need to follow UAC standard at the higher level too. Some USB interfaces avoid the second burden by using proprietary protocol. Good example is to compare size of the M2Tech hiFace Linux-driver and size of the UAC2 driver, the UAC2 driver being much bigger and much more complex.

 

To me, UAC2 is just like UPnP/DLNA - "designed by committee" so that it is very complex, while still completely omitting important bits like native DSD support.

 

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.

 

There's no free lunch... I could make an ASIO driver for NAA, but then I would need to find a model to get some compensation for it too. So it wouldn't be free from licensing limitations either. I have zero interest to provide free support to other players.

[vortecjr]

Anyone who doubts the viability of UPNP/DLNA just needs to read the Rendu review here on CA. You can also scan the comments on the PS Audio forum and you will find that the system just works and sounds great....

 

Computer Audiophile - Simple Design Rendu Ethernet to S/PDIF Converter Review

 

Jesus R

[Superdad]

Anyone who doubts the viability of UPNP/DLNA just needs to read the Rendu review here on CA. You can also scan the comments on the PS Audio forum and you will find that the system just works and sounds great....

 

Hi Jesus:

I certainly did not mean to turn this thread into a bash DLNA conversation. Indeed DLNA works, and works well, for many many products and many people around the world. And of course the Rendu (and awesome new Rendu Signature--looking forward to Chris' review of that) has its own hardware advantages which help it outperform musically many of the other DLNA solutions. And like what I was getting at, it does not have to have a computer processor and OS in it.

 

Personally I have only had a couple of frustrating run ins with getting DLNA to work, and others may not have any problems. I'd just like to see some cleaner, simpler, high-end audio-focused hardware solutions come forth. Ones that allow total freedom of choice with regards to s/w player use.

 

As Miska just reminded us, "there's no free lunch." To that I will add the indelicate "there is more than one way to skin a cat."

 

Best,

--Alex

[Miska]

Anyone who doubts the viability of UPNP/DLNA just needs to read the Rendu review here on CA. You can also scan the comments on the PS Audio forum and you will find that the system just works and sounds great....

 

Now put software upsampling into it and figure out how to change the upsampling filters and parameters from standard UPnP control point...

 

Btw, how do you connect for example five DACs to it, and select which one to play to from the control point too?

[tranz]

Now put software upsampling into it and figure out how to change the upsampling filters and parameters from standard UPnP control point...

 

Btw, how do you connect for example five DACs to it, and select which one to play to from the control point too?

 

Hi Miska,

 

Although I have not tried it yet, I understand that your filter magic require a bit of processing power, which obviously we want to keep far away from the DAC.

 

But if all the user wants to do is serve audio files unaltered, unprocessed, without upsampling to the DAC, why would DLNA not suffice?

 

Are there packets or bits getting lost without the user knowing?

 

Cheers

[tranz]

Anyone who doubts the viability of UPNP/DLNA just needs to read the Rendu review here on CA. You can also scan the comments on the PS Audio forum and you will find that the system just works and sounds great....

 

Computer Audiophile - Simple Design Rendu Ethernet to S/PDIF Converter Review

 

Jesus R

 

Hi Jesus,

 

Thanks for joining the discussion. The Rendu looked close to ideal. Is there a reason you did not go with a LAN output module? Beside the obvious that there are not many DACs with this capability, was there a technical, EE, software reason? Is the Rendu capable of bypassing SPDIF and translating a served up audio file directly into I2S, or is that a naive thought?

 

Cheers

[Miska]

But if all the user wants to do is serve audio files unaltered, unprocessed, without upsampling to the DAC, why would DLNA not suffice?

 

That's quite limited use case...

 

I didn't even get to dealing with digital room correction and multichannel setups yet.

 

Are there packets or bits getting lost without the user knowing?

 

For getting unaltered data to DAC, DLNA is not good either. First, to get anything started it requires very delicate dancing between three devices. And it requires processing from the renderer (decoding source content). It is not very good for unprocessed either, because you don't know if and how the server is messing with your data.

 

At the end, It is practically same as telling your web browser to play content from a web server, like YouTube. Control Point is telling which content Renderer (you web browser) should load from the Media Server (web server). If you need to seek backwards, Renderer needs to disconnect from the server and issue a new HTTP GET request, because you cannot go backwards in the stream. Since the GET request is made with byte offset it is only whereabouts with any compressed stream (like FLAC), because exact position cannot be calculated on a variable bitrate.

 

I didn't like UPnP before, and after implementing UPnP/AV support to HQPlayer I like it even less. It is also very prone to all kinds of network issues which are hard to track down. For example I had two dumb gigabit switches (non-managed) that didn't pass UPnP for some strange reason, but for example NAA was working fine through those. I spent lot of time chasing down why it didn't work and at the end, using Wireshark I discovered that the mDNS packets sent to the switch didn't appear on any other port. It's a tech support nightmare.

[vortecjr]

Hi Jesus:

I certainly did not mean to turn this thread into a bash DLNA conversation. Indeed DLNA works, and works well, for many many products and many people around the world. And of course the Rendu (and awesome new Rendu Signature--looking forward to Chris' review of that) has its own hardware advantages which help it outperform musically many of the other DLNA solutions. And like what I was getting at, it does not have to have a computer processor and OS in it.

 

Personally I have only had a couple of frustrating run ins with getting DLNA to work, and others may not have any problems. I'd just like to see some cleaner, simpler, high-end audio-focused hardware solutions come forth. Ones that allow total freedom of choice with regards to s/w player use.

 

As Miska just reminded us, "there's no free lunch." To that I will add the indelicate "there is more than one way to skin a cat."

 

Best,

--Alex

 

The Rendu and Signature Series Rendu couldn't be any simpler to use or any simpler in design. These products are every bit 'high end audio focused hardware solutions'. These products are also presently available and not a nice idea for the future:)

 

Jesus R

[vortecjr]

Now put software upsampling into it and figure out how to change the upsampling filters and parameters from standard UPnP control point...

 

Btw, how do you connect for example five DACs to it, and select which one to play to from the control point too?

 

Can you run all your filters on a Arm or Atom processor? Would it be fare to suggest your product has limitations because it might not be able to do that? I don't think it's fare. I like what your doing with your software, but it's not my vision for my product. If my customers need those features I'm happy to send them to you. If you read Chris' review you will see that a JRiver can stream to multiple renderers. Also, JRiver can up sample via DLNA...

 

Jesus R

[vortecjr]

Hi Jesus,

 

Thanks for joining the discussion. The Rendu looked close to ideal. Is there a reason you did not go with a LAN output module? Beside the obvious that there are not many DACs with this capability, was there a technical, EE, software reason? Is the Rendu capable of bypassing SPDIF and translating a served up audio file directly into I2S, or is that a naive thought?

 

Cheers

 

I guess I don't understand the question about the LAN output. What are you trying to do? The Rendu has built in Async Ethernet to I2S support and we offer it as an output on both units in the series.

 

Jesus R

[Superdad]

The Rendu and Signature Series Rendu couldn't be any simpler to use or any simpler in design. These products are every bit 'high end audio focused hardware solutions'. These products are also presently available and not a nice idea for the future:)

 

Right you are Jesus! I certainly was not dissing the Rendus. And with the awesome support that I hear you provide you are making DLNA safe and easy for many.

[Miska]

Can you run all your filters on a Arm or Atom processor? Would it be fare to suggest your product has limitations because it might not be able to do that? I don't think it's fare. I like what your doing with your software, but it's not my vision for my product. I have no need for the features you mention and neither do my customers. If they do need those features I'm happy to send them to you.

 

Yes, up to DSD64 on CuBox-i4Pro (quad-core iMX6), with full desktop GUI. But this is not about any certain implementation, but about limitations of the standard.

 

BTW JRiver can up sample via DLNA...

 

So can HQPlayer. But how do you configure and control the upsampling parameters from BubbleUPnP, PlugPlayer, Kinsky or some other UPnP Control Point?

 

 

I like the AirPlay/Miracast model more...

[vortecjr]

That's quite limited use case...

 

I didn't even get to dealing with digital room correction and multichannel setups yet.

 

 

 

For getting unaltered data to DAC, DLNA is not good either. First, to get anything started it requires very delicate dancing between three devices. And it requires processing from the renderer (decoding source content). It is not very good for unprocessed either, because you don't know if and how the server is messing with your data.

 

At the end, It is practically same as telling your web browser to play content from a web server, like YouTube. Control Point is telling which content Renderer (you web browser) should load from the Media Server (web server). If you need to seek backwards, Renderer needs to disconnect from the server and issue a new HTTP GET request, because you cannot go backwards in the stream. Since the GET request is made with byte offset it is only whereabouts with any compressed stream (like FLAC), because exact position cannot be calculated on a variable bitrate.

 

I didn't like UPnP before, and after implementing UPnP/AV support to HQPlayer I like it even less. It is also very prone to all kinds of network issues which are hard to track down. For example I had two dumb gigabit switches (non-managed) that didn't pass UPnP for some strange reason, but for example NAA was working fine through those. I spent lot of time chasing down why it didn't work and at the end, using Wireshark I discovered that the mDNS packets sent to the switch didn't appear on any other port. It's a tech support nightmare.

 

I respect that you don't like this approach, but to suggesting these issues are typical results is nonsense. I can tell you support on the Rendu series is nearly zero. The most demanding support questions I get are about how to rip CDs and or how to setup JRiver properly. I'm sorry your having problems with your UPNP implementation, but they are your problems not mine.

 

Jesus R

[vortecjr]

Alex, thank you for your comments.

 

Jesus R

[Miska]

I'm sorry your having problems with your UPNP implementation, but they are your problems not mine.

 

Again, I'm not talking of any particular implementation, I'm talking about the standard.

 

UPnP standard is built on top of HTTP standard and limitations and stupidities of HTTP standard have nothing to do with my implementation. You can also read yourself what UPnP/AV standard says about server side transcoding and what DLNA standard says about mandatory and optional codecs.

 

It is not my implementation problem either if BubbleUPnP nor PlugPlayer can find MinimServer (or Sony TV, game consoles, Windows or anything else) over UPnP because switch doesn't let the necessary ethernet packet through. I've also heard of similar problems for certain internet routers between their built-in WiFi and ethernet too. And I've read reviews of UPnP gear on magazines too.

 

None of this has nothing to do with my implementation.

 

 

By the way, I cannot find Rendu from the DLNA product search:

Product Search

[tranz]

I guess I don't understand the question about the LAN output. What are you trying to do? The Rendu has built in Async Ethernet to I2S support and we offer it as an output on both units in the series.

 

Jesus R

 

Hi Jesus,

 

I see the I2S HDMI and SPDIF Coax outputs, but not an ethernet output. The thinking is a cleaner path into the DAC, via an Ethernet cable as opposed to USB or SPDIF Coax.

 

There were a few DACs mentioned above, and a rumour that MSB is working on a LAN input module. This to avoid the noisy USB and the jitter inducing (all relative, I realize) SPDIF. Direct translation of audio file into I2S or balanced I2S Pro, and transport via ethernet. The Rendu, I thought first translates everything into SPDIF, and then another translation to I2S, is that not correct?

 

Unrealistic?

 

Cheers

[Superdad]

I could make an ASIO driver for NAA, but then I would need to find a model to get some compensation for it too. So it wouldn't be free from licensing limitations either. I have zero interest to provide free support to other players.

 

Well Jussi, if you want to see DLNA supplanted by something else, then you might want to take a closer look at crating something to license. When I made the suggestion, I did not mean you should give it away for free. AirPlay is crippled, requires h/w, and a giant fee to Apple. There is room in the market for you to do something.

That, or take steps to make your NAA easier and more popular (wink, wink; inside jab referencing other thread) .

[tranz]

Hi Superdad,

 

Of course intrigued by what you and John are up to!

 

In your design, would a user be able to play back from NAS or Amarra, JRiver, Audivarna, HQplayer on a CAPS/MacCAPS, internet radio, etc. and through an ethernet connection send the data to a DAC?

 

Cheers

[Superdad]

Hi Jesus,

 

I see the I2S HDMI and SPDIF Coax outputs, but not an ethernet output. The thinking is a cleaner path into the DAC, via an Ethernet cable as opposed to USB or SPDIF Coax.

 

There were a few DACs mentioned above, and a rumour that MSB is working on a LAN input module. This to avoid the noisy USB and the jitter inducing (all relative, I realize) SPDIF. Direct translation of audio file into I2S or balanced I2S Pro, and transport via ethernet. The Rendu, I thought first translates everything into SPDIF, and then another translation to I2S, is that not correct?

 

Unrealistic?

 

Cheers

 

I'll jump in here for this: Tranz, the Rendu is not a DAC, it is an Ethernet input device (with I2S and S/PDIF outputs). So having Ethernet output makes no sense. And no, the Rendu does not first convert to S/PDIF and then to I2S. The data coming off the rendering input module/processor feeds either the I2S board (with its LVDS HDMI driver) OR the S/PDIF output circuit (maybe both at the same time, I don't know).

 

Every DAC maker is trying to find, create, or license an Ethernet input solution for their existing or next products. (I predicted this almost 9 years ago, and the real choices are still scattered.) But since both hardware and software standards are involved--some that can be bypassed, some that can be leveraged, and some that we are just plain stuck with--there is still a lot of experimentation and slogging about.

 

A good time to wait and watch…

 

(Maybe the StreamWerxs computer thing that Gordon Rankin showed a year ago will pop up again at RMAF. Still a processor/OS solution.)

[tranz]

I'll jump in here for this: Tranz, the Rendu is not a DAC, it is an Ethernet input device (with I2S and S/PDIF outputs). So having Ethernet output makes no sense. And no, the Rendu does not first convert to S/PDIF and then to I2S. The data coming off the rendering input module/processor feeds either the I2S board (with its LVDS HDMI driver) OR the S/PDIF output circuit (maybe both at the same time, I don't know).

 

Every DAC maker is trying to find, create, or license an Ethernet input solution for their existing or next products. (I predicted this almost 9 years ago, and the real choices are still scattered.) But since both hardware and software standards are involved--some that can be bypassed, some that can be leveraged, and some that we are just plain stuck with--there is still a lot of experimentation and slogging about.

 

A good time to wait and watch…

 

(Maybe the StreamWerxs computer thing that Gordon Rankin showed a year ago will pop up again at RMAF. Still a processor/OS solution.)

 

 

Thanks Superdad,

 

Yes, I know the Rendu is not a DAC, but it will be a hell of a lot quieter (electrically) then a PC or Mac. It could potentially function as a go between, a kind of electrical and reclock buffer, between NAS, Mac, PC and the DAC's Ethernet input. But perhaps I am missing something obvious and/or technical.

 

You sure about the direct to SPDIF comment, as it looks to be an additional board that is added. I will wait for Jesus to confirm.

 

Cheers

[Superdad]

Hi Superdad,

 

Of course intrigued by what you and John are up to!

 

In your design, would a user be able to play back from NAS or Amarra, JRiver, Audivarna, HQplayer on a CAPS/MacCAPS, internet radio, etc. and through an ethernet connection send the data to a DAC?

 

Cheers

 

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.

[wadeh911]

I guess I don't understand the question about the LAN output. What are you trying to do? The Rendu has built in Async Ethernet to I2S support and we offer it as an output on both units in the series.

 

Jesus R

 

which of your products supports multichannel files

[tranz]

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.

 

Sweet! Keep us informed how it progresses.

 

Cheers

[vortecjr]

which of your products supports multichannel files

 

None. Multichannel is not a point of interest for me right now. There was a company that I contacted about a driver for multichannel PCM and DSD, but they declined to participate in the project...

 

Jesus R