Home > General > More on Sabre32 I2S Locking

More on Sabre32 I2S Locking

February 15, 2011 Leave a comment Go to comments

Perusing the old diyaudio threads (circa 2006), I came to a thread describing the initial designs of the Sabre DAC chip. The ASRC was being designed by Dustin Forman and included a SPDIF receiver. The SPDIF receiver was designed to be superior to any current design, being able to lock into an incoming signal even in the presence of large amount of jitter. This post summarizes the capabilities of the receiver:

“…I did however do a side by side test with my ASRC and the CS8421 looses lock with about 50ns of sine jitter added to the SPDIF stream (Tested with APS2) . Then with my ASRC it still maintained lock with up to 400ns (of sine) jitter…”

The output of the SPDIF receiver is connected to the input of the ASRC. In this post, Dustin shared the challenges of designing the ASRC:

“…designing the ASRC I ran into the problem that the higher my “PLL” bandwidth, the worse the SRC got. Lowering the loop bandwidth does create a better SRC, however something bad happens. If the bandwidth is too low, and your source sample rate is not rock solid (jitter, or just any slight frequency variation) then the locked output would get tiny glitches in it when the ASRC accidentally missed an input sample point or grabbed one twice.

Imagine I lock my “PLL” to the input rate at say 44.10000 kHz and then lowered the loop bandwidth so low it could not respond to the input rate changing to 44.10001 kHz before the PLL misses one of the input samples since it is only looking for data at 44.10000 kHz but the data is now actually coming at 44.10001 kHz.

This was the hardest part of the ASRC design: having enough loop bandwidth to handle source data rate variation, but not too much that it causes errors in the SRC.”

The ASRC as a standalone product was never released, but the technology was incorporated in the ESS DAC chip.

From the above information, one can probably deduce that the SPDIF receiver, being an “integral part” of the ASRC, will enable additional jitter suppression as compared to I2S input.

Update Feb, 2012: The current understanding is that with the same setting the DPLL for the I2S input is narrowed 64X, thus the “difficulty” in locking to the signal

  1. Russ White
    February 16, 2011 at 03:11

    This predates the Sabre 32. 🙂

    Naturally some of us have known this info for a long time, but it is good to remind people of the facts.

    In any case the major advantage of the ASRC is really in its extreme ratio (64 * mc / fs). But it does demand a great source clock.

    Where the ES9018 differs from the ES9008 as the fact that the DPLL window is actually quite a bit smaller at the lowest settings, unless you set the register which makes it the same.


  2. BlogGeanDo
    February 16, 2011 at 05:25

    Hi Russ, I suppose as the DAC chip and regulators are turned on they will start warming up until reaching some steady state temperature. This warm up will affect the frequency stability of the local clock causing the increased glitches during this warm up period

  3. Bunpei
    February 16, 2011 at 15:17

    I really want to know the exact meaning of DPLL bandwidth parameter.
    Is it just a “threshold value” or “both threshold value and scaling factor”?
    I guess it’s the latter.

    By the way, a crystal oscillator module also needs certain warm-up.
    Before warm-up is enough, its oscillating frequency hops.

  4. Bunpei
    February 24, 2011 at 15:29

    Hi, BlogGean,

    Do you have any idea on the guess here?

  5. BlogGeanDo
    February 24, 2011 at 19:07

    Hi Bunpei, I don’t know, although it is possible some firmware to use “lowest” and some to use “best”. I’ve done more tests and there is a HUGE difference in locking between “lowest” and “best” when using hi-res material 96K or 192K. With the hires material and I2S input, there are lots of unlocks with “lowest” but NO unlocks with “best”.

  6. soundcheck
    April 11, 2011 at 06:26

    The only thing I know and experience is that the jitter rejection on the SABRE SPDIF input is not worth to mention. I find it extremely poor. Slightest changes
    will make it through. What’s required is probably a multistage jitter rejection to be able to decouple properly from input variations.

    I’m running a TP. Buffalo II.

    So, it is either Twisted Pear or the chip itself who .

  7. BlogGeanDo
    April 11, 2011 at 16:42

    Soundcheck, thanks for the comment. Right now I’m using I2S inputs with “best” dpll setting. (Tweaking the dpll setting is not really worth it if your goal is to listen to music 🙂 )

  8. September 14, 2016 at 14:51

    imprezy firmowe wroclaw

  9. September 14, 2016 at 17:14

    premature ejaculation treatment in hindi

  10. September 14, 2016 at 18:10

    bible sermon topics

  11. September 17, 2016 at 07:04

    Excellent post. I was checking constantly this blog and I’m impressed! Very useful info specially the last part 🙂 I care for such info much. I was seeking this certain information for a long time. Thank you and good luck.

  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