Update on Oversampling Bypass

It has been suggested that turning off the internal oversampling allows flawless playing of 352.8K material with a 80 MHz clock. So I programmed the chip to turn the oversampling bypass register ON/OFF as indicated in the datasheet in register 17:

OSF bypass [link]:  Bypasses the internal oversampling FIR filter and expects the data to be at 8X oversampling according to the datasheet.  The data is sourced directly to the IIR filter.

THIS IS WHAT I FOUND:

In using a Musiland 03US feeding the Buffalo II DAC with the 80 MHz clock with I2S, turning off oversampling did not work except for 384K material. I tried changing all  possible settings that the chip registers and other settings allowed. I changed dpll bandwidth, IIR filters, quantizer size, notch filter, digital volume setting prior to the DAC, etc -everything that my latest s/w allowed me to change) and I was not able to get any music. The observable behavior is summarized below:

• SR<352Khz resulted in fast intermittent sound with the lock-led flashing like crazy. By increasing the dpll bandwidth setting to highest and the dpll bandwidth multiplier to x128 (this is the highest bandwidth setting possible), the lock-led flashing rate slightly decreased as though the DPLL was trying to lock. But there was no lock and no music
• For sample rates 352.8K and below, the DPLL was able to lock but only when there was no music content (for example when the player is paused).
• SR=384Khz resulted in “normal sound”
• The frequency of the DPLL indicated was 64x smaller what it should be for I2S input. So for example, for SR=384Khz, the sample frequency determined by the dpll was  6000 Hz (if you multiply 6000×64 you get 384000 Hz)

Now this is very strange: why would it lock with no data since the DPLL locks to the bit-clock? Why would it work if the sample rate is 384KHz? Why would the DPLL locking frequency be 64X smaller?  I have no clear answers for this behavior except for the comment by Russ White below. Indeed this behavior is very “undesirable” 🙂

According to a post by Russ,

…You would not want to turn of the OSF unless your data is synchronously re-sampled. Otherwise the result would be very undesirable.

Thus apparently it doesn’t work unless the clock (feeding the DAC) is synchronized  to the bit-clock. I am using the Buffalo II in its “normal configuration”, that is the clock driving the BII is separate and not synchronized with the incoming bit clock.

Further Russ indicates here [link]

The OSF in the Sabre32 is 8x FIR + 8x IIR for a total of 64x (This is why is needs 64Fs bitclock) so our math was a little out of whack. I am sorry for adding to the confusion for a while. The master clock in no way needs to be 8 * bit clock to do 8X oversampling (as the ES9018 does in fast roll-off) or even 4X (slow roll off). When you disable the OSF both filters are gone. Sorry for the confusion there.

The experiment of bypassing the oversampling “proves” that both filters are bypassed and thus the reduction of 64x in the sample rate. This would be a welcome explanation except that Russ further states:

Sorry quick correction on the above. The IIR remains active when OSF is turned off – only the FIR is disabled. I was confusing the point of two emails.

The above is consistent with what the datasheet specifies. It seems though, that empirically both the FIR and IIR filters are bypassed as measured by the dpll number when it can lock to the incoming data stream.

SYNCHRONOUS CLOCK

It appears that in order to turn off the oversampling, synchronous clock is required. But if you use a synchronous clock, according to a discussion by Dustin Foreman:

Thorsten: Further, the Sabre uses asynchronous sample rate conversion on all input data and converts into a clock rate of 40MHz.

Dustin: Again true but not the whole story. You can use the ASRC if you like – or not by simply clocking the XIN pin synchronously (at an integer multiple) to the BCLK. Then the ASRC drops itself out, reverting in this case to a more conventional method as the other DACs I’m aware of do

…The ASRC is automatically disabled if in addition to having synchronous clocking, the clock is also an even multiple of the bitclock. (As an example of a synchronous and even multiple clock, for a sample rate of 352.8KHz, the bitclock is 22.5792 MHz. If we feed the DAC with a frequency of 4X, we get 90.3168 MHz)

Thus in order to support all sample rages up to 352.8Khz and 384KHz material, with oversampling ON and with the ASRC disabled,  we need two oscillators of 90.3168 MHz and  98.304 Mhz (that can automatically switch depending on the incoming sample rate). Apparently TPA is planning these clock rates for their forthcoming XMOS USB interface.

WHAT NOW FOR THE 80 MHz BII?

I think there is no solution for the 80 MHz BII to play high-res (>362.8K) material. The only option is to upgrade the clock to 100 Mhz or use a synchronous clock.

Using a synchronous clock requires that the source can operate with the required clock that feeds the Buffalo DAC. So if we keep the 80 MHz clock, we need to feed this clock (or some integer fraction of it) to the source device. In the case of the Musiland devices, the base clock is 24 Mhz, thus it is not easy to derive the 24 Mhz out of the 80 Mhz clock. Other devices such as the XMOS or HiFACE also require clocks that are multiple of the typical audio frequencies of 44.1K and 48K. So synchronous clocking with the 80 Mhz clock is pretty much out of the question.

One can feed the Master clock from the source device to the Buffalo DAC (by disabling the 80 MHz clock). However the frequency of these clocks are typically in the “lower end” such as 22.5792 MHz. Which is not within the desired frequency range of the DAC in order to support high res material (with oversampling ON).

NOTE however, that Bunpei has tested synchronous clocking with a 22.5792 MHz clock input to master clock XI pin of ES9018 and found it feasible enough for from fs=44.1 kHz to fs=352.8 kHz sources under OSF = OFF conditions. [link]

Thus the only practical alternative is to upgrade to 100 MHz. unless one gives up the oversampling filter.

WHAT IF WE REPLACE THE CLOCK WITH A LOWER FREQUENCY?

Crystek has recently released ultra low phase noise oscillators focused on audio-relate frequencies:

(Best photo I could find [link] of the newly developed oscillators).

The specifications are impressive. If we compare with the current 100 Mhz clock in the BII/BIII, we get the following plot:

And entering those numbers into a RMS jitter calculator, we get the following jitter numbers:

• Original 80 MHz clock: 2.286 psec RMS
• 100 MHz clock in the current boards: 0.236 psec RMS
• 49.152 MHz CCHD-957 clock: 0.121 psec RMS (see below graph)

The jitter numbers are 2x better than the 100 Mhz clock that is used in the current boards.

40MHZ BETTER THAN 80 MHZ? (or 50MHz better than 100MHz)

According to Dustin [link]:

…by the way, running the DAC at 80MHz with a good crystal you can expect to only see a 1dB DNR loss from the 40Mhz boards, if that. Some show no diff, some showed 1dB.

In addition, the power requirement of the analog supplies (AVCC) with the lower frequency is about 40%-50% less [link] resulting in a cooler running electronics.

The disadvantage is that you will loose the capability of 192KHz through the SPDIF interface (datasheet requires 386xFS for spdif). It should still work for 192KHz for I2S and DSD.

So there are have it:

JUST TWO CHOICES FOR UPGRADE

CCHD-950 100 Mhz ($31.12) will support all sample rates

CCHD-957 “Audio Quality” 49.152 Mhz ($30.96) for the “ultimate” clock, if you are willing to give up ultra-high res music.

OTHER IMPLEMENTATIONS

The $32K Accuphase DC-901 uses a 40 Mhz clock

And it supports 192K through the spdif interface

The Resonessence DAC uses a 50 MHz clock [link]

Both analog boards are preceded by a Crystek CCHD-950-20 low-phase noise clock.  We chose the 50MHz part as it has the lowest phase noise at offsets that are in the audio band. The clock has its own dedicated ultra low-noise power supply

The Anedio D2 uses a 80MHz clock [link] (looks like 50 Mhz from the photo, though