Home > General > Why is 80MHz Not Enough?

Why is 80MHz Not Enough?

October 18, 2011 Leave a comment Go to comments


I am going to speculate the reason why a Sabre32 DAC needs a 100 MHz clock to correctly handle sample rates of 352.8K and above.

Sabre32 oversamples the incoming data at 8X  before it is passed to the ASRC (the “jitter eliminator). In the ASRC, the data is re-sampled to a higher rate still [link].  The “final” sample rate -the rate coming out of the ASRC is entirely determined by the master clock, and it is fixed at MClk/64 [574]. Thus for the 100MHz Buffalo, the resampled rate is 1.5625 MHz and for the 80 MHz Buffalo, the resampled rate is 1.25 MHz [link]

Maximum sample rate supported by clock frequency

The maximum sample rate is the clock frequency divided by 64 because in one cycle there are 64 samples (32 per stereo channel)  that must be clocked by the system. There is also no reference of clock multiplication inside the Sabre32 DAC. Thus clock frequency divided by 64 should indeed be the maximum sample rate within the DAC that can be accurately clocked.

If we take a look at the tables below, we note that for some incoming higher sample rates, 8X is not possible because it exceeds what the clock can provide. For example, we know that the 80 MHz Buffalo can play 192K material with absolutely no problems. 8X oversampling of this sample rate results in an upsampled rate of 1536 KHz, far, far exceeding what the 80 MHz clock can provide

In such cases, I suspect that the oversampling switches down to 4X (Other DACs such as the WM8741 requires manual switching down of the oversampling when  higher incoming sample rates are used. I would assume Sabre32 does this automatically)

If we look at the 4X column for sample rates 352.8K and 384K we notice that:

  • For 80 MHz clock, the oversampled rate exceeds the maximum rate
  • For 100 MHz clock, the oversampled rate falls within the maximum rate

Thus 80 MHz is not sufficient for oversampled 352.8K and 384K material.

According to the designer of the DAC…

Dustin Forman, the designer of the Sabre DAC over at diyaudio:

Yes you can bypass the internal upsampler if you like. You can put data in at 8X. X can be up to 192k. So that means its possible to put data into the chip at 1.536MS/s. Now that would require a 98.304MHz bit clock (64*8*192k), but the chip will do it if your not worried about running those kinds of clocks and data on an audio board.

The above shows that in order to “move” all the bits of the incoming sample, we need a clock frequency of at least 64*8*FS. “8” is the oversampling, whether applied internally or external to the DAC. If we tabulate the data we get the following minimum clock frequencies:

This also shows that if 100 MHz is the maximum frequency specified for the DAC, then at some point the internal oversampling switches from 8X to 4X.  Because we also know that with an 80 MHz clock you can perfectly play 176.4K and 192K material, I suspect that the 8X to 4X transition happens at FS>96KHz.

The table also shows that an 80 MHz clock, frequencies up to 192K are supported and for a 100 MHz clock, all shown frequencies are supported.

Even higher frequencies

The datasheet specifies that the maximum sample rate that can be supported by the Sabre32 DAC is about 500KHz. If we keep oversampling the base 48KHz by whole numbers we get these frequencies and the required clock frequencies:

If the DAC can support up to 500 KHz sample rate and if we assume that the internal oversampling falls back to 4X at the higher sample rates, then we can speculate that the DAC has been designed for clock speeds of more than 100 MHz.

Over at diyaudio, “coris” has been trying higher than 100 MHz clocks with success. (The upper limit seems around 130MHz which coincides with the above observation). Coris seems to have settled at 125Mhz as being the top end of the clock frequency. This matches quite well with the specified Max Spec if our assumption is correct

About the clock oscillator…
I`ve been used that time an 133,3 Mhz oscillator. I personally noticed a huge improvement in the sound quality after changed that clock. Unfortunately, and even though the sound it self was very high in quality (perceptual point of view), I`ve noticed in the same time a kind of sparkling noise in the silence passages of recordings. This was happened only when a sound file was played (CD, SACD, or wav/FLAC, 192khz/24bit). In the pauses between tracks was no any noise. It is very possible that in this last case, was about a mute function which was ON… Anyway, I concluded that this is not acceptable. So I had to go down to 125Mhz clock frequency…
It still be a very good sound quality, not as high as at 133Mhz, but is very well for me. And no any noise at all now as before. I think to go even lower to 122,88Mhz clock frequency. This clock frequence match accurate (by 5 factor) ones of the usual samplings frequencies. I`m just waiting now to get my ordered oscillator and try this way.


If the hypothesis is correct, then there is no solution to playing 352.8K material except increasing the clock frequency. No matter what you do, if you apply internal oversampling, the resultant sample rate cannot be supported with an 80 MHz clock.

The data sheet for the Sabre32 DAC specifies the  system clock frequency requirement as follows: Serial Normal Mode: fc>192fs. For fs=352.8Khz then the fc>67.7376 MHz. The system clock in the original Buffalo II DAC is 80 Mhz which meets the specification with ample margin. In fact it has a margin of about of about 18% higher. So it should work fine with 352.8Khz audio material.

Data sheet may be wrong:

But wait a minute, 192/8=24 so perhaps this is the clock frequency requirement of the 24 bit  DAC, the ESS 9008.

Indeed the specified minimum clock frequency for the ESS 9008: 192fs. The maximum sample frequency for the 9008 is 192KHz. If we do the math, for a stereo bit depth of 2×24, 4x oversampling and 192KHz sample rate, we get 48x4x192K=36,864MHz. We see the use of 40Mhz clocks in the evaluation boards.

For the 9018, which was an upgrade from 24 bit to 32 bit, I believe the clock frequency must be >32×8=256 or 256fs. So for 352.8Khz then the fc>90.3168 MHz and for 384KHz material, then fc=98.304 Mhz (Note, this is again assuming that at the higher sample rates, the internal oversampling is reduced from 8x to 4x)

Solution for 80 MHz clock:

It has been shown that turning off the internal oversampling allows flawless playing of 352.8K material with a 80 MHz clock. 352.8K material is the same as oversampling 44.1K material at 8x. This falls well within the max sample rate that a 80 MHz clock can support. Register 17 controls the oversampling ON/OFF. The ASRC upsamples this frequency to a final 1.25 MHz. Should sound pretty good without oversampling.

I shall add oversampling ON/OFF to the next version of the code

  1. Bunpei
    October 18, 2011 at 12:36

    Good speculations!

    I used to have the same speculation before.

    On the other hand, in the past, there were two persons who told that they played 352.8 kHz/24 bit PCM sources with 80 MHz oscillator successfully without continuous hiss noise. One of them said the reason why we can’t play it with 80 MHz clock normally is that the bit clock signal of I2S is not clean enough. His understanding was that the description in the datasheet was correct.

    Currently, I have lost my interest on this topic because my standard setting is “synchronous master clock input from I2S” and “OSF OFF mode” for playing 352.8 kHz/24 bit PCM sources. No need for 80 MHz nor 100 MHz oscillator at the DAC side.
    In the case of the first generation of TPA Buffalo II with 80 MHz oscillator, we had no way to select “OSF OFF mode” and it was a severe problem. However, we have your Hifiduino and other Arduino solutions now. We can set the “OSF OFF mode” easily.

    • Russ White
      October 19, 2011 at 02:31

      You certainly can turn OSF off with Buf II. You would just need to use an external I2C controller or custom firmware. 🙂 We fully expected advanced users to do stuff like this.

      I do fully agree with you that in many cases synchronous clocks seem to work wonderfully. So in the end it is not really something worry over. Honestly we were aiming toward 192khz at the time we designed the Buffalo. In fact that is all we ever really expected people care much about. 🙂 Later when we found some people were using higher sample rates we increased clock speed because of reported success with the higher clock speed. We do our best to be responsive.

  2. BlogGeanDo
    October 18, 2011 at 13:59

    Hi Bunpei,

    Thank you for offering your thoughts. Your contributions make this hobby that much more fun :-).
    If you look at this post by Dustin: http://www.diyaudio.com/forums/digital-line-level/117238-ess-sabre-reference-dac-8-channel-128.html#post1740381

    “Yes you can bypass the internal upsampler if you like. You can put data in at 8X. X can be up to 192k. So that means its possible to put data into the chip at 1.536MS/s. Now that would require a 98.304MHz bit clock (64*8*192k), but the chip will do it if your not worried about running those kinds of clocks and data on an audio board.”

    This says that the clock frequency be 512*fs (for 8x), which means that for 256*fs for 4x. Now, if your bit-clock is coming in at 98.304MHz, you need a clock in the DAC side that can clock that frequency.

    Have you tried plying 352.8K with a 90.3168 MHz clock and oversampling on?

  3. Bunpei
    October 18, 2011 at 14:46

    BlogGeanDo :Have you tried plying 352.8K with a 90.3168 MHz clock and oversampling on?

    Chiaki and I have tried it just on “Synchronous Master Clock” condition. He created a modified version of FPGA program that is capable of generating 90.3168 MHz MCLK. In this configuration, he succeeded in playing DXD sources on “OSF=ON” mode setting “DPLL bandwidth parameter = No bandwidth”.

    • BlogGeanDo
      October 18, 2011 at 17:15

      Doesn’t that shows that the problem is related to “exceeding the maximum sample rate” rather than “quality of the bit clock”?.

      Additionally, the fact that you can use DPLL=no bandwidth also shows that synchronous master clock eliminates all jitter. On the other hand, this could also mean that the ASRC is in “bypass” mode. The TI SCRC has a manual bypass which only works if the input sample rate is the same as the output sample rate, which is also the case in the Sabre DAC

  4. October 18, 2011 at 19:29

    Glt, Good work. I have suspected the same as you and Bumpei for a while now.

    I must admit that I must have been mistaken when I did my initial testing with the 80mhz clock. I had been using experimental firmware and I may have inadvertently been using the 80mhz B2 with oversampling disabled when I achieved success. I also was flipping back and forth between DACs with different clocks installed (including some < 80mhz) and may have simply made a mistake when noting results.

    Lately when doing some further clock testing I have found hat it was not possible to get good results using 80mhz clock with oversampling on.

    I actually have not used a buffalo with an 80Mhz clock for quite a while now, so it took me some time to revisit the issue. Now that I have I find no source I try achieves good results at 80mhz and OS on. Not even my own.

    It could very well be an error in the datasheet. But it seems like a pretty basic metric, so if it turns out to be so I truly hope they correct it.

    I have asked Dustin to clarify this for us.


    • BlogGeanDo
      October 18, 2011 at 20:20

      Hi Russ, good to see you here 🙂 and thanks for your comments… Sometimes it is better to be tinkering in your head because you don’t have to inhale solder fumes. 🙂

      So yes, the only solution for the 80 MHz part is to turn OSF off for the highest sample rates. That also got me thinking about the ASRC:

      Does it matter (to sound quality) how “far away” you are from the final frequency for the incoming frequency into the ASRC? I know the “theory” says that it doesn’t matter whether your final frequency is an even multiple or not from the incoming frequency. But I can’t find the “Theory” for how close or how far…

  5. Russ White
    October 18, 2011 at 21:08

    I like to stop by from time to time. 🙂

    One thing I know for certain because Dustin told me, is that when the master clock and bit clock are truly synchronous the “jitter eliminator” is not doing anything at all. But in reality this makes no difference as long as the clock is good.

    The DPLL is completely inoperative in this case.

  6. Russ White
    October 18, 2011 at 21:33

    One other thing. I believe internal oversampling may simply be 4X for everything. I have an old email from Dustin where he explains this. I will see if I can dig it up.

  7. Branko
    October 18, 2011 at 21:39

    would it be goof to change the clock for a 80 MHz to 100 MHz. And how would you do it?


    • Russ White
      October 18, 2011 at 21:50

      Only if you plan on playing sample rates higher than 312.5Khz. 🙂 Otherwise leave it alone.

  8. Russ White
    October 18, 2011 at 21:40

    Here is what I have from Dustin. It is pretty basic information so I am sure he would not mind me sharing it(I left spelling intact):

    Hi Russ,

    63 taps, completely custom coeffieicnts. Can implement any coefficients in this mode. (asymetrical, phase warped(for thos who want no “pre ringing”….) Downside is there is only 64 taps. This is a 4x oversmapling filter. The first coefficient MUST be 0, the rest are the 63 programmable ones.


    Se regardless of frequency it is 4X

    • BlogGeanDo
      October 19, 2011 at 05:34

      4X across the board seems reasonable.

  9. October 19, 2011 at 11:54

    Yes I it very definitely is 4X. Never 8X. Dustin was simply stating that if you were going to use an external over sampler that was a suggested oversampling rate.

    Keep in mind the OSF in the ES9018 has two modes. Slow and fast. The slow roll-off is a pretty basic 4X oversampled FIR. The other (fast roll-off) is an “interpolated” filter.

    My inclination is to think that Dustin’s 8X input in non-OS mode recommendation is because to approximate the performance of the ES9018 fast roll-off filter you would need an 8X oversampling rate to do it conventionally. The fast roll-off filter in the ES9018 is not exactly conventional so it can do it in 4. It is a two stage filter.

    Really this is a product of a data sheet that needs more complete information and apparently more accurate information. 🙂

    I am sure Dustin and ESS will set things straight for us.

    • BlogGeanDo
      October 19, 2011 at 14:13

      If the OSF is bypassed for external oversampling, then what kind of filtering is applied in the DAC for anti-aliasing? The IIR filter? (but that is at ~ 2X)

      • October 19, 2011 at 14:32

        I believe that is correct. Though I will need to double check. I seem to recall in a conversation with Dustin that the IIR would be active even if the OSF is not. The OSF is actually designed to work in synergy with the IIR filter.

        One further update. I have to correct my previous information after digging out one further email from Dustin I see that the fast roll-off filter is technically 8X but what is strange is it appears to work even at what seems to be sample rates that would only work at 4X. This could very well be because it is an interpolation filter. Or perhaps it is internally disabled? One more thing I would like him to clarify for sure. 🙂

        This is the kind of thing that should really be in the datasheet.

  10. October 19, 2011 at 14:48

    To be more clear. According to Dustin the OSF is 4X oversampling in slow roll-off and 8X in fast roll-off. But this interpolating fast roll-off filter is a two stage process. So really what you have is 2X stage the reult of which is followed by a 4X stage to get the effective 8X. So it makes sense it still works. But I would still like a more thorough explanation from ESS. 🙂 I am no DSP guru myself.

  11. Bunpei
    October 19, 2011 at 15:00

    Oh, what rich comments given by Russ during my sleep and business time in Japan!
    The information presented here on this topic is extremely meaningful for me.
    Thank you very much, Russ and BlogGeanDo!

  12. October 19, 2011 at 15:06

    Ah yes here is what I have from Dustin back when I was first designing the Buf II:

    First my question:

    >>> I really really really hope 352.8khz PCM input will work ok with the
    >>> 80mhz clock. I await word on that anxiously. 🙂
    >>> If it does work will the FIR filter etc still work as designed?
    >>> Cheers!
    >>> Russ

    >>>> Hi Russ,
    >>>> Yes you can do this high without any issues.
    >>>> Dustin

    Further from another email.

    >> Hi Russ,
    >> Although not explicate, it says it all in the datasheet already, Just
    >> refer to that.
    >> IN the System clock part it mentions that the mclk needs to meet certain
    >> criteria. Based on this criteria it can handle about 520kHz sample rate
    >> with a 100MHz clock and using the OSF filters.

    So this is just one more reason one would believe it should work just fine with the OSF functioning the same in any case. 🙂


  13. BlogGeanDo
    October 19, 2011 at 16:08

    Hi Russ, thanks for all the info. While you are at it, bug him about that GUI based app to generate the filter coefficients. 🙂

  14. October 19, 2011 at 17:53

    I am having a discussion with Dustin right now. He is sticking to the datasheet value of 192fs. He is going to do some testing and more follow up. I am also going to setup some more thorough tests.

  15. October 19, 2011 at 18:25

    First thing on the agenda is to try to dig up a 80Mhz Buf II. 🙂

  16. October 19, 2011 at 18:41

    The real kicker here is that the demo board uses 40Khz and yet it works fine with 192Khz…

    One other note. 192fs is 3X 64fs(bit clock) so it actually works out fine number wise. It still seems a bit odd as a multiple.

    I am going to break out my original XMOS experiments and see if I can replicate the success I had a year or so ago at 80Mhz while I await more information from Dustin.

  17. October 19, 2011 at 18:41

    Oops I meant the demo board uses 40Mhz master clock and yet it work fine at 192khz.

  18. BlogGeanDo
    October 19, 2011 at 19:07

    Russ, thanks for all the time you are investing. (especially because this is not a matter of life or death :-)). But eagerly awaiting the results…

  19. October 19, 2011 at 19:29

    Its all part of the fun. 🙂

  20. Russ White
    October 19, 2011 at 22:14

    Ok i have an update!!

    I have spent my afternoon emailing Dustin and others as well as going back over old experiments including one of my first XMOS prototypes.

    I can confirm that the datasheet is 100% correct – but should IMO be updated with a note about high sample rates.

    You have to remember that the DAC was initially spec’d up to 192Khz. and 192fs master clock is the absolute minimum clock speed. As you get above 192Khz you are making the ASRC and DPLL work within much tighter timing margins then at 192Khz.

    What I found is that I could sometimes make things work just fine with 80Mhz clock, but not always. It is very definitely more finicky. Dustin and I agreed that in the end if your going to be doing 384Khz you really just need to give the DAC more error margin to work with to be safe.

    I have in front of me a Buf II with 80Mhz clock. And it plays a loop of 352.8Khz material with no issues at all from an XMOS prototype board. This is with OSF on. But when I try another USB player at 352.8khz no dice. I really can’t explain why… But if I switch to 100Mhz DAC all is well with both. So it seems to be somewhat hit or miss unless you give the DAC some room to adjust.

    So I am glad we went to the 100Mhz clock! 🙂 And I would simply suggest that anyone really wanting to do the super high sample rates asynchronously do the same (well anything more than 256fs). Keep in mind this has absolutely no bearing on 192Khz and below. I was reminded once again that while faster can be more solid, it not necessarily “better” in terms of final performance. This is because the final analog part of the DAC is completely tied to the master clock, and it has a range of frequencies which are ideal. This is something which ESS tested. 100Mhz is well with the good side of things.

    Dustin said that there needs to be *at least* a sample before the currently playing sample and a sample after in the pipe for the ASRC to work, this is why the minimum master clock is 3*64 = 192Fs. But he also said that more is definitely better! But once again because of minimum rise times you can only take the master clock up to a point. 100Mhz is a sweet spot we identified in earlier conversations but for slightly different reasons than we are talking about now.

    Now about the OSF. There is a lot to clear up here…

    The OSF in the Sabre32 is 8x FIR + 8x IIR for a total of 64x (This is why is needs 64Fs bitclock) so our math was a little out of whack. I am sorry for adding to the confusion for a while. 🙂 The master clock in no way needs to be 8 * bit clock to do 8X oversampling (as the ES9018 does in fast roll-off) or even 4X (slow roll off). When you disable the OSF both filters are gone. Sorry for the confusion there.

    So in the end, there is no good way for us to know exactly *why* yet, but I think it prudent to say it is indeed a fact that 80Mhz master clock is not high enough clock frequency for reliable operation at more than 350Khz asynchronously. I can say that I get absolutely rock solid performance with 100Mhz clock. My working theory is that this is all about the pipe (think buffer) into the ASRC.

    So is the datasheet wrong? I would say no, not really “wrong”, but it also should note that for very high sample rated the 192fs rule may not really apply. You should not live life near the absolute minimum(3 samples in the pipe). My gut feeling is that the extra sample “in the pipe” at 256+fs simply makes the ASRC work more consistently at uber high sample rates. Think of it as protection against under-run. ESS shared a lot of good info with me and I am sharing as much as I feel comfortable with and keep in mind I have to theorize where they (very understandably) won’t give me to full details. Dustin is a busy guy and I don’t like to waste his time. I also really like their stuff and want more of it. 🙂

    Man that was a lot… Thanks for bearing with me.


    • BlogGeanDo
      October 20, 2011 at 06:26

      Well, there is no way to clock 352.8 samples at 64 bit per sample if overclocked at 4x with an 80 MHz clock. the math is very simple

  21. Russ White
    October 19, 2011 at 22:41

    Sorry quick correction on the above. The IIR remains active when OSF is turned off – only the FIR is disabled. I was confusing the point of two emails.

  22. October 20, 2011 at 11:52

    BlogGeanDo :
    Well, there is no way to clock 352.8 samples at 64 bit per sample if overclocked at 4x with an 80 MHz clock. the math is very simple

    IO am not sure I am following you there.

    384000 * 64 * 4 = 98304000 = 98.203Mhz

    Where 64 is the bit clock required.

    Which is the same as saying a master clock of 256fs for 384Khz.

    This is why I have settled on a clock rate of 256fs. This should leave 4 samples in the pipeline instead of only the minimum 3 at 192fs.

    Now imagine you only have a 192khz source at the same master clock. How many samples in the pipe now? 🙂


  23. October 20, 2011 at 11:55

    What I am saying is I agree with BTW, I just was not sure where you were getting the 4X number. As 3X is all that *should* be required.

  24. September 14, 2016 at 15:50

    this site

  25. September 14, 2016 at 16:07

    New Jersey online casinos

  26. September 14, 2016 at 17:30

    teeth whitening cheap

  27. September 14, 2016 at 17:44

    learn more here

  28. September 14, 2016 at 18:21

    mulberry alexa oversized

  1. January 28, 2012 at 23:31

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s