Home > TEST > Sabre32 DAC Unlocks: The Shielding Factor

Sabre32 DAC Unlocks: The Shielding Factor

I have effectively cut jitter in half!(?)

Shielding the DAC virtually eliminated the unlocks (with DPLL setting at “LOW”)

After shielding the DAC with a proper case, I ran the test for 24 hours straight, during which there was a lot of activity at home. Result: I got only two unlocks during the 24 hour period. I will repeat the test again to confirm these results, but this is very good news and has made this simple test tool incredibly useful for tracking down potential sources for noise and interference affecting the degree of  jitter rejection capability of the Buffalo/Sabre32 DAC. I can now set the DPLL bandwidth to “LOW” and thus increasing jitter rejection 2X (see background section)

Just for comparisons, this is the data I got prior to providing proper shielding to the DAC (and with only 19 hours of measurements)

I was very surprised to see that shielding the DAC yields such improvement or that the DAC is susceptible to airborne noise (RFI/EMI) and interference to such an extent.

In any case, the results gives validity to board level shields as implemented by some manufacturers as can be seen below in their Anedio 2 DAC (photo from head-fi)

Other factors to consider: Perhaps the casing configuration I used separating the power and everything else from the Buffalo II board, also contributes to this improvement. Perhaps even affixing the AVCC power module under the board (thus being shield by the GND plane) is also a contributing factor.


The Sabre32 DAC has a variable DPLL bandwidth setting which allows adjusting the amount of jitter filtered (or rejected) from the input signal. The (minimum) bandwidth setting depends on the input format (spdif or I2S), the sample rate of the incoming signal and also whether or not the DAC is cold (as in starting up).

While the Sabre32 allows the adjusting of the DPLL bandwidth, there is a point at which the DPLL can no longer lock to the signal. It has been widely reported that for 44/1 Khz sample rate I2S, setting the bandwidth to “LOWEST” will result in unlocks. Users in Japan have reported that the “minimum” (no unlocks) setting for 44.1Khz is “MID-LOW” which is two notches above “LOWEST”. This is the setting that I have been able to achieve with my own setup.

The Sabre32 DAC has the following available settings for the DPLL bandwidth: LOWEST-> LOW-> MID-LOW-> MID-> MID-HIGH-> HIGH-> HIGHEST-> BEST. Each step represent a doubling the bandwidth value. Thus BEST has a bandwidth value that is 128x the value of LOWEST.  Using the “BEST” setting will allow locking into the incoming signal  independently of the aforementioned factors of sample rate, format and whether the DAC is cold or warmed up. Using LOWEST results in the maximum jitter rejection capability the DAC was designed for.

According to the designer of the DAC [link] [link]:

… the performance will get worse as to set the bandwidth higher and higher, since the jitter attenuation is reduced as you open up the DPLL as it were.

…If you choose higher bandwidth setting, the DPLL locks faster but lets more jitter through. Your tradeoff.

I suspect that most (if not all) implementations of the Sabre32 DAC ship with the DPLL setting set at “BEST” because you cannot afford to experience any unlocks on a shipping product. However, in a DIY environment, you can experiment with the different values for the DPLL bandwidth and see the effect.

Thus, if one could lower the DPLL setting from “MID-LOW” to “LOW“, then one could decrease the bandwidth by a factor of two and double the jitter rejection capability of the DAC.

Next: figure out what it takes to use “LOWEST”

Note: see the earlier posts for the full context of these results

  1. Bunpei
    March 12, 2012 at 10:50

    I always read your blog articles and find them very interesting and valuable.
    However, I have one thing to be made clear on this topic.

    You said in your post;
    … and interference affecting the jitter rejection capability of the Buffalo/Sabre32 DAC. I can now set the DPLL bandwidth to “LOW” and thus increasing jitter rejection 2X …

    According to my understanding on “jitter reduction” functionality of ES9108 DAC chip, I’m afraid that your use of the term “jitter rejection” is not suitable.
    You have been concentrating on eliminating “unlock events” in your live production environment. The unlock event is just one unfavorable result of “DPLL lock operation” that the DAC chip essentially performs for decoding incoming serial audio data.
    On the other hand, I interpret “jitter reduction” is an optional correction method for re-calculating audio data by interpolation. I understand that the functionality is fully described in U.S. Patent 7,330,138 B2, “ASYNCHRONOUS SAMPLE RATE CORRECTION BY TIME DOMAIN INTERPOLATION”, Feb. 12, 2008.
    You can turn off the “jitter reduction” by changing Register #10, [2]: JITTER_REDUCTION_ENABLE. I think it might be interesting if you compare your previous measurement to the one where the jitter reduction is “Bypassed and stopped”. My anticipation is ENABLE/DISABLE of “jitter reduction” will have nothing to do with “UNLOCK” issues.
    You may ask me why you don’t do it by yourself. In my case, I only use a synchronous master clocking method these days. Therefore, I am free from unlocking events anymore even on I2S 352.8kHz/24bit and DSD256(11.2896MHz) with DPLL bandwidth setting, LOWEST.

    • BlogGeanDo
      March 12, 2012 at 14:13

      Hello Bunpei, as always thanks for visiting and sharing your knowledge. I also enjoy reading your contributions in the different audio boards.
      I agree with you on the use of terminology, and I have corrected the post to say “degree of jitter rejection” (which is afforded by the dpll settings in the chip). According to the literature out there, the effect of lowering the bandwidth of a PLL is to reject more jitter at the expense of locking time. Thus if you reduce the bandwidth setting, more jitter will be rejected from the incoming signal. The other part of course is the ASRC in the chip.
      I agree with you that one can bypass the ASRC with a synchronous clock, then there will be no more unlocks; but it requires modifying the Buffalo board to turn off the on-board clock and feed the external synchronous clock. Eventually I might do that, but right now I am exploring the maximum potential of the DAC as the designers “intended it to operate” (that is using the internal ASRC). Besides, the Crystek clock in the Buffalo board is the best clock I have, so it doesn’t feel good to disable it 🙂

      I think while the clock is asynchronous, the jitter eliminator (the ASRC) cannot be bypassed and turning ON/OFF jitter elimination with the register does not do anything. I mean, if you don’t have an incoming clock, the data has to be clocked by the ASRC. There is no other choice

  2. March 14, 2012 at 20:19

    Thanks for your observations… I’m incorporating appropriate defaults into our version of the HiFiDUINO code, and designing a grounding shield for the BIII.

    Our coding is coming along well!

    I am using a different power supply to provide 5.25V and am waiting for this new board to come in. I was having troubles with getting a Placid HD to give me 0.8A (needed when switching from 2-8 channel mode). Once that is built, we’ll be able to have some fun with the code!

    • BlogGeanDo
      March 15, 2012 at 05:25

      Looking forward to seeing the new code

  3. March 15, 2012 at 06:08

    This looks very interesting – have you tried putting ferrite beads on the longer interconnects to your DAC? I find that cables are the no.1 way for interference to be picked up so I treat them before going for shielding of circuitry. Here’s a ferrite bead type number you could try – http://parts.digikey.com/1/parts/1715063-ferrite-chip-1000-ohm-1-5a-0805-mpz2012s102a.html

  4. BlogGeanDo
    March 15, 2012 at 19:08

    Hi Richard,

    The longer interconnect is the USB cable, now that the USB-I2S interface is inside the box and the wires to the DAC are very short. I was thinking of using an NVE isolator for the I2S lines. I think I have a “shielded” USB cable somewhere (the one with the metallic braid). Thanks for the link.

  5. March 18, 2012 at 01:12

    What about the power supply wires? And does the DAC feed headphones or go off into a preamp somewhere? My hypothesis would be its your external wiring which is picking up (or just conducting from elsewhere) the noise which unlocks your PLL.

    • BlogGeanDo
      March 18, 2012 at 06:07

      Hi Richard, The DAC feeds the amp straight. The power for the PC (laptop), the DAC and the AMP all come from a Monster Cable Power conditioner. The cables are short and they all have ferrite beads at the end of the cables. Except for the laptop supply, the Amp and the DAC have EMI/RFI filters at the entry plug. I have also used shielded cables for the power cords. However, it would be a good idea to revisit the power wiring. Perhaps having everything integrated inside a single case with a single power cable would be a good idea…

  6. September 14, 2016 at 17:06

    can take flagyl bactrim together metronidazole indications usage flagyl s giardia dosage metronidazole gel precautions taking metronidazole 400mg pregnant what is metronidazole good for can you get metronidazole over counter metronidazole ascaris trichom

  7. September 14, 2016 at 17:27

    Cuban Cigars

  8. September 14, 2016 at 18:30

    Courier Services in India

  9. September 14, 2016 at 18:55

    restaurants in yarm

  1. No trackbacks yet.

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