Home > TEST > Sabre32 DAC I2S: Further Experiments

Sabre32 DAC I2S: Further Experiments

January 14, 2011 Leave a comment Go to comments

As you may know, the implementation of the Sabre32 DAC I am using is the Buffalo II DAC. However, I believe these observations apply to the Sabre32 DAC chip in general as there are other reports indicating similar behavior but with different implementation.


I rebuilt my trusty OPUS receiver board and LCDPS supply. The OPUS receiver board is based on the Wolfson WM 8804 SPDIF transceiver chip. It boasts 50 ps period intrinsic jitter (In the photo, it is the module in the middle on the white wood stripe). In fact some implementations use the WM 8804 as a signal conditioner (and jitter reducer) for spdif signals.

I connected the spdif output of the Musiland 01 MINI to the receiver board and the I2S output of the receiver board to Buffalo II. I wanted to test the different DPLL bandwidth settings on this source. Specifically I wanted to know if Buffalo could lock onto an incoming I2S signal with the DPLL bandwidth set to “lowest”.


The  behavior of the DPLL setting with the OPUS/WM8804 receiver board is exactly the same as with the Musiland 01 MINI board.

Just like with the Musiland board, I was able to eliminate most of the dropouts by setting the DPLL bandwidth to “Medium-Low”.

Additionally, like when using the Musiland board, , the dropouts are much worse, when the DAC is first powered on. As the DAC “warms up”, the number of dropouts becomes smaller until reaching a steady state (about 15 minutes).


I also have a PCM2707 based USB board. This is the “workhorse” of the Audio USB interfaces and it is implemented in many, many different designs. The downside is the 48KHz limit.

This device has been getting a bad rap lately with the introduction of “asynchronous” USB devices that can handle sample rates higher than 48KHz. Even though in the beginning it was praised, some measurements have put the jitter in the thousands of pico-seconds. Oddly, Stereophile measured the jitter of the Apple Airport Express at 258 ps which was likely based on  the PCM270x devices (Newer versions are based on different spdif devices which may or may not improve jitter -likely not improve)

The datasheet says that it “employs  SpAct™  architecture, TI’s unique system that recovers the audio clock from USB  packet  data.  On-chip  analog  PLLs  with  SpAct enable playback with low clock jitter”. SpAct refers to a method of capturing the data from the usb isochronous (bursty) transfer in such a way that data is always ready to be transmitted in real time through the i2s or spdif interface. This means that SpAct prevents data transfer hiccups at the USB side and the PLL generates the clock for the SPDIF/I2S side. Thus the jitter of this device is determined by the quality of the (analog) PLL.

The implementation I used was the gamma1 board from AMB, populated just for the USB to I2S functionality and bus powered. This is as minimalist as you can get for a USB to I2S interface.

One surprising result is that this is the only interface (of the 3 I’ve tested) with an exact clock frequency of 44100 Hz


Surprisingly, after the “warm-up” period of the DAC, this interface behaves the same as the other interfaces: just like with the Musiland and OPUS boards, I was able to eliminate most of the dropouts by setting the DPLL bandwidth to “Medium-Low”. “Eliminating most” doesn’t mean completely eliminating. Like the other boards, once in while you will experience a dropout; and like the other boards, setting the DPLL bandwidth to “best” solved the drop-out problem.

NOTE: I didn’t spend enough time time listening with this board to determine exactly if it was “exactly” as the other boards, but within the time spend listening to this board, it seems the infrequent unlocks (with DPLL BW set to “Mid-Low”) was “a bit worse” than with the other boards. Maybe if I spend more time I would determine if it is worse than the other two interface boards, but for now I would say that it is “the same” as the other two boards.


I would say that without some good A/B comparison, the three interfaces sound pretty much the same with the PCM2707 seemingly the worse of the three and the Musiland I2S seemingly the best (Can’t really tell for sure but that would take some serious A/B listening and have not done that yet). For now I will use Musiland SPDIF output primarily because I can set the DPLL bandwidth to “lowest” which in theory rejects the most jitter.


Based on these testing, the information that has been shared in the diyaudio boards and the fact that there exist a 128x setting for the DPLL bandwidth, tt seems that the low settings in the DPLL bandwidth were not meant for real life applications.

The SPDIF can easily lock into a signal perhaps because it is locking to the preamble (the preamble tells you the start of a data block) as the Cirrus receivers have started to do.

In any case, in order to get the most out of the Sabre32 DAC one has to set the optimal DPLL bandwidth depending on the type of the incoming signal: “lowest” for spdif, “best” for i2s/dsd. This can be automatically done by detecting the type of signal in the status register. I’ve done exactly that in my code. And having a manual mode will allow additional optimization depending on the source.

  1. Russ White
    January 14, 2011 at 21:17

    Hi glt,

    I agree that it just makes sense to tune the DPLL to whatever works best for the app. Nearly all clocks will change a very slight amount as they warm up. Even an oven controlled clock. So what you end up needing to do is plan for the worst case.

    That is the nice thing about DIY. You can make it work any way you like.🙂

    As for reported sample rate, keep in mind that the number you see is only as accurate as the reference clock and the divisor, and you have to allow for a little error on both ends (the source and the DAC).🙂 Even with a very accurate clock you will see some variation. This won’t have any impact on the end result.

    Also as previously noted, BW the DPLL of the Sabre32 is incredibly low. Increasing it a bit is *not* in any way going to be detrimental to your listening pleasure. But I understand the desire to try to get it to work at the lowest possible setting. I can totally relate there.🙂


  2. Hifiduino
    January 15, 2011 at 01:13

    Hi Russ
    Yes, that is the fun part of diy (and thanks to TPA, we have access to these modules without having to build them from scratch).

    I agree about the inaccuracies of the clocks, but getting an exact 44100 Hz was nice🙂.

    Regarding the “warm up”, it seems exactly that: the DAC needed to warm up (as in temperature warm up) for it to perform at the lower end of the DPLL BW with I2S. Turning the DAC on/off did not change its behavior, but let it cool off would.

  3. Russ White
    January 15, 2011 at 18:39

    Here is another little tidbit to consider. Notice that the DPLL number is different (64 times different) for SPDIF than it is for PCM. There is a very good reason for this, but what I really want to focus on is the consequence. What I think may be going on is it ends up automatically making the bandwidth higher for SPDIF sources.🙂 Say 64 times higher. Also notice that the DPLL only has to track at 1/64th rate. That is what I think is behind the more solid lock with SPDIF even at what would appear to be lower bandwidth. My guess is it is actually 64 time higher than we think.


  4. Hifiduino
    January 16, 2011 at 01:44

    That is an interesting observation. The factor 64 is a divisor, that means that for I2S, the DPLL number is 64 times higher. If DPLL number is directly related to the frequency of the DPLL, then with I2S it is tracking a frequency 64 times larger than with spdif. So you are right. We know that for I2S, it is tracking the bitclock at 64 fs. This means that for spdif, it is tracking at fs. In relative terms, then the BW is indeed 64x larger in spdif. I’ll have think about this some more… Thanks for the tidbit…

  5. Russ White
    January 16, 2011 at 04:35

    Another important point, is that it is true for all PCM, not just I2S. LJ and RJ are effected in the same way.🙂

  6. Nikitas
    May 29, 2012 at 21:17


    I don’t know where to leave this, so I will just write it here.
    Have you tried and/or managed to use your hifiduino system with gamma1&2 configuration?


    • BlogGeanDo
      May 30, 2012 at 00:09

      If you are referring to the AMB Gamma DAC boards, those are hardwired to work in H/W mode, so you can’t program the registers unless you do some hacking (lifting some pins, etc)

  7. Nikitas
    May 30, 2012 at 11:19

    Ok, but if I connect the hifiduino with the gammas will it function as a monitor?
    I mean will I able able to see the status of the system on the lcd screen?

    • BlogGeanDo
      May 30, 2012 at 16:02

      Well, there is nowhere to connect to. In addition, even if you can connect to the chip by setting it in software mode (by hacking some of pins) there is no “status” register to read. I’ve interfaced with the twistedpearaudio OPUS DAC. See hifiduino.blogspot.com There I show what you can do with the Wolfson DACs

  8. Nikitas
    May 30, 2012 at 16:35

    Excuse my ignorance…
    I just saw the dacmaster here http://www.netstuff.org/audio/
    and thought that it was something like what I asked before.

    • BlogGeanDo
      May 30, 2012 at 20:03

      I see. I was thinking s/w mode which allows you to control everything the chip is capable of.

      You can control those things that are allowed in H/W mode:
      – Anti-clipping enable/disable selection
      – Filter A/B/C selection
      You can use the Arduino to set those pins high or low

  9. September 14, 2016 at 14:45

    permaculture design course

  10. September 14, 2016 at 15:19

    limo Calgary

  11. September 14, 2016 at 15:21

    top service

  12. September 14, 2016 at 19:26

    clik here publishing

  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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s