Jump to content
IGNORED

Rendu with ANY output other than USB


Recommended Posts

22 minutes ago, vortecjr said:

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

 

Absolutely no collaboration between Rob and Ted.

 

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

 

So yes, all sound like they're doing a similar thing at a high level but as I mentioned, all probably slightly different in the nitty gritty details.

Link to comment
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.

Link to comment
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.

Link to comment
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.   

SO/ROON/HQPe: DSD 512-Sonore opticalModuleDeluxe-Signature Rendu optical with Well Tempered Clock--DIY DSC-2 DAC with SC Pure Clock--DIY Purifi Amplifier-Focus Audio FS888 speakers-JL E 112 sub-Nordost Tyr USB, DIY EventHorizon AC cables, Iconoclast XLR & speaker cables, Synergistic Purple Fuses, Spacetime system clarifiers.  ISOAcoustics Oreas footers.                                                       

                                                                                           SONORE computer audio

Link to comment
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.

SO/ROON/HQPe: DSD 512-Sonore opticalModuleDeluxe-Signature Rendu optical with Well Tempered Clock--DIY DSC-2 DAC with SC Pure Clock--DIY Purifi Amplifier-Focus Audio FS888 speakers-JL E 112 sub-Nordost Tyr USB, DIY EventHorizon AC cables, Iconoclast XLR & speaker cables, Synergistic Purple Fuses, Spacetime system clarifiers.  ISOAcoustics Oreas footers.                                                       

                                                                                           SONORE computer audio

Link to comment
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.

SO/ROON/HQPe: DSD 512-Sonore opticalModuleDeluxe-Signature Rendu optical with Well Tempered Clock--DIY DSC-2 DAC with SC Pure Clock--DIY Purifi Amplifier-Focus Audio FS888 speakers-JL E 112 sub-Nordost Tyr USB, DIY EventHorizon AC cables, Iconoclast XLR & speaker cables, Synergistic Purple Fuses, Spacetime system clarifiers.  ISOAcoustics Oreas footers.                                                       

                                                                                           SONORE computer audio

Link to comment
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.

Link to comment
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? 

SO/ROON/HQPe: DSD 512-Sonore opticalModuleDeluxe-Signature Rendu optical with Well Tempered Clock--DIY DSC-2 DAC with SC Pure Clock--DIY Purifi Amplifier-Focus Audio FS888 speakers-JL E 112 sub-Nordost Tyr USB, DIY EventHorizon AC cables, Iconoclast XLR & speaker cables, Synergistic Purple Fuses, Spacetime system clarifiers.  ISOAcoustics Oreas footers.                                                       

                                                                                           SONORE computer audio

Link to comment
10 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. 

 

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.

 

7 hours ago, barrows said:

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

 

Don't forget IIS... opticalRendu to IIS, that's the ticket! Don't even need a clock (IIS clock signals are ignored in the DS Dac).

Link to comment
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.

Link to comment
9 hours ago, barrows said:

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.

 

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

 

 

Link to comment
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.

Link to comment
13 minutes ago, mansr said:

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.

 

Extra info from Ted:

 

35281027_ScreenShot2019-04-12at10_07_29pm.png.594ca65bcffcf20085832986981cc223.png

Link to comment
5 minutes ago, Em2016 said:

Extra info from Ted:

 

35281027_ScreenShot2019-04-12at10_07_29pm.png.594ca65bcffcf20085832986981cc223.png

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.

Link to comment

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