TOPIC:

Curious if anyone A/B compared with your other DACS. Which other DACs did you compare with the 22DA?
Did you replace your DAC with the 22DA? Or did you keep your existing DAC?
Wondering how good the 22DA dac is.

Thanks!

Yes, I've measured DAC performance of DA-FP board.
Have a look at this forum thread.

Basically it seems to have a polarity inversion of the analogue XLR outputs, and also runs everything through it's asynchronous SRC which means it is not sample locked to your incoming digital audio.
It may not compare well against a Lynx Hilo, Lavry or DCS model obviously(!), but for the $75 it costs, it's pretty okay as a DAC.
The ESS Sabre ES9023 chipset which it uses (rated 112dB dynamic range) is used in quite a few commercial DACs costing a lot more.

Totally agreement with Richard.

The SRC realculates all incoming frequencies to the internal working frequency (@96kHz DDRC, @48kHz openDRC) which causes slightly timing irregularities and provides some filtering (from 44.1kHz->working frequency), but therefore free of aliasing or artificial sound.

The DA-FP produces a bit of noise- but less than AN-FP. The sound is hard to evaluate exactly. You cannot expect high end from an ES 9023 chipset in low cost electric environment, but it does fine in low setups. You get what you pay.

I personally clearly prefer using a good external DAC (Beresford Caiman MKII, including headphone output) driven by the DI-FP, over the DA-FP.

The asynchronous SRC really caused me a lot of headaches with the digital only OpenDRC-DI because I couldn't get a repeatable digital bounce through the machine without it removing or inserting a few odd extra samples here or there. Making the OpenDRC the master clock and slaving the digital playback to that was the best workaround, but it's almost impossible to run it as a 3 way stereo crossover into a common multichannel DAC which expects all incoming channels to be clocked the same, because there are three separate master clocks. That's why I had to buy the DA version and use their converters. Or otherwise I would need three identical external DACs, but even then they would go out of sync with each other if they reclocked the incoming digital signals from 3 separate master clock drift time bases.

I'm interested in any ways to bypass the built in SRC on the input board and feed digital IS2 or S/PDIF or something directly to the main MinSharc board, or is there an aftermarket board that can add external sync or woodcock facility?

Richard wrote:

The asynchronous SRC really caused me a lot of headaches with the digital only OpenDRC-DI because I couldn't get a repeatable digital bounce through the machine without it removing or inserting a few odd extra samples here or there.

Is it an audible problem? What is the error rate?

Yes, problems could be audible, depending on equipment setup, and how exactly the system is clocked (master vs slave machines, etc.)

I’ve measured the error rate as one sample glitch every 1.35 seconds…
(…which, over a three minute song, would be about 133 glitches!!!!!)

That indicates (to me) there is a discrepancy of +/- 0.0015432% in the recorded file’s absolute sample rate speed compared to the expected ideal 48000 Hz rate of the test file playback. *(I’ll have to explain this test methodology later!!!)

I noticed this because I was making comparison test recordings between source test WAV file vs recorded output through the OpenDRC processor and comparing the WAV files side by side in software, or as a transfer function in HOLM.

Most people would probably expect, in an ideal world, that if you played a 48KHz WAV file digitally through the OpenDRC-DI in blank default factory-bypass mode, that the output would be a perfect identical digital bit-for-bit clone, carbon copy of the input, wouldn’t you? You would certain want that, ideally, as a die-hard purist audiophile!
This is the premise I was testing.

In fact, it isn’t transparent at all – this is due to the Asynchronous Sample Rate Converter in the OpenDRC basically re-clocking all incoming digital audio to it’s own internal 48kHz crystal clock.

Besides adding a blanket of –125dBFS dither noise floor, you’ll also likely end up with greater or fewer total number of samples in your audio data stream depending on the timing speed differences between your digital source sample rate (even if rock solid 48000Hz clock) and the OpenDRC’s internal 48kHz crystal clock which over-rides your source clocking, and re-interpolates its own output data stream accordingly. This allows it to cater for all sorts of input sample rates or even varispeed playback without difficulty. If it then feeds a D/A converter its "48kHz" output, you’ll just hear audio playing in real-time without realising your EXACT sample rate has drifted, unless you can hear 0.0015% change in musical pitch (1/38th of a semitone!) But if OpenDRC machine’s "48kHz" digital data stream is captured and compared bit for bit with the "original 48kHz" source flie, side by side on computer screen in software, it will be seen to be time-stretched or shrunk depending on far out the 48kHz crystal clock actually is from the source clock. They might even both be fast or slow by the same error amount and ironically give you near perfect digital bounces! It’s an elusive problem to quantify and measure on different setups.

As a follow-up post, to explain what tests I did, and how I discovered these inconsistencies…

A long time ago, in my naïve blissful ignorance, I believed the OpenDRC-DI was a digital in – digital out black box which applied a predictable mathematical DSP process onto any digital audio I wanted to pass through it. I assumed “bypass” would mean “bypass”, and therefore AES/EBU input at 48kHz would give me back AES/EBU output at 48kHz, unchanged, the same as connecting my two XLR plugs together, albeit with some processor latency.

One day, I was happily importing rePhase filters and playing a 24 bit 48kHz test wav file sinewave sweep 1 Hz to 24,000Hz through the OpenDRC and recording its digital output, basically to double-check in the real world that nothing was clipping or distorting internally and that my rePhase filter was doing exactly what I expected and still removing the ultra low bass safely (with my chosen windowing function) down below where the generated red-line predicton was rather vague on the graph…

Anyway, I found all these glitches in the recorded WAV and had to work logically backwards to total bypass factory-reset conditions on the OpenDRC to try and isolate the cause of the glitches. Turned out to be the clocking of my playback / recording chain, which would have been okay if the OpenDRC truly was a digital in – digital out black box, as I thought, but the stark reality of it not working(!) taught me a hard lesson about taking things for granted, and eventually getting to the bottom of the problem uncovered, for me, all the headaches of going through an Asynchronous Sample Rate Converter when you’re trying to do digital domain bounces for repeatable test measurements.

Fast forward to now, and I realise there’s a stubborn little 48kHz crystal clock in there which you can’t bypass or externally sync to anything, so you’ve got to play ball with it, and let it dictate the rest of your digital clocking path. Annoying! - because going digitally through digital mixers (Yamaha 03D or Behringer X32) in a record / playback loop (such as recording a multi-channel mixdown digitally) I've always been able to choose to either use the mixer’s internal clock as master and slave the Tascam to that, or successfully use the Tascam MX2424 player / recorder as the master clock and slave the digital mixer and still not get glitches, but with OpenDRC, it’s always acting as a new master clock to anything that’s downstream of it, and it doesn’t follow (ignores) whatever clocking you feed into it.


*Test Methodology (from above post)

My test setup, in this case, using Tascam MX2424 digital multi-track 24 bit recorder / player to simultaneously playback the 24bit 48kHz test WAV file, sending AES/EBU audio as a straight digital pass through my OpenDRC-DI digital machine (old silver aluminium case version, serial no #202-2050, purchased January 2013) in factory bypass mode and simultaneously record the output AES/EBU audio back again onto the Tascam MX2424 as a new WAV file, for comparison test purposes. The WAV files can be imported to computer and compared side by side on screen at sample accuracy, revealing any errors, and a null cancellation test to see if they are identical or not, etc.

With the Tascam MX2424 player / recorder as the master clock on it’s own internal 48kHz clock, the OpenDRC stubbornly ignores it and generates a new internal crystal 48kHz rate of it’s own, which isn’t quite the exact same speed as the Tascam internal clock, so the Tascam’s input buffer does its best to hang on and match incoming samples to the recording buffer, until the buffer fills up and it has to drop one sample, or leave a gap, or whatever. End result is a hairline fracture in the audio, a tiny glitch spike, which you can visibly see in computer waveform spectral view! I measured these glitches as having a regular period of 1.35 seconds apart. At 48000Hz sample rate, that’s approx 1 sample out of every 64800 samples coming unstuck due to the clocks drifting, and that’s 0.0015432% timing error.
The recorded WAV vs original test WAV flles look roughly identical but recorded one has 1 sample glitches every 1.35 seconds, and a blanket of –125dBFS hiss from the S.R.C. dither, but they are forced to stay “in sync” all the way through (5 minutes total) because the recorder is dropping a sample whenever it has to.

I also tried same test with Apogee PSX100 converter as master clock (more stable reference with only 22 picosecond jitter) and Tascam MX2424 as wordclock slave to Apogee, and again the glitches are the same, because of the OpenDRC in the digital pipeline.

Solution to make the glitches go away, is to recognise the OpenDRC-DI as the master clock for the playback & recording, so set the Tascam MX2424 as slave to the AES/EBU input it receives from the OpenDRC-DI, and it simultaneously outputs playback at this rate also which the OpenDRC-DI subsequently receives and re-samples through its S.R.C., although this time it keeps pace with it’s own crystal clock! There is still about 269 samples of round trip latency, but there are no glitches in the audio.

BOTTOM LINE
If you can make the OpenDRC act as system master clock, then slave your digital playback to it, then you can achieve almost bit-for-bit copy digital reproduction through it. Hooray!
However, if your digital playback is locked to another master clock elsewhere (yep, even the most expensive Antelope 10MX atomic master clock or whatever!), if referenced downstream after the OpenDRC, you’ll get nasty audible / visible glitches as the clocks drift apart from each other (even though the downstream clock is providing the master clock reference for the audio you’re sending digitally INTO the OpenDRC-DI, as it was in my Tascam case to start with!), or if reference locked upstream before the OpenDRC, the audio will be re-clocked anyway through the asynchronous SRC to a new rate (nominal 48kHz) and you’ll get slightly elastic (stretched or shrunk) audio data stream which doesn’t correlate back in sync to your original file in a side-by-side comparison, but won’t have sharp audible glitches in it.

The most common case for everybody would be CD playback...
Linear chain of equipment in series. CD player is master clock, feeding 44.1kHz source into OpenDRC, which gets automatically upsampled into the MHz range by the asynchronous S.R.C., and re-interpolated and downsampled to the nearest 48kHz sample given from the internal 48kHz crystal clock and lowpassed / anti-aliased to feed smooth data stream at 48kHz to the FIR filter and DSP processes and ultimate audio output, via downsteam DAC, amplifer and loudspeakers.
If you were to rip a CD at 44.1kHz and use computer to convert that WAV file to 48kHz and compare it to the 48kHz recorded output from OpenDRC digital bounce copy, it would not match sample accurate in timing over the whole duration of a 4 minute song, I’d bet.

It’s a pity CD players aren’t 48kHz because that would make things easier. Going through a sample rate change 44.1 > 48 tends to obscure the file-length comparison discrepancy, maybe that’s why more people haven’t reported the fault here on this forum. It’s not too easy to spot, unless you test with 48kHz files directly, then it’s more obvious.
You could use a DVD soundtrack perhaps, or just play any independent 48KHz source through OpenDRC-DI in bypass and record the digital output and compare them side-by-side to see for yourself.

Interesting post Richard!

Richard wrote:

My test setup, in this case, using Tascam MX2424 digital multi-track 24 bit recorder / player to simultaneously playback the 24bit 48kHz test WAV file, sending AES/EBU audio as a straight digital pass through my OpenDRC-DI digital machine (old silver aluminium case version, serial no #202-2050, purchased January 2013) in factory bypass mode and simultaneously record the output AES/EBU audio back again onto the Tascam MX2424 as a new WAV file, for comparison test purposes.

In this case the tascam uses the same clock acting both as a playing and recording device, which causes the glitch. But it you used another device for recording (as in a real world scenario, source --> open-DRC-DI --> DAC) wouldn't it be able to correctly sync with the input signal?

Wow, deep analysis, Richard.

From my experience, I do not hear glitches or gaps in my chain (player->OpenDRC->DAC, each having its own clock). One would expect every SPDIF input to recognise the frequency of the incoming signal, to buffer 1 or 2 samples and to synchronise with the speed to avoid any gaps or glitches. ?? Is not??

But there is a little difference between 44.1 and 48kHz input. You may hear the converting and filtering from 44.1 kHz and the not 100% accourate timing.

planetti wrote:

From my experience, I do not hear glitches or gaps in my chain (player->OpenDRC->DAC).

Imagine photocopying a page from a book.
Photocopier is set 1:1 ratio 100% size.
You come away a sheet of A4 paper and it looks perfectly okay to you.
No problem is visible to the eye. Seems perfect.
BUT if you photocopied onto a sheet of acetate clear film transparency, and laid the transparency copy very carefully over top of the original book page, and look closely, you might see the image was stretched or warped slightly horizontally or vertically and they weren’t exactly the same size. Not exactly perfect 100% copy.

That’s the problem.

You cannot see very subtle warping if you only look at the photocopy sheet alone.

And likewise, in a linear chain, series connection (Player >>> OpenDRC >>> DAC) of course you cannot hear very subtle warping, of re-quantizing and re-clocking digital audio stream into completely new interpolated sample values at a slightly different time-base clock sample rate, because the new interpolated output is still a smooth flowing continuous digital audio stream with no glitches or gaps. That’s how asynchronous SRC works. Your DAC which you listen through is being fed a smooth flowing continuous digital audio stream, so there’s no glitches audible. Your DAC output is your photocopied sheet of A4 paper which looks and sounds okay.

But it isn’t the same as original.
It’s fractionally time-stretched or warped, just like a photocopy.

You’ll need to COMPARE to the original to observe the extent of stretch and warp.

Even if player source was also nominal 48000Hz sample rate, over a 3 or 4 minute song, its entire duration will now be composed by a few hundred(?) more or fewer samples than the original file’s samples, so the input vs output won’t be in sample-accurate sync anymore if compared together under the SAME clock timing reference (eg. a computer screen WAV file view.)

Viewed separately, the audio output (photocopy) might appear okay and glitch free, but by careful comparison to original we do observe slight error in processing.

planetti wrote:

One would expect every S/PDIF input to recognise the frequency of the incoming signal, to buffer 1 or 2 samples and to synchronise with the speed to avoid any gaps or glitches. ?? Is not??

Sorry dude, but you can’t really "expect" the input "to synchronise" when using an asynchronous sample rate converter!

Asynchronous means it works without synchronising – ie. it’s specifically designed not to!
OpenDRC and many other common devices (eg. Behringer UltraDrive DCX2496), use asynchronous SRC method as a utilitarian approach for dealing with numerous different sample rates and tolerating speed variation and unsteady clocks. etc.

Sample data values are first upsampled by a huge multiplying factor up to maybe 50GHz sample rate, by an interpolator which fills in extra data values inbetween the original samples with a zero-order hold function allowing them to describe almost continuous sample data values for any arbitrary time, which can then be decimated back by downsampling at the new desired output sample rate, as governed by the SRC internal clock, to generate a smooth output stream with appropriately interpolated sample values.

The input clock is NOT sample-linked or directly correlated to output clock in any way. If the player’s sample rate actually varies and speeds up very slightly, the OpenDRC doesn’t.
It won’t recognise source clock freq and automatically slave-lock or syncro-mesh itself to it, rather it just says, "Talk to the hand!" and sticks stubbornly to its own internal crystal clock timekeeping.
Player’s original source sample clock time-base is ignored.

In a basic linear chain, equipment connected in series…



Sadly, this method does force all audio passing through to be at the mercy of the master clock in the OpenDRC which maybe isn’t an ultra low jitter fantastic spec...

Some equipment avoids the asynchronous SRC method.
Doing sample-rate-convertion of WAV files offline using computer software typically uses a mathematical synchronous method.
You can, in fact, go shopping and buy yourself a perfectly synchronous, fixed- ratio digital sample rate converter, as outboard rack device, such as the Weiss SFC2 if you wish, and achieve precise sample value outputs mathematically calculated from the input samples, with the output clock time-base extracted from the input clock, multiplied by a fixed ratio. This is how things ought to be done, in an ideal world, and because Weiss retails at only $5095, it makes a perfect little stocking-filler for Christmas!!!

However, while not everyone employs asynchronous SRC method, if you want to benefit from OpenDRC's lovely 6144 tap convolution power, it’s a price you'll have to pay with this hardware.

I would love to see MiniDSP add an external wordclock input, or a way to bypass the SRC and slave the machine directly to the input AES/EBU or S/PDIF clock source!


The only reason I was able to actually produce glitches in my recorded WAVs was using another setup - not linear chain - but a round loop signal flow - where the player and recorder were one and the same machine (Tascam MX2424) under its own master clock, forcing the recording to run in sync with the source playback, which exposed the relative drift of the OpenDRC’s clock, as a glitch every time it exceeded the input buffer capacity.

pos wrote:

In this case the Tascam uses the same clock acting both as a playing and recording device, which causes the glitch.

Strictly speaking, no, the glitch wasn’t the Tascam’s fault. It can happily playback and record simultaneously under it’s own master clock obviously. The master clock governs the speed everything runs at. If the Tascam is the only master clock, it is perfectly stable, or it can slave to something else. You only really get problems if audio recording’s input signal is routed from it’s own output channel causing a feedback loop.
It also CAN send digital output to digital input loop to another channel and re-record it - a straight XLR patch cable AES/EBU introduces about 11 samples of latency, whereas going through an active digital device like digital mixer introduces considerably more, but as long as the master clock sample rate’s precise clock SPEED remains unaltered through the entire signal path it shouldn’t have any reason to lose sync, or overload the buffer. Recorded latency delay, per se, is quite normal.

Tascam was simply tripped up by the OpenDRC having a totally different internal clock, ostensibly not running at the same speed, hence the glitches. I wasn't expecting that so it caught me out too, but now I know better. I detailed how I first discovered this problem and then avoided it by making the OpenDRC the master clock and Tascam the slave in the previous post.

pos wrote:

But if you used another device for recording (as in a real world scenario, source --> open-DRC-DI --> DAC) wouldn't it be able to correctly sync with the input signal?

No, they still won't be in correct sample-accurate sync. If you compare them!
I already tried this, using a totally independent 24 bit playback device (Blu-ray player with DVD-Video disc burned with 24 bit 48kHz linear PCM audio soundtrack for my test sweeps) going S/PDIF through OpenDRC-DI, recorded AES/EBU to Tascam MX2424, and it worked without any glitches, but the warping and time-stretching was still noticeable when you compare the original WAV with the recorded WAV on computer, because all audio going through has still been independently re-clocked by the asynchronous SRC, just the same as described and illustrated above.

THEREFORE it follows that if you have a test sweep file and want to record it's transfer function processed through, say, a rePhase filter FIR convolution, you cannot expect the recorded wav to be in sample sync with your original computer test WAV file, so it won't work! But what you can do instead, is play one mono test file on both left and right channels, applying FIR convolution process to left channel, and bypass on right channel - or include 64ms delay to align with FIR impulse! - and record both channels as stereo or two mono WAVs. This way, you'll capture your FIR process plus a new version of the reference test file with any clock drift or warping occuring equally to both of them, so they can be truly compared side-by-side on a level playing field, and will import okay as a transfer function into HOLM.
Of course, the new test file copy on right channel will also now have -125dBFS dither due to SRC process too.

If you try and reference from a test file WAV which doesn't have the same clocking as the OpenDRC recorded signal WAV, you may see inconsistencies.

For purist music playback, it's the same clock drift warping due to the SRC described above which always plagues your output, whether you're aware of it or not! You can’t win - not with a domestic CD player or iPod & digital dock source or whatever...

The only way to run 100% audiophile sample-accurate audio through OpenDRC-DI is to make it the primary master clock and slave everything else to it, then de-jitter afterwards in the DAC.

I'd never thought about it before but I guess if I put a DDRC-22D looped back to my soundcard (via SPDIF) the same issue might arise. I seem to recall doing that once with a miniDIGI but that was a while ago... The presence of word clock inputs on some digital gear makes a lot more sense to me now.

Richard wrote:

The only way to run 100% audiophile sample-accurate audio through OpenDRC-DI is to make it the primary master clock and slave everything else to it, then de-jitter afterwards in the DAC.

Richard,

of course you are right with respect to sample accurate playback beeing not possible with ASRC in the chain.

On the other hand what's the purpose of DSP systems like openDRC? Guess it's not sample accurate playback

Questions are: what does the ASRC to the signal in comparison to the other signal processing errors (IIR and FIR filters)? And what's the effect to the audio signal if there is some jitter in the intermediate stage of the chain (btw. did anyone really measure the jitter of the miniSharcs XO)?

Theoretically it might indeed be the ideal setup using one MCLK for the whole system however guess that would make the whole thing more complicated. Could be a support nightmare

kind regards, Daniel

Hi Curryman,

Funny old world...!
First we demand ruler flat amplitude response, and correct absolute polarity, then we demand flat linear phase response, and optimised impulse response, and then, still not satisfied with that, we demand 100% sample accurate playback, just to listen to whatever our favourite musicians did sixty years ago in a recording studio in the 1950's with primitive uncalibrated gear on analogue reel-to-reel tape.
No attempt to correct for the overwhelming transfer function veil of their recording chain – that’s historic colouration we want to enjoy for some reason – yet we wouldn't dream of using the same vintage mono speakers they used...!

curryman wrote:

What does the ASRC do to the signal in comparison to the other signal processing errors (IIR and FIR filters)?

I would say the FIR and IIR filters are completely user-controllable and therefore can be made predictable. Their "errors", eg. due to windowing functions, are a known element of filter design, which the user chooses to implement. So they are a wanted part of the signal processing - the raison d'être of this machine.. Whereas any ASRC applied to digital input that's already correct 48kHz sample rate is unwanted processing, which the user has no control over, or ability to bypass. It might be useful for 44.1kHz input, but it's a shame you can't bypass it when you don't need it.

ASRC doing any harm???

I think ASRC is more a technical obstacle if doing repeated tests under controlled conditions, which only rigorous master vs slave clocking discipline can circumvent.
It doesn’t really hurt domestic music playback, which is why it’s so commonplace.

Re-interpolating the data stream at a fractionally different sample rate doesn’t “stretch” the audio you’re hearing, if it’s being clocked out the D/A converter in real-time at the new rate defined by the ASRC clock. It’s still real-time playback, whatever the new sample rate is. Nobody can hear any difference between 48,001Hz and 47,999Hz sample rates, per se, so as long as the new sample rate is the same “nominal” rate, you’re not really being short-changed by the ASRC.
The –125dBFS dither noise floor is probably more annoying, but unless you’re listening above 125dBSPL peak, that won’t even register above 20 micropascal = 0dBSPL human hearing threshold, so isn’t a massive issue either.

curryman wrote:

What's the effect to the audio signal if there is some jitter in the intermediate stage of the chain? (btw. did anyone really measure the jitter of the miniSharc?)

Jitter
This alone is a massive subject!

I haven’t measured jitter figure for the OpenDRC clock, but I agree it will be a factor because any jitter variations between player’s input clock and ASRC crystal clock will be forever imprinted into the ASRC datastream’s re-interpolated sample values.

What jitter spec is required for perfect digital audio reproduction?

Considering music is the total Fourier sum of many audio frequencies, the signal rise time at maximum steepest gradient may approach nearly a squarewave!
Squarewaves can only be approximated in digital audio - albeit not with perfect vertical rise time, because of limited bandwidth 48kHz sample rate, so they have the same rise time as a 24kHz sinewave.

But just consider those numbers!
At 48kHz, one single sample interval (20.83 microseconds!) for the signal level to traverse 24 bit peak-to-peak dynamic range of 16,777,216 quantization levels - at most extreme case!
That means signal level dashes across each individual digital quantization level step in just 1.24176 picoseconds!!!!!!
That’s fast. Not much time to accurately measure it’s level to 24 bit precision.
You’d need a sampling clock that is absolutely pinpoint accurate timestamp to within 1.24176 picosconds jitter error window, to be able to state for certain that signal level was detected and measured within precision window of just one quantization level step size, and thus can accurately discriminate between such size differences for any imaginable audio program content, and thus honestly represent the exact signal amplitude value, defining it to the full limit of 24 bit resolution range, and achieve full 24 bit depth resolution across entire audio bandwidth.

NB. I should remark, this jitter spec is the extreme limit which applies for fullscale 24kHz sinewave (or square wave!) but if signal waveform isn't fullscale height, then it isn't being resolved to 24 bit precision anyway - it's losing some bit resolution, so doesn't require such tight jitter spec. At -48dBFS down below fullscale the signal is equivalent to 16 bit resolution after all. It's not crossing so many quantization levels due to its reduced amplitude, so given identical waveform frequency cycle period, the required jitter spec can be relaxed. It's therefore music's uppermost transient peaks which are the most corrupted by jitter. So if you're doing critcal listening tests for jitter make sure you use music that is peaking near fullscale, which most commercial pop music does!!! Exactly how much jitter can be tolerated or even perceived by an average listener is another question, and one that is open to subjective opinion. But, if we just want to define the "size of the ballpark" scale we're working with here - the upper performance ceiling needed to achieve theoretical 100% transparency, then digital audio theory requires us to assume worst case scenario, which is a fullscale 24kHz sinewave, which could indeed exist in digital audio, probably as a test signal.

One may calculate how little jitter is necessary for perfect resolution digital audio in theory.




Reality of the situation - converter's jitter spec is often much worse than ideal, so the actual max achievable bit resolution is often less than 24 bit, maybe a lot less. Also, because the higher frequency cycles will cross individual quantization steps faster, the jitter limits the resolution more for higher frequencies, whereas lower bass frequencies cycle amplitude more slowly, so can be resolved to greater depth, relatively speaking. The bit depth resolving power of a given converter limited by jitter follows a progressively decreasing curve from bass (best) down to treble (worst) and yet funnily enough, most converter manufacturer's don't advertise this in the brochure, but boast of "24 bit resolution" as if their device always carries 24 bits worth of useful audio data, rather than a big bunch of worthless random number values beyond about the 17th or 18th bit.

In the real world, you might get about 350 picoseconds from a good domestic CD player, which is okay for 16 bit 44.1kHz audio, whereas a good professional studio converter might give you around quoted 1ppm spec. Which is 1 part-per-million of 22 microsecond sample interval, ie. 22 picoseconds jitter, so the converter can honestly resolve full bandwidth audio to approx 20 bit depth, beyond which the smallest data values are compromised by random error noise due to jitter.

Some high-end converters can do better, Mytek claim 10 picoseconds, Antelope claim 0.02ppm = 0.45 picoseconds. I remember reading the Lynx Hilo was around 30 picoseconds, but I can’t find that website link anymore. Obviously converter sound quality depends greatly on analogue stage I/O quality too, so it’s not merely a jitter spec war. Some snake-oil audiophile hi-fi manufacturers even claim ridiculous jitter values down into the femtoseconds which are both very dubious, and theoretically proven unnecessary anyway.
1 picosecond jitter would be an ideal benchmark to aim for.

Sadly, I doubt the clock crystal inside DA-FP board comes anywhere close to theoretical ideal jitter spec.
Someone measured a MiniDSP USBStreamer on diyaudio and it had approx 2.7 nanoseconds jitter.
I would ideally like to be able to bypass the ASRC master clock altogether.

Curryman - thinking outside the box....?

Having designed the Curryman DAC , you must be an expert on this topic, so probably you could tell us if it’s maybe possible to retrofit any external wordclock sync input to the OpenDRC or MiniSHARC board directly???
Or maybe bypass the ASRC process in the DIGI-FP and DA-FP input boards?
Perhaps feeding clean 48kHz digital input via S/PDIF or I2S directly to the circuit board’s connectors, or force the ASRC crystal clock to slave to external sync reference from a digital input or wordclock somehow?

Looking at Twisted Pear Chronus Reclocking module or Metronome ASRC module gives me some hope that a third party circuit board solution may already exist somewhere(?) that could be adapted as a retrofit to work in the OpenDRC ecosystem, but I lack the electronics expertise to figure out how…!?

Excellent analysis, Richard.
But to be honest, I would be glad in the first step if the minisharc board would be able to reduce the working clock from 48khz to 44.1khz by setup switching, since this effect is more audable. But I2S slave functionality will be an important feature in the future.
But i am afraid that some wishes need basic layout changes...

After some more tests and experience in my setup I recognise a clear difference in musical timing (such as sound stage and precision) when feeding the ASRC of the OpenDRC with the origine 44.1kHz signals in comparison to the same signal upsampled (and therfore stabilised?) to 48kHz or 96kHz- the instruments then sound more precise and "stable on the stage" - with my setup.

Can anybody confirm this effect?