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

 

Interesting details of Weiss Implementation of ES9018

SYNCHRONOUS CLOCKING

The photos below shows the inside of the Weiss 202DAC. Notice that there is no local oscillator, the location/pads where the oscillator should be located is empty.

(photos taken from different sites in the internet. Japanese sites have the best pics)

I would suspect that the clock is provided by the audio interface chip (DICE chip) which derives its clock from its local oscillator as shown below

According to the specification of the DICE chip, the crystal frequency shall by 24.576MHz (section 3.1.1.1).  This frequency multiplied by 4 results in a frequency of 98.304MHz. According to Enjoy the Music, this frequency is what is used to “drive” the ES9018 chip.

According to Russ White [link],

The best thing to do if you desired a synchronous clock is simply to supply one that is an exact multiple of the incoming bit clock. But if you do both 44.1khz and 48khz based multiples that is going to mean two master clocks. The way to do this is to use the same master clock that is actually used to generate the bit clock (by division). I have implemented this using my XMOS proto board. It works quite well, but you still want a fairly high speed clock.

Operating like this allows the DPLL to basically free wheel. It does not even have to try to maintain a lock. 🙂

This seems to imply that sample rates may be resampled to 192K  (an even division of 24.576) and then sent to the DAC

People at diyaudio have been experimenting with synchronous clocking with great results. The other message here is that the forthcoming XMOS interface from TPA will allow this kind of synchronous clock interface which is favored by the likes of Weiss

C529 BATCH: SAME AS MY BUFFALO II 🙂

I think the batch number means week 52 of year 2009. Notice also the location of the Buffalo II DAC and compare to the Weiss implementation.

USE OF BUILT-IN FILTERS

I have been trying to access the programmable feature of the ESS DAC without any success. According to the review at Enjoy the Music,

1. About Filter A and B. These are stated to be “upsampling filters,” but no real detail is given in the manual. Are they similar to other manufacturers upsampling filters, i.e. one is for say 96kHz and the other for 192kHz Upsampling? Does this mean DAC202 cannot be set to bypass upsampling (44.1kHz native playback with oversampling only?).

Answer: The A and B filters are the ones used in the ES9018 DAC chip, i.e. the “factory presets” so to speak. In the ES9018 all input signals (independent of their sampling rate) are upsampled to about 1.5MHz. The B filter has a softer transition band than the A filter. We plan to add more filters to those two.

This leads me to think that even industry-leading edge people like ESS have not been able to use the programmable filter feature of the DAC. Weiss does say that they “plan to add more filters”, but right now it seems that feature is not available.

In any case, Stereophile published the response of the two built-in filters (left is the sharp filter)

WHY SO MANY RELAYS?

The relays are Panasonic TN relays.

The DAC202 has four selectable coarse analog settings and provide 1.06, 2.12, 4.15, and 8.15v at the analog outputs. These are related to the gain resistors at the output stage. The relays are there to select the appropriate resistor for the desired gain. In addition, there may be relays selecting the appropriate input pins for I2S and SPDIF (although you could permanently wire and switch between I2S and 3 other SPDIF inputs just by programming the registers in the DAC chip as detailed here [link])

Code compatible with Arduino 1.0

I’ve updated the Buffalo Code to make it compatible with Arduino 1.0. Check the code section

NEW SETTINGS

Preceding the sample rate number there is an oversampling indicator

• Oversampling: (^)
• Oversampling bypass: (.)

Next to the DPLL setting there is a “mode” indicator

• Normal: DPLL setting is x1: (NOR)
• Multiplier: DPLL bandwidth is x128: (MUL)
• Jitter Eliminator is off: (OFF)

These setting are probably only useful if you use the DAC in synchronous mode (feeding an external clock that is synchronous with the data).

OVERSAMPLING BYPASS ON 80MHZ BUFFALO II

Based on previous experimentation and also as suggested by others, I attempted to turn off oversampling in order to play 352KHz material without the noise problem. I added code to automatically turn off oversampling when high sample rate was detected.

Unfortunately, it didn’t work. Oversampling bypass works 0nly if the incoming sample rate is 384KHz. I simulated this by having the Musiland o3 USB interface do the upsampling (it could have been Quicktime doing it but all I had to do is set the sample rate in the Musiland control panel to 384KHz), and I confirmed the sample rate in the Arduino display.

With incoming sample rate below 384KHz, the following was observed:

• DPLL locks if there is no music playing. The measured frequency is 64x smaller
• DPLL is unable to lock if music is playing. When the SR is 352K, it can intermittently lock (very rapid lock/unlock). When the sample rate is 192K or below, there is no music output.

GUI SUMMARY

DISPLAY MODE

The normal mode of operation is the “display mode”. In this mode, moving the rotary encoder only changes the volume level: clockwise increase volume (decreases attenuation); ccw: decreases volume (increases attenuation)

SELECT MODE

To enter select mode, you press down on the rotary encoder (to activate the switch in the rotary encoder). If there is no activity within 4 seconds (adjustable in the code), the code reverts to normal mode.

In select mode, a right pointing arrow indicates which parameter may be changed. Every click of the switch of the rotary encoder switch moves the arrow one position; to change the parameter, rotate the rotary encoder. In this mode the sample rate is NOT updated.

REMOTE CONTROL

• Button 1: Increase volume
• Button  3: Decrease volume
• Button 5: Mute/unmute

The mute function is implemented to kill the volume instantly but softly restore the volume level to the previous setting.