New Version of Code

FULL SUPPORT FOR “SMART INPUT SWITCHING”

I finally tested the “Smart Input Switching” for the Sabre DAC as proposed here: [link] and implemented in QuangHao’s DAC-END R [link]. I connected the Amanero USB board and also a Toslink SPDIF source to the DAC, and had both sources live at all times.

The DAC-END R connects the Toslink through SPDIF #3 as shown in this diagram (borrowed from here: [link])

Had to fix the code in order to make it work. I discovered a couple of things on how the Sabre32 DAC chip behaves:

• When switching from SDPIF input to Serial input, it is not sufficient to switch the input format. One must also switch the SPDIF MUX to an input that does not have a live SPDIF signal (I switched it to SPDIF#1 which is shared with the I2S connections). If you do not do this step, the status register will report an SPDIF data stream even though you are receiving an I2S stream, and the sample rate calculation will be completely wrong. However, this has no effect on the sound.
• “Auto SPDIF detection” must also be set in the registers when using any of the SPDIF inputs. It is not sufficient to just select the SDPIF input port. If you do not do this step, the DAC will not receive the SPDIF data stream.

In summary:

Switching	Reg8: Source	Reg17: Auto SPDIF	Reg18: MUX
SPDIF to I2S/DSD	I2S/DSD	Off	Select SPDIF #1
I2S/DSD to SPDIF	SPDIF	On	Select SPDIF channel

The code shows the implementation and register settings. “Smart Input Switching” has great appeal because no additional components such as relays or solid state muxes are required resulting straight wire input for any of the sources.

CLEANER CODE FOR DUAL MONO

Recognizing that for the most part changes in register values for one chip in dual mono configuration are the same as for the other chip, I modified the register writing routines to write the same value to both chips even in dual mono. After all the values are written, register 17 is changed for “right channel” and the value is written to the RIGHT chip. This greatly simplifies the programming for dual mono configurations.

Note: not yet tested since I do not have a dual mono configuration.

CODE AVAILABLE IN THE “CODE” TAB

The code is available in the usual place.

NOISE IN I2C: ARDUINO FREEZES

When using the HiFiDuino controller with DAC-END R, I experienced the Arduino controller freezing shortly after power-on. Eventually I traced the problem to the I2C library code in Arduino, which freezes when there is noise in the I2C lines (the functions never return, hanging the micro controller). During experimentation, I tried different things:

• Added smaller pull-up resistors. This improves the I2C waveforms [link]. I used 1.5K pull ups
• Added bypass capacitors to the 5V and 3.3V right at the level shifter board
• At first I forgot to ground the DAC chip reset line. So I grounded the reset line
• Twisted the I2C lines for noise immunity

…but the improvement were very small. The controller would still freeze a few minutes after power on.

It turned out that the noise was caused by the I2S wires crossing the DAC chip as shown in the photo below. The bitclock is twisted with the ground wire, but the data and LRCK lines are just twisted with each other. Another confirmation that it is a good thing to shield the DAC as I previously discovered [link]

Proper wiring is (as usual) required for proper operation.

Even after uncovering the problem, the above enhancements to the I2C lines (pull-up, bypass, etc) are still worthwhile to do to ensure clean I2C signals.

DSO QUAD Enhancements and Mods

I have updated the DSO QUAD Quick Start Guide [link]

In particular, check the sections where on:

1- Installing a community version of the firmware. There are basically two options: Pedro Simoe’s version and Wildcat’s version.

2- Replacing the ESD protection diode for the digital inputs. This will increase the bandwidth of the digital inputs to 8 MHz or more. You can measure LR clock together with Bit clock (two channels)

Seeedstudio is also sponsoring a DSO application competition with a top prize of $3000. If you can write software for the oscilloscope, considering entering so we we can all benefit from your submission :-). Seems Seeed is putting serious effort in making this scope a more capable product.

Experiments with NVE IL715 Isolator

A fellow diyer from Germany kindly sent me as a gift a PC board and other components for the IL715 isolator. I purchased the chip from Digikey. It came with very sophisticated packaging:

I configured the IL715 the “standard” way: both sides fully isolated including power and ground. Below is a photo of the mounted device including two .1 uF capacitor bypass for the power lines (forgive the messy soldering -I couldn’t find my bottle of flux 🙂 ).

Other projects have implemented the use of isolators and the NVE part is the favorite part. But at that time I did not find compelling reasons to use isolators. In addition, according to the IL715 datasheet, the part adds 100 ps of jitter. So lowering jitter is not a reason to use these isolators. In fact the amount of jitter is in the same order of magnitude as the jitter present in modern  FPGA-based USB interfaces so the added jitter is a significant amount.

Note on Jitter: likely the figures quoted are “peak-to-peak” values. Clock jitter values are typcally specified as RMS jitter. The approximate conversion is 15 ps peak to peak ~ 1 ps RMS. Thus in RMS values, the added jitter by the isolator is about 7 psec RMS. Typical FPGA-based USB interfaces will add in the order of 150 psec peak-to-peak or 10 psec RMS [link]

In theory, the reason to use a signal isolator is to block any potential noise coming from the I2S lines including ground. I suppose one can find benefit if the detrimental effect of the noise is greater than the effect of the added jitter.

The power for the input side (the USB interface) is taken off the 3.3V supply inside the Musiland 03 US. The power for the output side is taken off the 3.3V digital supply in the BII DAC. Conveniently, the through holes for the Tridents provide the 3.3V.  This way the two devices are completely isolated from one another. Neither GND or Power are shared.

Connection between the BII DAC and IL715 and Musiland USB interface. Only used 3 of the 4 inputs/outputs (no need for master clock as the Sabre/Buffalo is configured for asynchronous operation).

MEASUREMENTS

I ran my unlock tests with and without the IL715 and here are the results:

First couple of hours after start-up; 44.1KHz, DPLL set at LOWEST

The start up behavior looks similar with or without the IL715. It takes about 1 hour for the system to stabilize. With the IL715 effectively blocking any potential noise passing through the USB interface, this implies that what we are seeing is the “warm-up” characteristics of the Sabre32/Buffalo DAC itself.

After the warm-up (bottom graph), the IL715 seems to slightly increase the number of unlocks. If we compare the this test with what we obtained before without the IL715, the configuration with the IL715 does not look as good. A longer test may show similar results as without the IL715, but this at least hints that there is no need to use the isolator.

This test also seems to indicate that the remaining unlocks are not due to noise coming through the I2S inputs (through the PC and USB interface) since they are isolated, but are due to some other factor.

Increase the sample rate to 88.2KHz; DPLL still at LOWEST

Since the behavior of the DAC with or without the IL715 is about the same, it is hard to see any substantial differences.

It is well known that increasing the sample rate also requires increasing the DPLL setting. In this experiment we will increase the sample rate to 88.2 KHz but leave the DPLL with the setting set at LOWEST. We can expect a large number of unlocks and hopefully see how they IL715 compares with the direct connection. The sample rate will be increased at the Musiland control panel after it has stabilized at 44.1KHz.

The graph below compares the performance of connection through the IL715 vs direct connection. As expected we get lots and lots of unlocks. The tests were done at the same time frame: 10:00 PM to 12:00 AM an then again in the morning in order to eliminate other contributing factors.

The IL715 connection seems to be better (less unlocks) but neither connection really works to listen to music. It is interesting to note that there are intervals where there are no unlocks. This continues to hint at the fact that inherent jitter of the device (which in the case of adding the IL715 results in a total of ~300 ps) is not the factor causing the unlocks. There are other factors that contribute to the instability of the DPLL or clock. These other factors may also contribute to increased jitter causing the unlocks. I think it is worthwhile to focus on providing cleaner to the USB interface (the Musiland is currently fed by USB power) and also in preventing noise from entering through the power line.

Between midnight and around 8 AM I switched the DPLL setting to LOW. Here are the results.

As expected there are no unlocks if the DPLL bandwidth is increased to the next setting. Both interfacing with the IL715 and direct gives the same results. Notice that in the beginning when changing the DPLL setting from LOWEST to LOW, there are a bunch of unlocks. Seems the DPLL can become destabilized with a change of sample requiring some time for it to stabilize. The implication here is that low settings for DPLL may not work well when playing music of different sample rates.

CONCLUSION

As discussed earlier, at least in theory, the reason to use a signal isolator is to block any potential noise coming from the I2S lines including ground. If one cannot find other ways to eliminate noise from the source, and it is demonstrated that the noise is real and it is detrimental to the DAC, then one might consider trading off the added jitter with the elimination of noise.

However as shown by these experiment, there is no clear advantage of using the IL715. With “normal” operation (DPLL=LOWEST with 44.1K and DPLL=LOW with 88.2K), there is no real difference between using the IL715 or a direct connection. We know for a fact that there is added jitter. The data also shows that there is NO “noise issue” from the source.

Since I am a fan for minimal components in the data path, I would side towards NOT using an isolator.

I still have Ian’s FIFO jitter eliminator to test…

“LOWEST” DPLL Setting in Buffalo II DAC

[Note: the reader is encouraged to read the previous posts in the subject, to understand the context of this post]

According to the information shared by the designers of the Sabre32 DAC, when you set the DPLL bandwidth setting to “LOWEST” in the Sabre32 DAC, you maximize the jitter rejection capability of the DAC while in its designed-for asynchronous operating mode, that is with the master clock generated by an on board clock, and with the on-board ASRC fully operational.

In theory, there is an optimal setting for the DPLL bandwidth. However, it is probably safe to assume that “LOWEST” in the Sabre32/Buffalo DAC is indeed “OPTIMAL” because it uses a top-end, ultra low noise oscillator.

After being able to identify the cause for unlocks with the DPLL setting at “LOW” (one notch above “LOWEST”) and having implemented a simple shielding solution that eliminated virtually all unlocks, I ran the tests again but this time setting the DPLL bandwidth at “LOWEST”. This is the ultimate test for the capabilities of the Sabre32 DAC as implemented in the Buffalo II and used in my own home environment. The USB interface is the Musiland 03 and the source is a Win 7 laptop with iTunes.

I let the Arduino/computer record the data for 27 hours. Here are the results:

Notice that when the DAC is powered-on, some time is needed for the clock to stabilize and thus the higher level of unlocks (this is normal behavior). Notice also the long stretch without any unlocks.

Comparing with my first set of measurements with DPLL setting at LOWEST, we see that with the casing/shielding fix, the unlocks have been greatly reduced. The graph below shows the original set of data collected during a 5-hour period. The number of unlocks per 10 minutes peaked at over 20. Now there are no data points above 10.

OBSERVATIONS

1. I was totally surprised at the relative lack of unlocks and also at the lack of correlation between waking hours and sleep hours.
2. We seem to have eliminated most of the airborne noise by using proper casing for the DAC. The number of unlocks have been greatly reduced, but at this DPLL bandwidth setting, they have not been totally eliminated.
3. There doesn’t seem to be much noise sneaking in through the wiring as shown by the long stretch of no-unlocks during the waking/working hours.
4. There are two “burst” of unlocks and they coincide in time (8-10 PM). I cannot relate this behavior to anything happening in the house. During the long stretch at night, the washing machine was on and it did not cause any unlocks.
5. I have had the Buffalo II DAC for over two years, and have used different interfaces feeding the I2S inputs. All of this time I thought that the unlocks were caused by jitter in the interfaces, even with the currently used Musiland o3.  Not so!. If we look at the data, the long stretch (over 6 hrs) of playtime without a single unlock indicates that the the jitter in the I2S signals from the USB interface device are not large enough to cause unlocks even at this lowest setting of the DPLL bandwidth.
6. The Musiland 03 seem better than I thought 🙂

POTENTIAL SOLUTIONS

1. I can only think of more shielding. Perhaps on-board RFI shielding is required. Something similar to what Anedio has done.
2. I2S isolation. We can use a device such as the NVE IL715 [link]. I already have a device and board and will test it when ready.

ENJOYMENT

Normally, I set up the test and go off doing other things (like going work or sleeping). The test is done with the amp off. Last night for the first time I was able to enjoy several songs (after 10 PM -see data, only one unlock) with the setting at LOWEST. I didn’t even notice the single unlock I measured. I can’t say that I can clearly distinguish differences in sound, but as a diy-audio enthusiast, a successful tweak clearly adds to then enjoyment of music :-).

3/14/2012 Session

This time I used the computer while listening to music (like browsing the web). DPLL is again set at LOWEST. The unlocks recorded are unrelated to using the computer; they happened while I was NOT using the computer. I can’t figure out what caused the unlocks.

3/15/2012 Session

• I collected data right from the time I powered the DAC for about 5hours. Notice the large amount of unlocks when the DAC is “cold” and the time it takes for DAC to stabilize (“warm up”) – I would say it takes about ONE hour.
• I switched the power cable to a “shielded” cable, keeping the ferrite bead I had before and I also switched the USB cable with one that said “shielded” in the jacket, keeping the ferrite bead I had before. (The original USB cable was a USB-3 cable that probably is also shielded, but did not say so in the jacket). Doesn’t seem to make any differences
• Still no correlation from the unlocks (after warm-up) with what was going on at home
• The pattern of the unlocks indicates interference from somewhere rather than jitter in the USB interface.

Never too much shielding???

Added additional shielding to the DAC chip. To do this, I soldered two pin connectors to a small copper board and then plugged it in to the GND pins of the AVCC module as shown in the photos. In addition, I added some damping material to the oscillator in order to reduce vibrations.

The results: next post…

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.

SOME BACKGROUND

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

Sabre32 Unlocks: Looking for Gremlins

Recognizing that the Sabre32 DPLL setting is sensitive to incoming jitter, I devised a test to automatically measure the number of unlocks as documented here: [link]

As it is turning out, the unlocks do not seem directly related to the jitter of the transport because they seem random glitches and they show a strong correlation to electrical activity during the daylight hours. Either the noise in the electrical grid increase jitter or causes other anomalies causing the DPLL to loose lock.

In this post I will record and update different tests in order to determine what improves this un-lock behavior. Ultimately, if we can lower the DPLL bandwidth of the Sabre DAC, the level of jitter reduction will be increased, and that is a good goal.

TEST CONDITIONS

• Bufflalo II DAC powered with Placid at 5.25V.
• DPLL bandwidth: “LOW”. This is one notch above “LOWEST” since with this setting I am able to have unlock-free behavior for long periods of time (hours)
• Source: iTunes on Windows 7
• Transports: Musiland 03US
• Everything is plugged into a Monster Cable power conditioner
• [Click on images to see the original size]

MORE SHIELDING: (modding the case)

Originally, I had the DAC board without any casing affixed to the top of the power supply unit, just minimal shielding from a top plate as shown below (minus the Musiland MINI on top which I had upgraded to the Musiland o3).

Using another case for the DAC board (luckily I had a matching case :-)). I also elevated it from the PS unit below to keep the electronics a little further away from the transformers in the PS unit.

The Musiland 03 also fits neatly inside the case

Never hurts to add additional shielding. I put a metal plate to serve as more shield and to affix the output connectors. In addition, the plate makes contact with the Musiland case setting it a common EARTH GND potential (the Musiland is sitting on rubber feets) with the rest of the case. Also I wanted to isolate the output wires from the input wires.

With the cover in place. you can also see a ferrite I added to the input power to the DAC

Measuring the unlocks…

SHIELDING: SEEMS TO HELP

Suspecting airborne interference/noise (as also expressed by a commenter), I added some additional rudimentary shielding to cover the DAC board (just a metal cover that fully covers the top and the two long sides of the DAC board).

Here I plotted the best data set I had for the wee hours against the new data I got last night. There seem to be improvement. (This time, instead of looping a single song, I let iTunes play through the library -I wouldn’t think this would make a difference)

Notice that I only got 5 unlocks from 11:00 PM to 8:00 AM and there was a long stretch of almost 6 hours  without a single unlock. So we are “getting there”. I shall construct a case that fully encloses the DAC board…

LONG LEADS vs SHORT LEADS: NO DIFFERENCE

I shortened the I2S wires from about 9″ to 3″ to test if there are any differences in the unlock behavior. I also removed the ferrite bead I put in the bit clock wire as it seemed to make no difference (it seemed worse) and in addition, the ferrite might become a problem with higher sample rate material. As shown below, it doesn’t seem to make any difference

AM vs PM: NOISE IN POWER GRID

I let the computer collect more data as I went to work. No activity at home until around 3:00 PM. The Bitclock signal has a ferrite bead (which seems to make it worse – I will test it again without the ferrite bead). As shown by the data: the number of unlocks is strongly dependent on day vs night.

FERRITE IN BITCLOCK: NO BETTER (SEEM WORSE)

Attempted to deal with the power noise issue by inserting a ferrite bead in the bitclock wire (with two turns). The results are shown below. In total I recorded 249 unlocks with the ferrite and 174 unlocks without the ferrite. Since the data was taken in different days, I don’t think the difference is that significant.

What the data shows is a strong correlation between electrical activity during the daylight hours and much reduced activities during the night time hours especially after midnight. There is also a “break” during the daylight hours when people are out of the residential areas.

Poor Man’s Jitter Measurement

INTRODUCTION

It is well known that by setting the DPLL bandwidth in the Sabre32 DAC to its lowest level, results in the DAC being “overly” susceptible to incoming jitter. This is manifested by the DAC loosing lock on the signal. We can use this “property” of the DAC to determine a relative value of incoming jitter.

METHOD

In order to measure the number of unlocks, I connected the outputs of the lock LED in the Buffalo II DAC to an Arduino. The Arduino detects the unlocks and logs that event with a time stamp.

The lock LED is replaced by a resistor (I used 5 Kohm) the then the two leads across the resistor are connected to Pin2 and GND in Arduino. The lock signal is a voltage applied to an LED. An unlock pulls that voltage to ground. This can be detected by generating an interrupt in Arduino.

I put tape on the pins that I did not use because I didn’t want to mistakenly connect a wrong pin (say a 5V pin) to the DAC and risk potential damage.

The data is logged to the Arduino serial monitor, which can be copied to a spreadsheet to generate graphs.

RESULTS

Below is the result of my first measurement. The Buffalo II DAC DPLL bandwidth is set at “lowest” and is connected to a Musiland 03US through its I2S input.

Each data point represents the number of unlocks in a 10 minute period. Notice that in the first 10 minutes after I turned on the DAC, there are many more unlocks due to the fact that the DAC goes through a “warm-up” period to stabilize its clock (this is a well observed behavior). The data also shows that it takes about 10 minutes for the DAC to stabilize.

CODE

/*
Code to detect unlocks in BII DAC.
 The lock LED is replaced by a resistor the then the two leads
 across the resistor are connected to Pin2 and GND in Arduino
 By detecting the unlocks and recording it we can measure how
 many unlocks occurr during a specific amount of time.
 
 The lock signal is a voltage applied to an LED. An unlock pulls
 that voltage to ground. This can be detected by generating an
 interrupt in Arduino.
 */

#define INTERVAL 10             // Arbitrary time interval in minutes

static boolean unlock=false;    // Flag
int total=0;                    // Total unlocks
int totalInterval=0;            // Total unlocks every time interval

unsigned long minutes=0;        // Minute count 0 to 59
unsigned long totalMinutes=0;   // Total minute count 0 to ...
unsigned long hours=0;          // Hours count 0 to ...
unsigned long lastInterval=0;   // Time in minutes of last interval

void gotUnlock()                // Interrupt handler
{
  unlock=true;                  // Interrupt indicates got an unlock
}

void printTime(){               // Prints hours:minutes as xx:xx
  if(hours<10)
    Serial.print("0");
  Serial.print(hours);
  Serial.print(":");
  if(minutes<10)
    Serial.print("0");
  Serial.println(minutes);
}

void keepTime(){                // Keeps track of elapsed time
  if(millis()>((60000)+(60000*minutes)+(3600000*hours))){
    minutes++;
    totalMinutes++;
    if(minutes==60){            // For every 60 minutes...
      minutes=0;                // Reset the minutes and...
      hours++;                  // Increase the hours
    }
  }
}

void printData(){
  Serial.print(totalInterval);
  Serial.print(" ");
  Serial.print(total);
  Serial.print(" ");
  printTime();
}

void setup() {
  Serial.begin(9600);
  pinMode(2, INPUT);            // Set pin 2 for input
  digitalWrite(2, HIGH);        // Turn-on pull-up resistor
  attachInterrupt(0, gotUnlock, FALLING);
  Serial.println("start test");
  Serial.println("IntervalTotal Total Time");
  unlock=false;
}

void loop(){
  keepTime();
  if(unlock==true){
    delay(20);                  // Some delay for "debouncing"
    total++;                    // Update total unlocks
    totalInterval++;            // Update total for interval
    Serial.print(". ");
    printData();
    unlock=false;
  }
  if((lastInterval+INTERVAL)==totalMinutes){
    lastInterval=totalMinutes;
    Serial.print("# ");
    printData();
    totalInterval=0;            // Reset the interval count
  }

}

Jitter: 100MHz Clock 10x Better Than 80MHz Clock?

I decided to compare the jitter value between the 100 MHz clock vs the 80 MHz clock based on the datasheet from Crystek. This is what I got:

80 MHz: 2.29 ps RMS

100 MHz: 0.24 ps RMS (almost 10x better!)

I used the online jitter calculator to determine the numerical value for the jitter based on the data points shown in the phase noise graph.

For the 80 MHz part: RMS jitter=2.2864 ps (keep in mind that most specifications start at 100 Hz whereas this measurement starts at 10 Hz)

For the 100 MHz part: RMS jitter=0.23586 ps! WOW. This is 10x lower than the 80 MHz part. (but whether you can hear a difference or not, that is another matter)

CLOSE-IN JITTER

Notice that most of the jitter in the RMS measurement comes from the close-in part of the frequency spectrum, in particular the region up to 100 Hz.

“Lower grade” clocks conveniently ignore this part of the measurements in their jitter specifications. For example, the specification for the Crystek C33XX, (the typical “small” clock found in many audio products) says:

Jitter RMS: 12kHz~80MHz: 0.5psec Typ., 1psec Max

DOES IT MATTER?

One authoritative paper is an AES paper titled Specifying the Jitter Performance of Audio Components. The concluding remark with respect to “useful” jitter measurement is the 100Hz value and the RMS jitter from 100 Hz to 40 KHz

Jitter spectra, when plotted properly, can be very useful.   They can be even more useful when accompanied by numbers for RMS wideband jitter (100Hz corner) and RMS baseband jitter (100Hz-40kHz).  The makers of audio clocking chips should consider providing this information in their product datasheets.

If we then compare both clocks starting from 100 Hz, then we get:

• 80MHz clock: 0.00462 ps (100Hz ->)
• 100MHz clock:  0.00123 ps (100 Hz ->)

Now we are talking about a difference of about 3 fs (femto-sec) or 340 atto-sec

Read more here and  here

BII 80MHz + 352.8KHz Audio + Silence = Noise

(NOTE: This behavior and the solutions have been documented by Bunpei over one year ago. Here I am reporting my own experiments which confirms his findings)

MASTER CLOCK SPECIFICATION

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.

PLAYING MUSIC

As reported in this post, the BII-8oMhz DAC can play 352.8Khz audio. It seems though to “struggle”, like being at the “edge” of its capability, occasionally emitting a “click”,  but with some adjustments it plays fine and almost noise free.

PROBLEM

However, there is a peculiar problem with 352.8Khz audio material: when the track is paused, stopped or during the gap between songs the DAC will emit a loud hissing sound (sort of like white noise). This noise responds to filter and volume settings in unexpected manners:

• The level and tone changes with the DAC digital volume setting but not in relation to it. For example, one setting will give you low volume and lowering the volume one click will greatly increase it.
• FIR sharp filter results in a louder noise than the slow filter
• The quantizer bit depth also changes the amount of noise coming from the DAC, with 8bit giving the lowest amount and less than 9bit
• The IIR filter and the notch delay don’t seem to have any effect
• DPLL  bandwidth even by enabling the 128x DPLL bandwidth multiplier did not have any effect. I applied the maximum DPLL bandwidth and the noise did not go away

The white noise problem can also be replicated with the following:

• Reduce the volume to zero using the volume control of the application, the OS or the device driver
• Reduce the volume to near zero. The noise will start showing up in the form of “clicks” and “cracks”
• Playing a silence track.
• Fast forward/reverse the track (the application mutes the sound when doing this)

The problem has also been reported if using an ExaDevices EXAU21 USB interface and also using the SDTrans transport.

It seems that somehow there is a reversal and silence is interpreted as sound and because there is no real data, you get white noise. If it were erroneous low level data picked by the I2S wiring then it should respond to the lowering of the volume, but it doesn’t

SOLUTIONS

Software solution

I have not yet found a good software solution to this problem.

The only thing that mitigates this problem is enabling the “automute loopback” feature of the chip. The DAC can detect the “zero” level and mute itself (if so programmed). However, it cannot automute in zero time but it takes a fraction of a second as it ramps to mute after detecting the “zero” level.

The result is that the noise can be limited to a short burst of white noise whenever silence is encountered. It is still annoying but not as annoying as continuous white noise :-).

Additionally, I tried different things to reduce or eliminate this burst of white noise but so far the following measures don’t seem to make any difference:

• Detect the zero level sooner (shorten the time in zero level that constitute zero level)
• Increase the value of zero level (I have changed it from the default value of -104db to -60db)

Hardware solution

Upgrade the clock to 100Mhz

The Buffalo II DAC was upgraded to 100 MHz clock. The Buffalo III also comes with a 100 Mhz clock. This is the “official solution”.

If you can do simple soldering, you can buy a 100 Mhz oscillator at Mouser for about $30. The mod is very simple and can be completely non-destructive by adding a second oscillator to the board.

• First, cut off the power to the existing clock by removing L3 in the backside of the board.
• You can use the existing low noise regulator to power the new clock. To do this you can leverage  the Trident connectors: VDD_XO and GND.
• Then use proper bypass of the VDD_XO pin close to the clock. In order to further minimize noise, use a ferrite prior to connecting the power to the clock
• Finally you take the output of the new clock and connect it to the pad next to the text R17

I haven’t decided to do this mod.  The only reason at this time is for “proof of concept” because there isn’t much material out there that is in 352.8KHz.

For those who are planning to do the mod, look at the comments section. There is a comment from Bunpei (http://www.zeph.com/lowmelt.htm) showing the “best” way to replace the clock.

Further ESS Sabre DPLL Tweaking

I don’t know if there is a well defined direct correlation, but this setting gave me a pretty stable lock with DPLL set at “LOW” with the Musiland USB -> I2S. I am pretty happy with the performance of this USB interface so far.

Seems ESS designed the DPLL with low enough bandwidth to be a good experimental gauge of jitter for even the big league USB interfaces.

I can probably do a more scientific experiment by wiring the lock LED to an arduino interrupt pin and count the unlocks within a period of hrs…