Please do. My question is really; do one need a buffer of size 44 sample with the variations you see, or turning it around; what kind of incoming clock variation would fit into that buffer without needing a clock change?
Its not a jitter problem I suppose because a very high jitter figure would be say 10ns and a sample is 1/44100=22us so jitter easily consumed by a 3 sample (to be safe) buffer.
So remains clock deviations; 2 cases
a) very steady incoming clock but different to internal; DAM has to track until it is adjusted to incoming clock - then no more adjustment should be necessary - only jitter left to absorb i.e. no adjustment should be needed.
b) varying incoming clock around its center freq. but within incoming clocks "ppm"; so what ppm should be required to still not have to do a DAM clock adjustment i.e. the buffer swallows the frequency variation and no need for a DAM clock adjustment is at hand. Here of course a situation arises when incoming clock is drifting away for the first time and the point where it is "coming back" is not known - this would need a little bit of AI to find out and adopt to. But how a bad incoming clock will 44 sample digest before it needs to start follow the incoming clock...?
//
Its not a jitter problem I suppose because a very high jitter figure would be say 10ns and a sample is 1/44100=22us so jitter easily consumed by a 3 sample (to be safe) buffer.
So remains clock deviations; 2 cases
a) very steady incoming clock but different to internal; DAM has to track until it is adjusted to incoming clock - then no more adjustment should be necessary - only jitter left to absorb i.e. no adjustment should be needed.
b) varying incoming clock around its center freq. but within incoming clocks "ppm"; so what ppm should be required to still not have to do a DAM clock adjustment i.e. the buffer swallows the frequency variation and no need for a DAM clock adjustment is at hand. Here of course a situation arises when incoming clock is drifting away for the first time and the point where it is "coming back" is not known - this would need a little bit of AI to find out and adopt to. But how a bad incoming clock will 44 sample digest before it needs to start follow the incoming clock...?
//
And 1 more filter question... for now 🙂 May I configure non shared filters by taking away the 1004 and add filter data to the bank/fs in question? For a few filters - keeping it within the 256k total size...!
//
//
I am using Soeren's circuit using a MAX3280E and the DAM1021's TTL input. Sounds better than the S/PDIF input circuit shown in the DAM1021 manual. I made small PCBs for it.
Regarding the auto select: I added a connection for the selector, but I can't say if it made a difference. It might have made a small difference, but in this case I didn't record before - after files.
Total Stability for a XO specifies the maximum amount that the XO’s center frequency can drift from its nominal value over all operating conditions, which would typically include temperature stability, initial accuracy, aging for 20 yrs at 70 ºC, load pulling and VDD variation. Supply variation and load variation are less significant factors, typically in the 0.1 ppm range, and these stability factors are often omitted from XO datasheets.
Temperature stability characterizes the frequency deviation caused over the operating temperature range. Silicon labs specifies it as industrial temperature range (-40 to +85 ºC) not commercial temperature range.
Initial accuracy is frequency deviation from nominal frequency at room temperature.
Aging is slow gradual change of frequency with time. Silicon labs specifies aging as frequency change for 20yrs at 70ºC which is the strictest conditions in the marketing.
VDD variation stability is the frequency shift due to a power supply voltage change within spec in datasheet.
Load pulling stability is the frequency shift due to the load variation.
To be short, the total stability can be calculated as:
Total Stability = Initial accuracy + Temp stability (I-temp) + Aging (20 yr 70ºC) + VDD variation + Load pulling.
What's total stability of oscillator?
Temperature stability characterizes the frequency deviation caused over the operating temperature range. Silicon labs specifies it as industrial temperature range (-40 to +85 ºC) not commercial temperature range.
Initial accuracy is frequency deviation from nominal frequency at room temperature.
Aging is slow gradual change of frequency with time. Silicon labs specifies aging as frequency change for 20yrs at 70ºC which is the strictest conditions in the marketing.
VDD variation stability is the frequency shift due to a power supply voltage change within spec in datasheet.
Load pulling stability is the frequency shift due to the load variation.
To be short, the total stability can be calculated as:
Total Stability = Initial accuracy + Temp stability (I-temp) + Aging (20 yr 70ºC) + VDD variation + Load pulling.
What's total stability of oscillator?
So the given total stability denotes the absolute worst case, it is very likely much better at room temperature in a DAM1021 with a high quality DC supply.
The clocking in my system is much, much more stable than the corrections the DAM makes. Doing the loopback test with the same AD but a Lynx Aurora16 with syncrolock (their combination of PLL + crystal with advanced measuring and syncing) turned on the samples of the original and the converted file still align perfectly after several minutes.
The buffer size you actually need in this scenario for several minutes of audio is obviously a lot smaller than 1ms.
My guess would be that the DAM's correction is either way too coarse, so it overshoots/undershoots. Or the measurement of the actual average clock speed doesn't work well enough. Probably because it gets an insufficient sample size (too small time span).
The way the Aurora does it is to measure incoming clock over a longer period of time (ca. 1 minute) and progressively fine tune the re-generated clock to the average clock speed of the incoming clock.
My guess would be that, given the source clock is good, after a certain point only infrequent, minute adjustments are necessary.
The clocking in my system is much, much more stable than the corrections the DAM makes. Doing the loopback test with the same AD but a Lynx Aurora16 with syncrolock (their combination of PLL + crystal with advanced measuring and syncing) turned on the samples of the original and the converted file still align perfectly after several minutes.
The buffer size you actually need in this scenario for several minutes of audio is obviously a lot smaller than 1ms.
My guess would be that the DAM's correction is either way too coarse, so it overshoots/undershoots. Or the measurement of the actual average clock speed doesn't work well enough. Probably because it gets an insufficient sample size (too small time span).
The way the Aurora does it is to measure incoming clock over a longer period of time (ca. 1 minute) and progressively fine tune the re-generated clock to the average clock speed of the incoming clock.
My guess would be that, given the source clock is good, after a certain point only infrequent, minute adjustments are necessary.
I believe we all totally agree that this is what should be happening. I also believe Soekris did some great work for a budget conscious design (after having heard a tweaked one..) => the basis is there (more expensive & better models exist too), off course it can alwas be better and I also see Soekris continiously supporting this. Thank you Soekris and looking forward to the new firmware you talked about.
Some misc comments:
The long term stability (say hours, probably a few minutes are enought) is no issue for the listening experience, I think. In case you really need sub mHz accuracy for a session, and the "sub-hour" stability is fine, you could just calibrate your device in advance.
There are more efficient ways to measure frequency than "counting cycles". None of the "10-12 digits per second counters" runs a xxx-GHz clock.
For 99,999% of the users all that clock matching stuff is solving a self-created problem.
For these 99,999% there is no reason to provide the data in clocked/synced form for listening recordings. An async approach with one decent clock, clocking the DAC, would vaporize all that.
Nether the less it is a nice topic to think about what could be done, like cross word riddles, I thus will continue with it 🙂
The long term stability (say hours, probably a few minutes are enought) is no issue for the listening experience, I think. In case you really need sub mHz accuracy for a session, and the "sub-hour" stability is fine, you could just calibrate your device in advance.
There are more efficient ways to measure frequency than "counting cycles". None of the "10-12 digits per second counters" runs a xxx-GHz clock.
For 99,999% of the users all that clock matching stuff is solving a self-created problem.
For these 99,999% there is no reason to provide the data in clocked/synced form for listening recordings. An async approach with one decent clock, clocking the DAC, would vaporize all that.
Nether the less it is a nice topic to think about what could be done, like cross word riddles, I thus will continue with it 🙂
It's an issue for everyone using S/PDIF and AES/EBU inputs. That's hardly 0.0001 % of users.
My point is that it really shouldn't be a problem, adjustments well below the 1 sample (at 44,1khz) level should suffice. If not, your source's clock truly is garbage and then you should fix that first.
I find it more intuitive to argue in terms of period, i.e. the duration of one clock cycle.
Let f_s👎 be the frequency of the signal source clock at the n-th cycle, and f_i👎 the one of the internal clock. Moreover let p_s👎, p_i👎 be the respective periods.
If f_i👎-f_s👎=d👎*f_i👎, then for small d👎 we have approximately p_s👎-p_i👎=d👎*p_i👎.
The time deviation D(n_0...n_1) of the clocks in the interval n_0...n_1 is
D(n_0...n_1)= Sum_{n=n_0....n_1} p_s👎-p_i👎= Sum_{n=n_0....n_1} d👎*p_i👎.
If we assume that the internal clock is stable, i.e. p_i👎=p_i constant, This becomes
D(n_0...n_1)= p_i * Sum_{n=n_0....n_1} d👎.
As first illustration the trivial example of your case a), there the difference d👎 between the clocks is constant "d". So
D(n_0...n_1)= p_i *d*(n_1-n_0) - well that is obvious anyhow.
If the variation of d👎 is small from one sample to the next, The sum D(n_0...n_1) can be approximated by an integral, which might be easier to evaluate that the sum.
D(n_0...n_1) is the integral from t_0 to t_1 of d(t),
where the time points t_k are t_k= p_i*n_k.
Example: assume in your case b) that the variation of the incoming clock around the centre is of sinus form of frequency f, i.e.
d(t)=A sin(2 pi f t).
The maximal deviation D(n_0...n_1) is obtained by summing over a half cycle of d(t) (e.g. n_0=0, n_1= f_i/{2 f}, so t_1= 1/{2 f}). By the integral approximation we can evaluate this to D(n_0...n_1)=A/{pi f}, as the antiderivative of sin() is -cos().
Make this an even more concrete example. Let A=100 ppm and f=0.1Hz, i.e. he incoming clock oscillates around the internal clock as a sine in a period of 10 seconds and its maximal frequency deviation is 100ppm.
The the maximal deviation between the clocks is
A/{pi f}= 100ppm *10s/pi = 1ms/pi, so roughly a third of a millisecond.
Sorry that got a bit long and too explicit perhaps.
No, it was great - thanks. I pondered it but could not come up with the above problem math model. 0,3ms just fit into the half of 44 samples i.e. 0,48 ms so this *very* bad clock would still fit within the DAM PLL without adjustments.
So a period of 100sec instead of 10 would require a 3 ms buffer? I wonder what the variation on second/minute level looks like for a typical oscillator driving incoming data to a DAM over s/pdif - should be much better then 100ppm!
Si514 claims "0.026 ppb frequency tuning resolution" so its hard for this to be meaningful with a corresponding drift accuracy.
//
So a period of 100sec instead of 10 would require a 3 ms buffer? I wonder what the variation on second/minute level looks like for a typical oscillator driving incoming data to a DAM over s/pdif - should be much better then 100ppm!
Si514 claims "0.026 ppb frequency tuning resolution" so its hard for this to be meaningful with a corresponding drift accuracy.
//
Last edited:
Yes oscillation seems not to be the major problem, once the offset and drift are taken care of.
Yes, or a 1000ppm clock for 10.
So to me it looks like the clock change intensity (several/second to once per 10 seconds) seems uncalled for!? Or can you see a reason zfe?
//
//
The dam1021 currently adjust with a resolution of 1 Hz. If incoming samplerate isn't at whole Hz, which it probably isn't, then the clock will keep going up and down, trying to reach it....
OK.
But why in such a hurry to catch it? How much does 1 Hz eat out of the buffer? I suppose it depends if the incoming clock comes back or not... One need to learn its behaviour during a few minutes (?) in order to be cool about changing the Si I suppose...
Is this hunting why this multitone doesnt look to great in the "bass"? Other DACs keep the grass well trimmed also at 20 Hz. But it's not clear if maybe USB was used and if so it would be not due to hunting.
https://www.superbestaudiofriends.org/index.php?attachments/upload_2020-11-17_19-36-12-png.23884/
//
But why in such a hurry to catch it? How much does 1 Hz eat out of the buffer? I suppose it depends if the incoming clock comes back or not... One need to learn its behaviour during a few minutes (?) in order to be cool about changing the Si I suppose...
Is this hunting why this multitone doesnt look to great in the "bass"? Other DACs keep the grass well trimmed also at 20 Hz. But it's not clear if maybe USB was used and if so it would be not due to hunting.
https://www.superbestaudiofriends.org/index.php?attachments/upload_2020-11-17_19-36-12-png.23884/
//
OK re FFT window size. I couldn't fully digest the answer on the PLL - probably I did not understand it. Your upcoming alteration to the PLL - in the light if the discussion here recently - can you say something more about what to expect - both implementation and anticipated performance (tracking as well as clock frequency stability)?
//
//
Just to get an idea of the magnitudes...
I did some preliminary measurements of the bit-clock of the I2S output of an Ian Fifo, running at nominally 64*44,1kHz, (that is what gets measured by the DAM) with different of the common clocks.
After warmup the offset of the frequencies are at most a few 10Hz. The line fitted through the measurements of the frequencies has a slope of about a ppm per hour. The deviation of the measurements from the line is in the region of a few 10ppb for an hour or so.
With that slope the sample clock drift fills the DAM buffer in 1000s. The offset of the fitted line oscillates with small amplitude and worsens that time probably not significantly.
As the clock of the DAM is of equal stability as the incoming clock, half the above time to be on the safe side.
The bitclock output of Ians SPDIF breakout board, fed by Toslink, is equally good in terms of stability (at this point no reclocking with the "good clocks" was done, only Toslink converted to I2S).
So the major "corrections" that need to be done by the DAM is to fix the offset and to keep up with the drift. After the correction of the offset, only infrequent adjustments should be enough.
My measurements on the DAM itself get a bit delayed as I need to swap one or two parts of that Ian Fifo (I bought a used one), there is a issue with the data-line.
I did some preliminary measurements of the bit-clock of the I2S output of an Ian Fifo, running at nominally 64*44,1kHz, (that is what gets measured by the DAM) with different of the common clocks.
After warmup the offset of the frequencies are at most a few 10Hz. The line fitted through the measurements of the frequencies has a slope of about a ppm per hour. The deviation of the measurements from the line is in the region of a few 10ppb for an hour or so.
With that slope the sample clock drift fills the DAM buffer in 1000s. The offset of the fitted line oscillates with small amplitude and worsens that time probably not significantly.
As the clock of the DAM is of equal stability as the incoming clock, half the above time to be on the safe side.
The bitclock output of Ians SPDIF breakout board, fed by Toslink, is equally good in terms of stability (at this point no reclocking with the "good clocks" was done, only Toslink converted to I2S).
So the major "corrections" that need to be done by the DAM is to fix the offset and to keep up with the drift. After the correction of the offset, only infrequent adjustments should be enough.
My measurements on the DAM itself get a bit delayed as I need to swap one or two parts of that Ian Fifo (I bought a used one), there is a issue with the data-line.
Interesting! By 1000s I assume you have assumed half the 44 sample buffer as we have to start in the middle of the buffert? So if I interpret you correctly, one clock adjustment per, say, every 4 minutes would be necessary for a reasonably stable incoming clock? 1000s / 2 / 2 (if internal clock has opposite drift direction) = apprx. 4 minutes.
OK, you didn't use the Ian buffer board, just the IO board - so could only be better with improved clocks.
I hope that the PLL algo check the fill level of the buffer rather than tries to continuously estimate the clock drift/difference in Hz once the Fs is determined.
Thanks zfe!! Looking fwd to also some DAM measurements if you have a chance and will to do them.
//
OK, you didn't use the Ian buffer board, just the IO board - so could only be better with improved clocks.
I hope that the PLL algo check the fill level of the buffer rather than tries to continuously estimate the clock drift/difference in Hz once the Fs is determined.
Thanks zfe!! Looking fwd to also some DAM measurements if you have a chance and will to do them.
//
Last edited:
Ups I made an error in the calculation :-( I should use my own formula instead of hand-waving!
So after the offset is corrected, a drift with slope of 1ppm per hour says that d👎=n * 1ppm/{44100*3600} = 6n *10^{-15}.
Sum_{n=0....m} d👎 = 6*10^{-15}*(m+1)m/2 or roughly 3*10^{-15}* m^2.
So D(0...m)=p_i * 3*10^{-15}* m^2= 1/44 * 3*10^{-15} * m^2 milliseconds.
So D will be half a millisecond after m = sqrt(22*10^{15} /3)= 85*10^6 samples or 1900 seconds.
Well at least the magnitude is similar. I hope this time it is correct, but it is already late in the evening ...
So after the offset is corrected, a drift with slope of 1ppm per hour says that d👎=n * 1ppm/{44100*3600} = 6n *10^{-15}.
Sum_{n=0....m} d👎 = 6*10^{-15}*(m+1)m/2 or roughly 3*10^{-15}* m^2.
So D(0...m)=p_i * 3*10^{-15}* m^2= 1/44 * 3*10^{-15} * m^2 milliseconds.
So D will be half a millisecond after m = sqrt(22*10^{15} /3)= 85*10^6 samples or 1900 seconds.
Well at least the magnitude is similar. I hope this time it is correct, but it is already late in the evening ...