Simple Design Rendu Ethernet to S/PDIF Converter Review

The Rendu is not the client and is instead the renderer. It's up to each controller to see and use the server (Foobar2000, JRiver Media Center, etc..). I have not tried Foobar2000 as a server, but I have tested LMS as a server and it works great.

 

Jesus R

Not sure what the difference is between a client and a renderer; probably I was using the wrong terminology.

Using a SMPS in our design was not a consideration. Sure it could reduce the cost, but I don't fell our customers are looking for this option....

 

Jesus R

I think Linn use rather special SMPS' (which they call "Dynamik") in their products; they are used in Linn streamers and power amplifiers 15 times more expensive than your unit, and when sold as upgrades the power supplies themselves are several hundred GBP, so I think it's unfair to insinuate that Linn's use of SMPS is a cheap option.

One could go further and suggest that the architecture of your system has considerable disadvantages compared to Linns DS. You need to turn ethernet packets (which have no embedded clock and therefore no inherent jitter) into s/pdif with an embedded clock which must have jitter, and the receiving DAC will inevitably use PLLs to try and attenuate that jitter. There is no provision for clock feedback between a DAC and your product so jitter and uncertainty in clock recovery are inevitable it seems to me. In the case of the Linn streamers, because they are dealing with data directly, the correct clock frequency is known from the file metadata and data can be clocked out of the internal buffer at the precisely correct, invariant, frequency which surely must be advantageous from the jitter point of view. Other companies like NAIM audio also have network DACs which are high quality renderers, with similar advantages of completely avoiding s/pdif.

Seems to me the whole concept of ethernet to s/pdif conversion is flawed; why add jitter to data that doesn't need it?

Seems to me the whole concept of ethernet to s/pdif conversion is flawed; why add jitter to data that doesn't need it?

There's much more to it than this. The sound of a component has many variables.

Do you know what the conversion process inside the Linn unit requires and is that effects sound quality? Do the packets go directly from Ethernet to I2S? What hardware is required to do that conversion? Any intermediate SPDIF step? Any noise added by converting Ethernet internally?

Some people have existing DAC they think sound better than anything available today. Using an Ethernet to SPDIF converter allows them to get a better sound quality than purchasing a unit with Ethernet built in.

I really like Linn products but want to get my point across that there's quite a bit more to sound quality than the interface.

There's much more to it than this. The sound of a component has many variables.

 

Do you know what the conversion process inside the Linn unit requires and is that effects sound quality? Do the packets go directly from Ethernet to I2S? What hardware is required to do that conversion? Any intermediate SPDIF step? Any noise added by converting Ethernet internally?

 

Some people have existing DAC they think sound better than anything available today. Using an Ethernet to SPDIF converter allows them to get a better sound quality than purchasing a unit with Ethernet built in.

 

I really like Linn products but want to get my point across that there's quite a bit more to sound quality than the interface.

I am sure there are many more things involved in sound quality than the interface, or indeed the class of power supply. You say that you use high-quality fixed frequency clocks in your product. Wouldn't it at least be a good idea to provide a clock output from your product so that suitably equipped downstream DACs could use it, rather than it having to derive the clock from the s/pdif stream with all the drawbacks of PLLs and/or ASRC? Long term I am sure that. like Linn and Naim, DAC manufacturers will acquire the expertise to give their DACs network connectivity, just as they have acquired the expertise to give their DACs USB connectivity. s/pdif just doesn't make any sense for data that is stored on a hard-drive; the correct clock frequency is known absolutely precisely.

I think Linn use rather special SMPS' (which they call "Dynamik") in their products; they are used in Linn streamers and power amplifiers 15 times more expensive than your unit, and when sold as upgrades the power supplies themselves are several hundred GBP, so I think it's unfair to insinuate that Linn's use of SMPS is a cheap option.

That is not what I said. What I said is it could reduce the cost, but I was referring to my device. I also said that if was not a design consideration for us. Anyway, I'm not going to put a high speed switching device right next to my audio board no matter what others do.

One could go further and suggest that the architecture of your system has considerable disadvantages compared to Linns DS.

Below you are comparing a network device with SPDIF output to a network device with analog output. These are two different type of devices. Not only that, but you fail to mention that the device you are comparing to mine has 3 other digital inputs. Why is this important your wondering? This is important because you need route all those inputs through a transceiver or worse yet some kind of relay. The Rendu does not use this "architecture" and I consider it an "advantage" because we are keeping the signal patch as clean as possible.

You need to turn ethernet packets (which have no embedded clock and therefore no inherent jitter) into s/pdif with an embedded clock which must have jitter, and the receiving DAC will inevitably use PLLs to try and attenuate that jitter. There is no provision for clock feedback between a DAC and your product so jitter and uncertainty in clock recovery are inevitable it seems to me. In the case of the Linn streamers, because they are dealing with data directly, the correct clock frequency is known from the file metadata and data can be clocked out of the internal buffer at the precisely correct, invariant, frequency which surely must be advantageous from the jitter point of view. Other companies like NAIM audio also have network DACs which are high quality renderers, with similar advantages of completely avoiding s/pdif.

You have to consider the quality of the signal and I said before I have not heard a DAC that did not sound better with a better source. This device is meant to provide a very clean output for devices that don't have the ability to except an ethernet or USB input. It's also meant be used even if you have USB input and you just don't want a computer pretending to be an audio device. We a DAC option, but my goal is not to limit you to a built in DAC.

Seems to me the whole concept of ethernet to s/pdif conversion is flawed; why add jitter to data that doesn't need it?

What is flawed is your argument and comparing two things that are not the same.

I am sure there are many more things involved in sound quality than the interface, or indeed the class of power supply. You say that you use high-quality fixed frequency clocks in your product. Wouldn't it at least be a good idea to provide a clock output from your product so that suitably equipped downstream DACs could use it, rather than it having to derive the clock from the s/pdif stream with all the drawbacks of PLLs and/or ASRC? Long term I am sure that. like Linn and Naim, DAC manufacturers will acquire the expertise to give their DACs network connectivity, just as they have acquired the expertise to give their DACs USB connectivity. s/pdif just doesn't make any sense for data that is stored on a hard-drive; the correct clock frequency is known absolutely precisely.

It's not my product. I have no stake in Simple Design or its products. I'm just raising questions about the competing designs.

Also, I'd prefer a DAC with world clock output to clock a converter. I've had great results keeping the click as close to the DAC as possible.

I am sure there are many more things involved in sound quality than the interface, or indeed the class of power supply. You say that you use high-quality fixed frequency clocks in your product. Wouldn't it at least be a good idea to provide a clock output from your product so that suitably equipped downstream DACs could use it, rather than it having to derive the clock from the s/pdif stream with all the drawbacks of PLLs and/or ASRC? Long term I am sure that. like Linn and Naim, DAC manufacturers will acquire the expertise to give their DACs network connectivity, just as they have acquired the expertise to give their DACs USB connectivity. s/pdif just doesn't make any sense for data that is stored on a hard-drive; the correct clock frequency is known absolutely precisely.

You have a funny way of asking for a feature. DAC's with clock outputs are in short supply and then to complicate things there are a few different formats. This seems to be more of a pro gear solution. Also, adding the clock input complicates playback and requires manually changing things at the clock source for different playback rates.

I keep an eye on trends and I don't see DAC designs moving in the network input direction. TVs, CD players and receivers with network playback are more likely to be mainstream, but that is a different market.

Jesus R

You have a funny way of asking for a feature. DAC's with clock outputs are in short supply and then to complicate things there are a few different formats. This seems to be more of a pro gear solution. Also, adding the clock input complicates playback and requires manually changing things at the clock source for different playback rates.

 

I keep an eye on trends and I don't see DAC designs moving in the network input direction. TVs, CD players and receivers with network playback are more likely to be mainstream, but that is a different market.

 

Jesus R

I certainly agree about the clock complication. I had an Esoteric D-05 with a stand-alone G-03X. Changing the clock to match the file frequency was a royal PITA. I would never own a stand-alone clock again. . .just not worth the aggravation IMHO.

I certainly agree about the clock complication. I had an Esoteric D-05 with a stand-alone G-03X. Changing the clock to match the file frequency was a royal PITA. I would never own a stand-alone clock again. . .just not worth the aggravation IMHO.

External clocks can be like a manual transmission compared to an automatic (regular DAC). Manuals can enable better performance but less convenience.

The dCS Vivaldi doesn't require any manual changes.

External clocks can be like a manual transmission compared to an automatic (regular DAC). Manuals can enable better performance but less convenience.

 

The dCS Vivaldi doesn't require any manual changes.

I have the notes from our internal discussion regarding the master clock option. We considered 4 different options for implementing a clock input and each one has a pro/con to it. One option is to let the customer do the work which is actually pretty common. Another option was to up sample the incoming data so the rate was always consistent. Then the options start to get more complicated. I wasn't really interested in it though and decided to invest the time in the i2s and MSB Network output. To me these outputs options are way more interesting compared to a clock input. I'm currently using a Rendu.i2s into my Buffalo DAC and my VP is using a Rendu.MSB into his MSB Analog DAC and these combinations are....

Jesus R

Having two clocks in a system doesn't make sense to me. They can't both be right.

This device is quite a lot more expensive than a netbook. A netbook can equally well sit on a network on ethernet or wireless and, running foobar or JRMC to name but two, act as a UPnP renderer. If your DAC has an asynchronous USB input what would be better? Feeding it from a rendu via s/pdif, or feeding it from a netbook via asynchronous USB? Which sounds better? Which measures better?

This device is quite a lot more expensive than a netbook. A netbook can equally well sit on a network on ethernet or wireless and, running foobar or JRMC to name but two, act as a UPnP renderer. If your DAC has an asynchronous USB input what would be better? Feeding it from a rendu via s/pdif, or feeding it from a netbook via asynchronous USB? Which sounds better? Which measures better?

A lot of things would be better. Look around this forum a bit; to get a really good USB output to a DAC, people are often spending the price of Rendu for a unit which just converts USB-SPDIF accurately with good clocking. The Rendu produces a low jitter SPDIF output on its own with no intermediate USB step. I think some readers may misunderstand the value of a dedicated, network based player like the Rendu:

In a traditional compute based playback system, audiophiles go to great extremes to get a high quality, low noise output to the DAC. This is one of the reasons we see so much emphasis placed on custom servers like the Aurender, CAPs, etc, with things like SOtM USB output cards, and expensive custom power supplies, along with specialized playback software. Audiophiles have found that all of these things matter. The problem with most music servers is that they all rely on a mass produced Mother Board, designed for general computing purposes, and built to the lowest possible price point. The Rendu solves this problem, by removing consumer grade computer peripherals from the equation. All the important processing is done by a device specifically built for processing audio signals perfectly, with very low noise, to audiophile standards.

Andy: There are two fixed frequency oscillators in the Rendu to accommodate the two base frequencies of all sample rates: 44.1 kHz and 48 kHz, this is necessary to achieve the lowest possible jitter. Only one clock is active at a time, the appropriate one for the sample rate being played.

This device is quite a lot more expensive than a netbook. A netbook can equally well sit on a network on ethernet or wireless and, running foobar or JRMC to name but two, act as a UPnP renderer. If your DAC has an asynchronous USB input what would be better? Feeding it from a rendu via s/pdif, or feeding it from a netbook via asynchronous USB? Which sounds better? Which measures better?

It's all a matter of what you like. Some people will see the value proposition in the Rendu while others will see the value in a netbook. These two devices may accomplish the same thing but they do it very differently and require very different levels of user intervention.

 

Andy: There are two fixed frequency oscillators in the Rendu to accommodate the two base frequencies of all sample rates: 44.1 kHz and 48 kHz, this is necessary to achieve the lowest possible jitter. Only one clock is active at a time, the appropriate one for the sample rate being played.

I understand that only one fixed clock is active in the Rendu at once, but you have to consider the whole system - there will also be a second, independant, clock in the receiving DAC which either not be fixed and use a PLL, or use ASRC resampling. So the system has two clocks, and they can never agree. It's not very elegant to my way of thinking and can only add jitter into the system. If the Rendu fed it's clock directly to the DAC then only one clock would be in control of the process, (which is often how DACs work in a pro-environment.)

But I'm far from convinced that products like the Rendu will find more than a very small niche in the market; if you want a networked DAC why not just buy one from Naim or Linn or many others?

I understand that only one fixed clock is active in the Rendu at once, but you have to consider the whole system - there will also be a second, independant, clock in the receiving DAC which either not be fixed and use a PLL, or use ASRC resampling. So the system has two clocks, and they can never agree. It's not very elegant to my way of thinking and can only add jitter into the system. If the Rendu fed it's clock directly to the DAC then only one clock would be in control of the process, (which is often how DACs work in a pro-environment.)

 

 

Your criticism is of the SPDIF interface, not the Rendu. The Rendu with SPDIF output is for those customers who already own an SPDIF input DAC which they love. The Rendu is also available in I2S output models to suit DACs with I2S inputs: in this case the Rendu's clock can be used by the DAC as Master, as you suggest.

In any case, one thing which you do not seem to understand is that having a low jitter source, even via SPDIF is an advantage, as the SPDIF receiver circuit will produce less artifacts when fed a low jitter SPDIF data stream. Take a look at the thread here titled: "Best USB to SPDIF converter" to learn the great lengths some audiophiles will go to in order to get a low jitter SPDIF feed.

 

But I'm far from convinced that products like the Rendu will find more than a very small niche in the market; if you want a networked DAC why not just buy one from Naim or Linn or many others?

Yes, the Rendu with SPDIF output is a niche product. It is for those audiophiles who are interested in getting the best performance out of their present SPDIF input DAC, via a networked interface. For those audiophiles, the Rendu with SPDIF output is the "perfect" solution.

If the Rendu fed it's clock directly to the DAC then only one clock would be in control of the process, (which is often how DACs work in a pro-environment.)

 

But I'm far from convinced that products like the Rendu will find more than a very small niche in the market; if you want a networked DAC why not just buy one from Naim or Linn or many others?

How DACs work in the pro environment is vastly different from how DACs on the cutting edge of technology work. There is no money in pro audio to buy the best gear available. In addition the clock is usually derived from one master to feed several devices and is set for the entire time in the studio. It's not necessarily because the engineers believe in externally clocking the DAC for the best performance rather it's to keep all devices on the same clock to prevent headaches.

Again, you don't see the value proposition in the Rendu. That's completely OK. Many readers have DACs that are awesome but they want network connectivity. The Rendu fits this bill perfectly. I'm currently using a Linn Akurate DSM in for review. It's gapless performance isn't even close to the Rendu. Plus, I'm experiencing odd digital output at 4x sample rates into the dCS Upsampler. The Rendu works every time and has no configuration.

Your suggestion to just buy Linn or Naim appears based on solely on partial understanding of technologies and specs. There's nothing wrong with that but purchasing components based on those criteria frequently leads to disappointment.

I keep an eye on trends and I don't see DAC designs moving in the network input direction. TVs, CD players and receivers with network playback are more likely to be mainstream, but that is a different market.

 

Jesus R

Jesus, I also don't see that direction for most...

But I was told that Lyngdorf can add ethernet input (besides USB) on the successor of TDAI2200, but specs remain to be confirmed...

About clocks, manually changing the clock could be a showstopper to me...I hated that feature on the Hiface Evo clock, even if I was pleased with the sound...

This device is quite a lot more expensive than a netbook. A netbook can equally well sit on a network on ethernet or wireless and, running foobar or JRMC to name but two, act as a UPnP renderer. If your DAC has an asynchronous USB input what would be better? Feeding it from a rendu via s/pdif, or feeding it from a netbook via asynchronous USB? Which sounds better? Which measures better?

I recently tested a laptop againts the linn ds.

The laptop was tested with JRMC and Foobar, connected to the nice Hiface Evo stack (with clock).

The sound was nice, on par with the Linn, If I could ignore the noise issues....

So, using a usb/spdif converter - even with the power and clock companions - is not the "universal" solution for electrical isolation many people are assuming....

I got convinced that a renderer like Linn is doing a wonderful job at keeping my variables to a minimum, while sounding very good - this makes my life easier...

Rendu follows the same logic!

 

But I'm far from convinced that products like the Rendu will find more than a very small niche in the market;

Small but important...after all is my niche! :-)

if you want a networked DAC why not just buy one from Naim or Linn or many others?

If you want a network dac...you buy a network dac...rendu is redundant in that case.

Not everybody likes the sound of Linn or Naim...

I have found that Linn "sounding good" devices start at Akurate Level (I tought Majik was nice but not relaxed and refined)...That is probably out of many peoples price point.

On Naim I have less experience, but the good stuff is also not on the cheap side...

I preferred to invest in a not-networked but amplified DAC, that sounds clear, neutral and refined...certainly better than a Majik...

Well, if there was a amplified-and-networked DAC sound as good as my Lyngdorf...I would look at it with interested eyes..

Yes it has warranty. Firmware updates are done via the unit's webpage. We don't publish the parts list and reserve the right to upgrade things as we go. Also, each option has a module and it's own power supply and they are all different. There are some pics of the modules on our webpage. It's a 32 bit digital volume attenuator. The volume level is selected at the controller. You bypass volume attenuation with a 100% volume selection in the controller.

 

Jesus R

Thanks for the info. I'll contact you offline for additional info.

Jesus, I also don't see that direction for most...

But I was told that Lyngdorf can add ethernet input (besides USB) on the successor of TDAI2200, but specs remain to be confirmed...

 

About clocks, manually changing the clock could be a showstopper to me...I hated that feature on the Hiface Evo clock, even if I was pleased with the sound...

If you were to use the M2Tech Evo Clock you would have to select the rate manual. BTW I built a bunch of computer servers that had the capability to receive a master clock input and only one (1) customer ever used it...

Jesus R

This device is quite a lot more expensive than a netbook. A netbook can equally well sit on a network on ethernet or wireless and, running foobar or JRMC to name but two, act as a UPnP renderer. If your DAC has an asynchronous USB input what would be better? Feeding it from a rendu via s/pdif, or feeding it from a netbook via asynchronous USB? Which sounds better? Which measures better?

I can tell you from experience that the Rendu sounds better than any Mac based system. I have no experience with a Windows based system so I can't comment.

I understand that only one fixed clock is active in the Rendu at once, but you have to consider the whole system - there will also be a second, independant, clock in the receiving DAC which either not be fixed and use a PLL, or use ASRC resampling. So the system has two clocks, and they can never agree. It's not very elegant to my way of thinking and can only add jitter into the system. If the Rendu fed it's clock directly to the DAC then only one clock would be in control of the process, (which is often how DACs work in a pro-environment.)

 

But I'm far from convinced that products like the Rendu will find more than a very small niche in the market; if you want a networked DAC why not just buy one from Naim or Linn or many others?

Why do you care what others buy? While you're certainly entitled to your opinion, you keep shilling for other brands. It's clear to me that you have an agenda other than discussing the item under review.

If you were to use the M2Tech Evo Clock you would have to select the rate manual.

I know...the manual work was just one factor that made me stay away, altough we must consider the features for the price are nice...

But it was also the added boxes, the added cables and clutter.

BTW I built a bunch of computer servers that had the capability to receive a master clock input and only one (1) customer ever used it...

Fine, it's a good start...:-)