Why is 80MHz Not Enough?

HYPOTHESIS

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.

IN PRACTICE

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

Musiland Driver 2.X: Release Version

(Update Oct 26, 2011). Another update: MlCyMon_2.1.0.0_build20111026.exe in the main driver folder.

WHAT IS NEW IN THIS UPDATE

Slight changes in the UI (notice “System Volume”, and other small details)

According to this post:

1. New technology and software algorithms to improve the accuracy of the signal to improve sound quality
2. Improved compatibility with 64-bit systems, AMD chipset, systems with 4GB or less of memory, WDM and ASIO
3. Minor tweaks to the user interface (as shown above)
4. Support Windows 8 Preview
5. New DMA playback mode, for improved high sampling rate playback (352.8kHz and 384kHz)
6. Improved compatibility with a variety of playback software
7. Reduction of system latency

(Update Oct 13 2011). Yet another update: MlCyMon_2.0.1.0_build20111013.exe in the  main driver folder. All of these releases are “out of the beta folder” but they are still called beta releases.

WHAT IS NEW IN THIS UPDATE

• Better support for 64bit Windows, Windows 8 and AMD chipsets
• Improved 352.8kHz and 384kHz playback in Monitor 03US
• Utilization of undocumented 32-bit API for full 32 bit support across the entire Musiland Monitor series
• New “DMA playback” mode for reduced latency, and better 32 bit support
• “White” interface

You can download MlCyMon_2.0.1.0_build20111009.exe from main driver folder. You can find more information in the Musiland Tab.

NEW FEATURES

The main visual difference is the HDCD indicator which lights up when it detects an HDCD encoded track.

In order to enable the HDCD feature (and indicator) , you must change the “hdcd” value from 0 to 1 in the Config.ini file found in C: \ Program Files \ MUSILAND \ Monitor Series (USB). After you change it, close (exit) the Musiland control panel and restart it. [The installer installs the config file with only read permission. You need to add the write permission to the config file in order to edit the value]

FIXES:

- Fixes a noise problem when playing 352.8KHz material through the Musiland built-in DAC/Headphone amp. There used to be a hissing sound when playing at that higher sample frequency. This was supposed to be fixed previously, but previous version would not install in my system due to “invalid license” problems.

- The default sample rate setting is persistent across reboots. The old driver would reset to 48 KHz after a system reboot

In addition:

• Support for Windows 8
• Support for Chinese language (yes, they released English menus first)
• Digital volume level can be saved

REMAINING PROBLEMS

• At min or max setting, the volume will jump to max or min if you keep “turning it”
• MMDI does not work
• For Monitor Series 01 and 02: a second consecutive click on the sample rate generation mode will turn off the indicator like this:

STILL NEED SOME POLISHING

Installed for the Monitor 01 USD (no Analog output)

Note: there have been two earlier releases (one day apart) that are no longer available. If you downloaded MlCyMon_2.0.0.0_build20111007 or MlCyMon_2.0.1.0_build20111008, they have some minor problems (not compatible with Monitor 01 and 02 series, not announcing to the OS as 32 bit drivers and not being able to save the default bit rate in the sound control panel)