Rendu with ANY output other than USB

[barrows]

@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.

[barrows]

@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).

[barrows]

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.   

[barrows]

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.

[barrows]

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!

[barrows]

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.

[barrows]

2 hours ago, mansr said:

That's enough of a lag to be really annoying

Is that album 1 continuous movement with no gaps and sections?

There is no reason the DAC has to buffer an entire album, or playlist, and I am pretty certain it does not work that way.  If you would like a better explanation from Ayre as to how their asynchronous SPDIF input works, perhaps @Ryan Berry can help.  I have a great deal of confidence in the straightforward nature of Ayre's claims, and that their products actually do operate in the way that they claim.  As their company is here in Boulder, CO, I have had a fair amount of interaction with them, and their people, over the years.   

[barrows]

2 hours ago, mansr said:

While that's not specifically a PLL, it is still tracking the source clock. At a high level, it actually behaves much like a PLL too in that fluctuations in the source clock are low-pass filtered and the resulting average used to control the local clock. The advantage over a typical PLL is that the corner frequency can be much lower without losing lock.

Yeah, I would agree with that: anything which speeds up and slows down in order to accommodate source timing variations should not be considered asynchronous.  While this method will reduce the effects of jitter (by averaging them out) it does not eliminate them the way a true asynchronous interface does.

[barrows]

3 hours ago, Em2016 said:

ed has previously mentioned ESS use similar method too...

ESS uses a DPLL and asynchronous sample rate converter to reduce jitter.  It is a very good implementation of such, but it does not result in a true asynchronous interface.  (ESS chips have direct SPDIF input with an onboard SPIDIF receiver).

 

But:  The ESS chip can also be used without the DPLL and ASRC, this is how I prefer to use them, and (I believe) the way Ayre uses them in their DACs.  With the DPLL and ASRC deactivated, the ESS chip is at the mercy of the incoming data jitter level.  In my ESS 9038 based DAC I prefer to use a very good, isolated, asynchronous USB interface synched to the local masterclock to create a "jitter free" data stream to send to the chip.

[barrows]

21 minutes ago, mansr said:

Are you suggesting the DAC should look for silence and pad or reduce it slightly if the buffer is running low or getting full? What if a suitable gap doesn't turn up in time? I would not want a DAC incapable of operating indefinitely.

I am not suggesting what a DAC "should" or "should" not do.  I am suggesting how the Ayre asynchronous SPDIF input works.  The approach they use is proprietary, and patent pending, so they think it is unique enough to go through the patent process (anyone who has gone through this knows what I refer to).

I do not know exactly when the buffer chooses to reset, but from asking Ariel Brown (Ayre lead engineer) directly, in person, whether there is any PLL involved he said no, and told me that the buffer is managed by software in terms of overruns and under runs, exactly when it resets is a detail I do not know the answer to.  And further, their DACs use a fixed frequency master clock, with no DDS, or any other way to adjust clock speed.  Every bit of information I have on this input suggests that it is a true asynchronous approach.

 

With this approach I would expect there to be a "problem" (perhaps a brief dropout), if one tried to play a music file of infinite length (at some point the buffer would have to over run or under run), but music is not typically infinite in length.  I do know the size of the buffer used, but I suspect that this design detail is something that Ayre might consider proprietary, so I will respect that suspicion.

 

Anyway, perhaps we should get back to Sonore Rendu discussions here!  anyone else interested in SPDIF/AES output Rendus?