Rendu with ANY output other than USB

[mansr]

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.

[mansr]

10 hours 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!

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.

[mansr]

10 hours ago, barrows said:

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.

An S/PDIF source clock is permitted to be off by up to 1000 ppm. That's a drift of 3.6 s per hour against a perfect clock. The longest album I have is Wagner's Götterdämmerung at just over 4 hours. To assure uninterrupted playback of this, the DAC would have to pre-buffer at least 15 seconds. That's enough of a lag to be really annoying, especially if you use software volume control.

[mansr]

16 minutes ago, barrows said:

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

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.

[mansr]

2 minutes ago, fdreed said:

Apparently Ted Smith does not track the source clock at all, nor use ASRC -no edges are ever looked at nor timed. It is some sort of high frequency input sampling with pattern matching and data extraction, to a buffer I would presume.

Either you track the source, or you have drift and inevitably glitches. Pick your poison. Anyone claiming otherwise is mathematically provably telling porkies.

[mansr]

9 hours ago, Em2016 said:

All noted. But I was only referring to Ted's post..

 

That's how logic analysers with protocol decoding work. The method is trivially applicable to signals such as I2S where data is sampled on the clock edge. As long as you sample fast enough to discover the clock transition within the hold time of the data, you're fine. S/PDIF is trickier since the data is encoded as the presence or absence of a transition at the midpoint of each bit interval. In order to know where the midpoint is, and thus where to look for a transition, you must measure the (recent) edge interval. In a sense, this is a crude clock recovery without any jitter suppression at all. Regardless of the signal type, you end up with a fairly jittery data stream that needs to be re-clocked along with some method (variable clock or ASRC) to track the average rate. That is the hard part. How the data was extracted from the incoming signal isn't particularly relevant.

[mansr]

5 minutes ago, Em2016 said:

Extra info from Ted:

 

It may not use a recovered clock per se, but it has to do something to match the data rate of the source (unless periodic glitches are acceptable). If it's using a good ASRC or a variable clock synthesiser, a million-point FFT of course isn't going to show any jitter. That doesn't mean a different measurement won't show something. That said, I'd be surprised if there are any audible effects coupling through from the source.