Jump to content
fdreed

Rendu with ANY output other than USB

Rate this topic

Recommended Posts

I haven't seen it mentioned in a while, so I would like to reiterate a point others have made: I would love to be able to use an opticalRendu and would purchase one instantly if it had ANY output other than USB. It would be ideal if the USB circuitry was eliminated in favor of this other output. And no, I don't want to add another box and power supply downstream (like the ultraDigital).

 

I know you are very busy fulfilling existing demand for the current version. I am just suggesting that you could make an additional killing with the non-USB version that has been suggested.

 

Thank you.

Share this post


Link to post
Share on other sites
20 minutes ago, fdreed said:

I haven't seen it mentioned in a while, so I would like to reiterate a point others have made: I would love to be able to use an opticalRendu and would purchase one instantly if it had ANY output other than USB. It would be ideal if the USB circuitry was eliminated in favor of this other output. And no, I don't want to add another box and power supply downstream (like the ultraDigital).

 

I know you are very busy fulfilling existing demand for the current version. I am just suggesting that you could make an additional killing with the non-USB version that has been suggested.

 

Thank you.

Right now I'm keeping on eye one piece of technology that unfortunately is not advancing much. Another idea I'm considering is to replace the ultraDigital with a version that does not need an external power supply. This is because the Rendu series has great USB power if feed from a good power supply. These combined with a dual faceplate will make for a one box with one power supply solution. 

Share this post


Link to post
Share on other sites

@fdreed, I am curious as to why you appear to be so against using USB audio?  I am not attempting to challenge your opinion, but I would like to point out that USB audio, in general, has equal or better performance than SPDIF/AES because its asynchronous nature allows the master clock to be in the DAC (where it should be), and does not require that master clock to be synched to any external clock.  When one uses SPDIF/AES, the incoming clock signal from the source is the clock source for the DAC, and this clock signal (due to being embedded in the single wire data stream of SPDIF and the distance travelled) will have more jitter (implementation being equal) than an internal master clock in the DAC.

The notion that USB audio is somehow inherently flawed is a false one.  While it is true that with some source/DAC combinations USB may not be the best performing input; this only happens is the source has a poorly performing USB output, and/or the DAC has a poorly performing USB input.  I can assure folks the the USB output from the Sonore Rendus is excellent.  There is ample evidence on the performance of DAC USB inputs at Stereophile.com in John Atkinson's DAC measurements: every DAC measured within the last few years has equal or better performance from its USB input vs its other inputs.

 

I would also add, that implementing a really good SPDIF output on Sonore Rendu products will significantly increase their complexity-to do a really good SPDIF output would require the addition of a separate power supply, two more "Femto" clocks, with their low noise supplies, as well as a SPDIF transceiver chip and other associated circuitry-such will result in a  considerable increase to the final price.  While it is likely that Sonore will add a version with SPDIF output at some point to meet some customer's needs, the solution of using the ultraDigital is really a very good one, as this allows for customers to only pay for what they really need: those who want to use USB only pay for that output, and not the additional expense/complexity of the SPDIF output, while those who want SPDIF can add the (excellent and affordable) ultraDigital and the (required for good performance anyway) additional power supply.


ROON: DSD 256-Signature Rendu optical--Buffalo PRO (ESS 9038) or DSC-2--Ncore 400 Stereo-Focus Audio FS888-JL E-112 sub-Nordost Tyr USB, Nordost Frey XLR & speaker, DIY AC cables-Synergistic Blue & Hi Fi Tuning Supreme Cu Fuses, Dark Matter system clarifiers.    Design/Build Consultant with Sonore

 

                                                                                                  SONORE computer audio

Share this post


Link to post
Share on other sites

There is a least one other USB to I2S solution currently in the market place that does use USB power, but I don't see sending power down the same cable as the signal as an improvement, even though it does save the price of one high performance LPS. In addition, this approach still requires converting ethernet to USB first, which to me seems an extra unneeded noise producing step, and the added expense of yet another  "hi-performance" USB cable.

 

Is it that difficult to directly change fiberoptic ethernet to, say, I2S in one box (or is it optical -> electrical -> I2S)? I know there are products that do ethernet -> I2S, but they all require separate optical conversion. Is it the unavailability of an off-the-shelf conversion chip?

Share this post


Link to post
Share on other sites

@barrows I agree that the master clock should be in the DAC. If we limit the discussion to DACs that internally re-clock the signal from every input, rather than referencing an external clock, the inputs tend to equalize with respect to data transfer and jitter, and mainly differ in the nature and amount of noise transmitted. The USB cable is demonstrably the worst in this regard, hence the frequent pairing of a Rendu product with a USB cable that costs several multiples of the price of the Rendu. Said differently, you can achieve similar (arguably better) SQ with a much less expensive cable to any other input. My own tests have reinforced this opinion.

 

The ultraDigital may indeed be an excellent and affordable product, but it still requires an expensive USB cable and an expensive LPS to perform optimally -there goes the affordable. I think it stands to reason -if you can eliminate one conversion, one power supply, and one cable, you will generate less noise -especially if it is downstream of the optical "filter".

 

We are now at a point where bit perfect data transfer is essentially a given. As more DACs re-clock the bit perfect data themselves, the overall contribution of jitter to SQ should become less relevant to how we configure our systems -i.e. jitter becomes DAC dependent. That leaves controlling noise (EMI, RFI, ground loops etc.) as the final battle ground for the end user. Breaking the electrical ethernet connection with an optical segment seems like an excellent idea in this regard. Putting additional data conversions, power supplies, and cables past this "break" seems like going backwards.

 

 

Share this post


Link to post
Share on other sites

@fdreed:

 

I would suggest that the number of DACs which can actually re-clock an SPDIF input asynchronously, without resorting to using a PLL (or DPLL) to synchronize with the incoming clock can be counted on less than the fingers on a single hand.  Many DACs claim "re-clocking" but actually use a DPLL to adjust the differences between the incoming master clock and the DAC clock-this does not eliminate the problems inherent in the clock embedded in the SPDIF data stream.  Ayre is one DAC that actually includes a truly asynchronous SPDIF receiver, there are very few others.

 

As far as cables go, yes, good cabling is required for best performance.  The same is true for SPDIF, USB, analog, speaker, etc.  I find nothing odd about this.  Although, experience suggests, for USB at least, that the difference the cable makes is much less if the USB source is superb, and the USB receiver is superb.

 

I totally agree that simplicity is preferred: hence my recommendation of the Rendu (optical), with a good USB cable, direct into a DAC (with good USB receivers onboard), and no use of SPDIF or those conversions whatsoever.  Just USB, direct to I2S direct into the DAC.  SPDIF actually requires an additional conversion:  From I2S to SPDIF at the source, and from SPDIF to I2S at the DAC.

 

The SPDIF interface in general is compromised as it embeds the I2S signal into a single wire (from 4 data sets: bit clock, word clock, master clock, and data) and this embedded signal needs to be de-embedded int he DAC.  Both of these conversions can also be lossy, although the SPDIF transceiver chips have improved a lot over the years.

 

Data conversions, if we now think of them as true data streams (like USB audio, or Ethernet audio) which are not time dependent like SPDIF is, are not lossy or noisy, unless serious engineering errors have been made.  OTOH, an SPDIF conversion from I2S or to I2S is problematic due to its non asynchronous nature (again excepting the very few DACs which can actually operate asynchronously on SPDIF).


ROON: DSD 256-Signature Rendu optical--Buffalo PRO (ESS 9038) or DSC-2--Ncore 400 Stereo-Focus Audio FS888-JL E-112 sub-Nordost Tyr USB, Nordost Frey XLR & speaker, DIY AC cables-Synergistic Blue & Hi Fi Tuning Supreme Cu Fuses, Dark Matter system clarifiers.    Design/Build Consultant with Sonore

 

                                                                                                  SONORE computer audio

Share this post


Link to post
Share on other sites
15 hours ago, fdreed said:

and the added expense of yet another  "hi-performance" USB cable.

 

There exist an excellent $35 option 😀

Share this post


Link to post
Share on other sites
12 hours ago, barrows said:

I would suggest that the number of DACs which can actually re-clock an SPDIF input asynchronously, without resorting to using a PLL (or DPLL) to synchronize with the incoming clock can be counted on less than the fingers on a single hand.  Many DACs claim "re-clocking" but actually use a DPLL to adjust the differences between the incoming master clock and the DAC clock-this does not eliminate the problems inherent in the clock embedded in the SPDIF data stream.  Ayre is one DAC that actually includes a truly asynchronous SPDIF receiver, there are very few others.

 

Barrows

This whole post and the previous one is a very good explanation of USB vs SPDIF I think. Thanks for writing this.

 

Made me thinking if my Theta Generation VIII S3 actually is within the very few ones. So I start reading  https://www.thetadigital.com/generationviii/ and as far as I can understand it probably is 😀

Do you agree ?

 

@fdreed

As my expensive DAC doesn’t have USB, I have spent some time testing USB to SPDIF converters. There are many to choose among. For its price the UltraDigital is quite good. Very good actually.  

I have one, but I’m currently using my modified Singxer SU-1 with external power supply. (A much more expensive solution). 

 

The UltraDigital is a condensed version of the SU-1.

 

So you either has to change your DAC, or use a USB / SPDIF converter.

I think you should be able to find a tread or two here at AS about the converters.

 

What DAC do you have ?

 

Share this post


Link to post
Share on other sites
On 4/5/2019 at 1:14 AM, vortecjr said:

Another idea I'm considering is to replace the ultraDigital with a version that does not need an external power supply.

 

Depending on power supply in use, a Y-split may solve this 😀

 

(Same PS for a Rendu and the UltraDigital).  

Share this post


Link to post
Share on other sites
On 4/5/2019 at 10:14 AM, vortecjr said:

Right now I'm keeping on eye one piece of technology that unfortunately is not advancing much.

 

Merging's Zman? Or something else?

 

Share this post


Link to post
Share on other sites

@barrows:

 

Thank you for taking the time to respond, some great information comparing asynchronous USB to synchronous SPDIF.

 

If we, however, focus on the only those DACs that treat all inputs asynchronously, I think we agree that having the master clock in the DAC itself is overall quite beneficial. If we can measure that we get bit perfect data to the I2S bus through all inputs and are using the DAC as the master clock on that data, then the only difference in SQ between inputs must be due to noise -either that presented to the DAC through the input cable, or that generated by the individual input circuits -> I2S. The important aspect to address in this situation is to minimize the noise coming to the DAC and then choose the input that adds the least amount as the signal is processed on the way to the bus.

 

To move from the philosophical to the practical, when I render an optical ethernet transmission, I hear a difference in SQ depending on the input used on my particular DAC. I2S > AES = Coaxial > Toslink > USB. This is all with 3 figure ($$$) cables and no 4 figure ($,$$$) or more expensive cables. It could be argued that this particular USB input is poorly engineered, but it's the one I have.

 

So I have no particular ax to grind against USB audio (though I may have over-generalized my own situation). It is just that, in my particular case, I would prefer an optical renderer with any output other than USB, with I2S as my best hope.

Share this post


Link to post
Share on other sites
14 minutes ago, fdreed said:

To move from the philosophical to the practical, when I render an optical ethernet transmission, I hear a difference in SQ depending on the input used on my particular DAC. I2S > AES = Coaxial > Toslink > USB. This is all with 3 figure ($$$) cables and no 4 figure ($,$$$) or more expensive cables. It could be argued that this particular USB input is poorly engineered, but it's the one I have.

Or, the USB source could be a problem.  USB sources vary by a great deal in terms of their quality, both noise, and in signal integrity (I am not suggesting any bit loss, but signal integrity matters as to how the USB.  If your AES or I2S source is significantly better, the difference may boot have anything to do with differences in the DAC.  Or, the results could be due to the combined negative effects of both source and DAC inputs.

One would have to consider all the possibilities here, and if one is not using a source with super high quality USB output, then one cannot really draw a valid conclusion about the performance of the DAC's inputs.

 

I am not trying to be argumentative, just making sure anyone reading here tests all the possibilities before drawing any conclusions.

 

If i had a DAC where I had tested the USB input with a Sonore Signature Rendu SE via both USB and in combination with the ultraDigital via I2S (and the ultraDigital was powered by its own, nearly perfect), linear power supply, and the DAC performed objectively better (measured jitter and or low level resolution and or noise floor), then for sure I would conclude the USB input on that DAC is compromised, and if I was married to that DAC (otherwise) I would make a search for the best I2S source I could find which was compatible.

But really, if I had such a DAC, I would be very disappointed and probably want to get rid of it, as poor USB performance is an indicator of inadequate engineering and I would suspect other problems if the USB input were poor...  that is just me though, an opinion.   


ROON: DSD 256-Signature Rendu optical--Buffalo PRO (ESS 9038) or DSC-2--Ncore 400 Stereo-Focus Audio FS888-JL E-112 sub-Nordost Tyr USB, Nordost Frey XLR & speaker, DIY AC cables-Synergistic Blue & Hi Fi Tuning Supreme Cu Fuses, Dark Matter system clarifiers.    Design/Build Consultant with Sonore

 

                                                                                                  SONORE computer audio

Share this post


Link to post
Share on other sites
1 hour ago, fdreed said:

@barrows:

 

Thank you for taking the time to respond, some great information comparing asynchronous USB to synchronous SPDIF.

 

If we, however, focus on the only those DACs that treat all inputs asynchronously, I think we agree that having the master clock in the DAC itself is overall quite beneficial. If we can measure that we get bit perfect data to the I2S bus through all inputs and are using the DAC as the master clock on that data, then the only difference in SQ between inputs must be due to noise -either that presented to the DAC through the input cable, or that generated by the individual input circuits -> I2S. The important aspect to address in this situation is to minimize the noise coming to the DAC and then choose the input that adds the least amount as the signal is processed on the way to the bus.

 

To move from the philosophical to the practical, when I render an optical ethernet transmission, I hear a difference in SQ depending on the input used on my particular DAC. I2S > AES = Coaxial > Toslink > USB. This is all with 3 figure ($$$) cables and no 4 figure ($,$$$) or more expensive cables. It could be argued that this particular USB input is poorly engineered, but it's the one I have.

 

So I have no particular ax to grind against USB audio (though I may have over-generalized my own situation). It is just that, in my particular case, I would prefer an optical renderer with any output other than USB, with I2S as my best hope.

What DAC are you talking about?

Share this post


Link to post
Share on other sites

I generally try not to discuss specific brands as the original intent of the post so often spirals out of control after that... however, I'm currently using the PSAudio DirectStream DAC. An interesting and probably little known feature of this DAC, is the possibility of sending it test files that the DAC confirms are received bit perfect. This feature is of great help when setting up different inputs and testing different cables, control software (Roon), etc.

 

 

Share this post


Link to post
Share on other sites

I am by no means certain that the DS DAC is asynchronous on either is I2S or SPDIF inputs.  The descriptions given by PS audio are not precise enough to be sure, but it may be so.  The question I would ask of PS audio to really determine true asynchronous operation would be whether there is a PLL/DPLL being used.  If there is any PLL/DPLL then it is not truly asynchronous.  Unfortunately, many DAC manufacturers do not give precise enough technical descriptions of how the products operate to be certain-a DAC can re-clock, without being asynchronous, by using a PLL/DPLL.

Interestingly, the VP of Sonore used to own a DS DAC, and he preferred the USB fed by the Signature Rendu SE over any other input.


ROON: DSD 256-Signature Rendu optical--Buffalo PRO (ESS 9038) or DSC-2--Ncore 400 Stereo-Focus Audio FS888-JL E-112 sub-Nordost Tyr USB, Nordost Frey XLR & speaker, DIY AC cables-Synergistic Blue & Hi Fi Tuning Supreme Cu Fuses, Dark Matter system clarifiers.    Design/Build Consultant with Sonore

 

                                                                                                  SONORE computer audio

Share this post


Link to post
Share on other sites

According to the engineer of the DSDac: no PLLs, FLLs, etc. that track any input, so jitter doesn’t transfer from the inputs to the output clocking.

 

1 hour ago, barrows said:

Interestingly, the VP of Sonore used to own a DS DAC, and he preferred the USB fed by the Signature Rendu SE over any other input. 

 

Yes, it is extremely difficult to control all the variables to compare inputs -I am unaware of any renderer that has all the outputs we are discussing. I used a TDLInk optical ethernet segment, ultraRendu, ultraDigital, and Aries G1, to discern my preference (I2S > AES = Coaxial > Toslink > USB), in my particular system, and I do understand it is just one man's opinion. 

Share this post


Link to post
Share on other sites
31 minutes ago, fdreed said:

According to the engineer of the DSDac: no PLLs, FLLs, etc. that track any input, so jitter doesn’t transfer from the inputs to the output clocking.

Good to know!


ROON: DSD 256-Signature Rendu optical--Buffalo PRO (ESS 9038) or DSC-2--Ncore 400 Stereo-Focus Audio FS888-JL E-112 sub-Nordost Tyr USB, Nordost Frey XLR & speaker, DIY AC cables-Synergistic Blue & Hi Fi Tuning Supreme Cu Fuses, Dark Matter system clarifiers.    Design/Build Consultant with Sonore

 

                                                                                                  SONORE computer audio

Share this post


Link to post
Share on other sites
1 hour ago, fdreed said:

According to the engineer of the DSDac: no PLLs, FLLs, etc. that track any input, so jitter doesn’t transfer from the inputs to the output clocking.

That's impossible for a source, such as S/PDIF, with no feedback channel for flow control.

Share this post


Link to post
Share on other sites
2 hours ago, mansr said:

That's impossible for a source, such as S/PDIF, with no feedback channel for flow control.

Actually it is not impossible.  Ayre does it in the QX-5 DAC.  I discussed this directly with Ayre engineer Ariel (I forget his last name).  They have a full asynchronous SPDIF input, with software control of a pretty big RAM buffer.  He would not reveal all the details, but the software controls when the buffer resets.  So, samples are timed out of the buffer only via the DAC masterclock (which is a free running oscillator with no PLL).  Now, if one tried to play endless music, with no gaps, for too long, eventually there would be a problem (overflow of buffer, or buffer running out of samples), but music typically ends at some point in time (between tracks, or at the end of a playlist) where the buffer can be reset.  So, there is of course no flow control back to the source (impossible with SPDIF as you mention) but with a large enough buffer and some smart software an asynchronous SPDIF input can be accomplished.


ROON: DSD 256-Signature Rendu optical--Buffalo PRO (ESS 9038) or DSC-2--Ncore 400 Stereo-Focus Audio FS888-JL E-112 sub-Nordost Tyr USB, Nordost Frey XLR & speaker, DIY AC cables-Synergistic Blue & Hi Fi Tuning Supreme Cu Fuses, Dark Matter system clarifiers.    Design/Build Consultant with Sonore

 

                                                                                                  SONORE computer audio

Share this post


Link to post
Share on other sites
2 hours ago, mansr said:

That's impossible for a source, such as S/PDIF, with no feedback channel for flow control.

 

Or as @JohnSwenson did for the unique S/PDIF input of the Bottlehead DAC, which was to use an FPGA instead of a traditional S/PDIF receiver with its jitter-prone PLL.  He did a little cleanup of the S/PDIF signal then sent it into an FPGA for the decoding. But the special part was that he’s used a digitally controlled low phase-noise clock, with performance close to some of the best fixed frequency clocks. The FPGA told the variable clock to speed up or slow down so it was synchronized to the average data rate of the source.  It was a REALLY good S/PDIF input!

Share this post


Link to post
Share on other sites
24 minutes ago, Superdad said:

 

Or as @JohnSwenson did for the unique S/PDIF input of the Bottlehead DAC, which was to use an FPGA instead of a traditional S/PDIF receiver with its jitter-prone PLL.  He did a little cleanup of the S/PDIF signal then sent it into an FPGA for the decoding. But the special part was that he’s used a digitally controlled low phase-noise clock, with performance close to some of the best fixed frequency clocks. The FPGA told the variable clock to speed up or slow down so it was synchronized to the average data rate of the source.  It was a REALLY good S/PDIF input!

 

At a high level that sounds like the way Ted Smith and Rob Watts do it too, although hard to know without nitty gritty details of how they do it.

 

Share this post


Link to post
Share on other sites
8 hours ago, Em2016 said:

 

At a high level that sounds like the way Ted Smith and Rob Watts do it too, although hard to know without nitty gritty details of how they do it.

 

They are probably similar, but differ since there was no collaboration that I'm aware of between them. 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...