The introduction of the Buffalo III, added welcomed features to an already excellent implementation of the Sabre32 ESS 9018 DAC that Russ and Brian have accomplished at TwistedPear Audio. The improvements over the product it replaced, the Buffalo II DAC, were focused on exposing all the inputs, outputs and software parameters supported by the chip. However, from a technical perspective these improvement were not big in any major way. The upcoming Buffalo III-SE follows that same evolutionary approach of adding user requested features.

On the other hand, I think the introduction of the Buffalo II DAC represented a “quantum leap” to everything TwistedPear Audio had produced up to that moment.  In a way The Buffalo II DAC represented the “Aha!” product for Russ and Brian. Not only was the Buffalo II DAC solidly engineered, but its built quality was top notch surpassing even commercial offerings, and it was also popularly priced. Finally, there it was: a state-of-the-art DAC available for the do-it-yourselfer.

The fact that Russ and Brian shared a lot of information in public forums during the development of the DAC also adds to the value of this product. You get to know some of the “hows” and the “whys”.

As one of the earlier owners of the Buffalo II, I am a big fan of the DAC and right now I do not feel a need for upgrading either to the latest offerings or a competitive product. Just like any diyer, I have spent time adding capabilities and modding the device and in this post I share what I have done to “improve” upon this DAC.

In keeping with the spirit of this blog, the Buffalo II DAC, especially with the improvements I’ve implemented represent a lot of value, little money 🙂



The first implementation by Twistedpear Audio of the Sabre DAC was the Buffalo I (04/2008). I think his DAC was designed “by the book” following the recommendations from the factory as the configuration is similar to that of the application note and the evaluation board.

This was a two layer PCB, using “out of the mill” regulators for the digital supplies, supply capacitors and oscillator. The choice of an oscillator was already an improvement over the use of a crystal in evaluation board (shown below [link]).

The implementation of the critical analog supply, the AVCC, was as recommended in the ESS application note [link] with DVCC is used as a reference to the regulating opamp. This configuration provided a low impedance supply to the analog pins [link]. But he main drawback was the pretty nonexistent PSRR (power supply rejection ratio), so the PSRR of the analog supply was pretty much the PSRR of the DVCC that was used as the reference [link].

The Buffalo I DAC was a real bargain. Priced at $149, it was priced evenly with the WM8741-based OPUS and WM8804 receiver combo and threw in an ASRC (as an integral part of the DAC) for free. This was during the time TPA products did not have the demand they do today and Russ/Brian were basically doing this for fun and for beers :-).

About a year later came the Buffalo 32S which implemented the output stage right on the board. There were many improvements including using a very low phase noise clock from Crystek (top of the line) which is still in today for the Buffalo III and Buffalo IIISE, and low noise regulators with OSCON capacitors; the AVCC was still based on the factory recommendation but the reference was now provided by a lower noise regulator to that used in BI. There was also an option to use an external AVCC instead of the on-board AVCC, but this was left to the implementer.

The 32S was a big improvement over the Buffalo I DAC.

The AVCC (“filter”) was split in two physically separate supplies to feed L and R channels. It was based on two LM49710 single opamps whereas the Buffalo I AVCC (“filter”) was based on a single LM49720 dual opamp. (Keep in mind that the AVCC consist of a reference voltage and the opamp based filter. The reference voltage was provided by the 3.3v regulators)

There was even a “tweakers” version of 32s in the works that never saw the light of the day:

The seeds for the modern AVCC (found in Buffalo II and III) were already planted during the time of the Buffalo I. A mod was proposed by Russ to replace the reference voltage (which was provided by the lowly DVCC regulator) with an LED-based reference [1038], [1073] which had much, much lower noise. Some users immediately implemented it as shown in the photo below by AVR300 [1167].

Russ had this to day about the VREF mod [1168]:

The VREF mod is meant to lower broadband noise and totally decouple the analog supply from the digital supplies (actually the decoupling was the main goal) and it does this very effectively. The reason why the decoupling was key is because it is easier for the output stage to reject low frequency than the 40-80-160 MHz found present on VDD. The VREF mod simply makes the outputs have a lot less crud for the output stage to have to filter out or reject…

While we want to lower the corner on the noise as much as possible, anything below 100 Hz will be very easily canceled by the next stage as it is totally common mode to the analog output. This is the wonderful thing about differential analog outputs. If this DAC were single ended then you would have any AVCC noise directly super imposed on the signal and at low frequencies, this could very easily be audible. Not so with differential outputs.

Also remember that AVCC is a purely analog supply. Low impedance is actually far more critical than absolute (low) noise. It is not feeding a clock or something where we have jitter effects to worry about.

Further, the idea of a separate AVCC board were also incubated during this time [1197], [1114], [1320]


Around March of 2010, the Buffalo II was released. All the research, development and production knowledge that Twistedpear Audio was able to muster up to that point including community input and expert advise from ESS was invested in this product.

There is a DVCC pin in the AVCC header. Never been used for anything. Perhaps the last vestige of its Buffalo I ancestry 🙂

Also of note, although the AVCC header has four pins, only three are used by our AVCC module. The AVCC module does not use the DVCC pin. It is there as a convenience to any who might want to use an ESS demo board style AVCC supply (where DVCC is a VREF). Our AVCC module uses its own low noise VREF, not DVCC.

Russ explained the salient features of the new DAC [link]:

The new board builds on the experiences gained and I have put a lot of time and work into it. A lot of prototyping and proving ideas. A lot of “back to the drawing board” moments…

Also there is a wicked cool little plug-in extremely low impedance/low noise shunt regulator for AVCC that is something very special. It solves a lot of technical hurdles which have always been present, and are not simply remedied. It is the best solution I have found so far…

The layout is optimized with an eye on EMI and especially to get the most out of the chip. I really worked hard on the ground plane strategy and the supply bypassing. Buffalo was a good first effort, and Buf32S grew into something incredibly successful and personally satisfying beyond my hopes. Now, “Buffalo II” as I am calling it is a natural evolution based on the experience and success of those two projects (not to mention the COD and Opus) as well as the result of requests many people had. This new PCB fulfills many of my own wants and brings to fruition some my own new ideas. I didn’t want to just “redo” Buffalo. Really, what I wanted was to draw inspiration from it while working on something much better.

It has been a long time coming, but that’s because the new design took a lot of work to get right. Lots of prototyping bits and pieces and working details out. I am a designer. The joy is not just in the result, but the work.

The use of a 4-layer board is evident in the darker color of the board. 4-layer layout allows for a more solid ground plane and the tight bypassing around the DAC chip for improved noise suppression which is key to getting the highest performance possible of the chip.

According to the ESS application note:

The most important for DAC performance is the ground plane, it should be as solid as possible with as few traces routed through the ground plane as possible. Any traces that are routed through the ground plane and block the “line of sight” from the DAC output to the opamp output stage significantly degrades the output THD…

Make the ground plane as solid as possible. Try to keep all ground connections as short as possible. Every ground connection should have its own via, do not share vias if possible.

Ensure every opamp and DAC has decoupling capacitance on its power supply right next to the power supply pins.

Try to keep the digital circuitry away from the analog circuitry.

The clock used was the top-of-the-line ultra low noise Crystek CCHD-950 first in 80 MHz and later upgraded to 100 MHz for better support for 352.8 KHz and 384 KHz sample rates and even lower phase noise.

Note: my testing indicates that an 80 MHz clock cannot support playback of 352.8 KHz material [link].

The selection and use of this oscillator was a big deal; the use of such high quality oscillator was hardly seen in any other diy or commercial implementation. TPA could have been the first one using the CCHD-950 clock in a DAC. More information here [link].

Here is a photo of the CCHD-950 100MHz clock from Crystek as implemented in a carrier board designed by Iancanada over at diyaudio.

The form factor of the Buffalo II was consistent with that of the Buffalo I and departed from the “all integrated” approach of Buffalo 32S. This allowed not just complete separation of the analog parts from the digital parts but also the flexibility of using different output stages or no output stage at all. The vertical plug-in approach for the output stage, first envisioned in the Buffalo I, remained in the design and allows for “as close as possible” integration of the output stage as recommended in the application note:

– The audio path between the DAC and the opamp stage should be kept as short and clean as possible.
– The audio path after the opamps is not as critical.
– Try to keep the digital circuitry away from the analog circuitry.

Input configuration

The inputs to the BII (and also to the B32S and BI) were configured in a way that allowed automatic detection of SPDIF, I2S and DSD. However, in order to use SPDIF, one had to remove the wiring for I2S. But if one wanted to use I2S and DSD, the same wiring could be used. I have recently configured the Amanero USB interface and it can play I2S and DSD through the exact same connection to the BII [link].

The input configuration of BII is illustrated below when the input is I2S and DSD. In this configuration BII can automatically switch from I2S and DSD:

In DSD, DSD clock = BCK, DSD1=LRCK and DSD2=DATA

Single SPDIF input.

The way BII (and predecessors) inputs are configured only allow the use one SPDIF input even thought the DAC and internally switch between 8 SPDIF inputs.


Sadly, the Buffalo II is no longer in production and with that, the old $249 price tag is also gone. If you are looking for a Buffalo DAC, it’ll have to be the Buffalo III and with price tag of $379. Still a good deal considering the enhancements and included Trident regulator set, but not the great deal that was the Buffalo II.

Nowadays, $250 gets you a Dragonfly…

Lately I’ve learned that TPA outsources their boards to be professionally manufactured. In the old days they did all their products by hand in a reflow oven. I don’t know if BII was manufactured by hand or outsourced to a professional shop. Looking at the quality of built, it definitely look professional.

The Buffalo DACs have had a tremendous demand. They are so HOT that often they are sold out minutes after they become available. They are the iPhones of the DAC world :-). No doubt this has pushed pricing towards the more premium side even if offering more for the money. Maybe Russ and Brian are now living in a Pacific island and drinking beer all day since they are making a lot of money and have outsourced their manufacturing 🙂



DAC chips have included a software interface for a long time already. It is only recently that the audio community has started using it to access all the features that are supported by the chip. In particular the audio do-it-yourself community has been even slower in targeting the software interfaces that are available in many audio chips.

An outboard micro-controller with custom firmware is used to set and enable the different options available in the Sabre32 DAC. The out-board micro-controller provides similar functionality as the on-board micro-controller in the Buffalo DAC but allows for much greater flexibility such as adding a display, remote control and knobs and switches to select various parameters. It is more flexible it uses a more capable device and because it has more input/output pins. But hardware has to work with software and in order to provide the utmost flexibility, the source should be “open source”. I’ve made the custom firmware open source so that users can add and modify the code at will.

The Arduino platform was selected for this task because it is an open system and provides an easy learning curve for non-programmers and there is a vibrant community that provides a lot of sample code and support. Additionally, the Arduino community has been growing tremendously enabling a proliferation of both hardware and software products for a variety of applications.

Hifiduino was created not only to document my own learning process in programming modern DAC chips, but to share the knowledge and code. This is consistent with the “Arduino spirit” of open hardware and open source.

The current version of the code represents the time and effort I have invested in making all the features supported by the chip available for user selection, in ensure rock-solid stability, and in providing a comprehensive and yet easy to use user interface.

Using an outboard micro-controller has the additional benefit of lower noise in the Buffalo II because there, the 3.3V is taken from the 3.3V supply that also is used to power the DAC. According to the ESS Sabre application note [link]:

To minimize the risk of digital noise affecting the performance of the DAC, a separate +3.3V supply powers the micro-controller.

Many people throughout the world have downloaded the software and implemented Hifiduino for their own Sabre32 based DAC. Some people have added code (for example, to drive input selection relays) and some have even re-architected the code into their own liking.

If you want to get your own “Hifiduino”, here are a few links to get you started.

  • How to implement the outboard controller with Arduino: [link]
  • Latest Arduino code: [link]. Current version is compatible with Buffalo II and Buffalo III in Stereo and Dual Mono configurations.
  • Latest user interface: [link]


A datasheet is essential for the understanding of the chip. Unfortunately, the datasheet for the ESS DAC is very basic and only provides “sufficiently minimal” information to program the chip. If you get a hold f the ESS9018 datasheet it immediately becomes evident that It is not up to the level of content and format as those provided by companies like Wolfson and Texas Instruments. In addition, it is not freely downloadable and you need to petition the distributor for a copy. In the old days you even had to sign an NDA. I don’t know what the reason is for being so restrictive in making the datasheet available. Perhaps it is because it does not look “professional enough” like the ones from other companies?

If you need support, the company would ignore you if you are not a factory. ESS does not have a discussion board and would not reply to your email. Other companies have a more proactive approach in supporting the end user. In the past I’ve written to Wolfson asking questions about the WM8471 and have received information and support. It seems as though ESS is discouraging the use of the chip.

Luckily Dustin Foreman, the lead designer of the chip was answering questions in the diyaudio forum.  But as of late, he has disappeared from the forums.

In order to remedy the lack of information in the datasheet, I’ve compiled publicly available information from different sources including the contribution from Dustin and have documented it all in a dedicated page [link].


Having the microprocessor off the DAC board and having its own power source already allows for lower noise. If that is not enough (nothing is ever enough for audiophile :-)) one can isolate the I2C lines with an I2C isolator such as the ADUM 1250 [link] (Digikey: $6). This way, whatever noise is generated by the micro-processor itself is totally blocked both through the signal lines, the power line and the ground line.


A remote control is an essential feature for any audio control. I first used a Sony remote control and fount it not very user friendly. There were just too many buttons and I only needed a few functions. The only one thing that was going for the Sony was that it was the “easiest to program” at least for me.

Around the same time, Apple developed a remote control with a very simple user interface. When the aluminum version came out I quickly embarked in writing code for it. For the way I wrote the code, I needed the Arduino people to fix a piece of code in the Arduino software. Luckily it was fixed shortly after in the new release

The Apple remote is the best fitting remote control for this project. It is widely available can be had for about $20. Here are the things I like the most:

  • Aluminum Unibody construction: solid feel
  • Textured finish: good grip
  • Perfect dimensions and weight: feels good in your hands
  • Intuitive key layout: instant recognition by feel/ touch alone
  • One finger operation: all keys within reach of, and operated by the thumb and without having to move the position of the remote in your hand
  • Double-bevel design: tap down one side, the other raises to allow easy grab

The more I use the remote, the more I appreciate its design an simplicity. There is never a need to go hunting for a specific key. You know exactly where the keys are. In comparison, the typical remote controls have keys in seemingly random order and no two remotes have the same layout. Most often I have to read the labels in order to figure out the keys even after using the remote for a long while.

More info here: [link]

Here is a look at the Apple remote from a designer point of view [link]


The existing regulators for the digital section of the BII are the LT1763 low noise LDOs with a specified noise figure of 20 uV RMS. There are already OSCON input capacitors on board. According to some reported measurements the noise figure can be further reduced by increasing the output capacitor. Thus I’ve added OSCON output capacitors by paralleling them to the existing ceramic output caps [link]

There are also the TPA Tridents shunt regulators that can be used to replace the existing series regulators. For now I am sticking to the LT1763 which I think are perfectly suited for digital power roles. This is what Russ said regarding the use of these series regulators in an early comment before the Tridents were available [link]:

While low noise is certainly desirable, the point of diminishing returns is hit pretty quickly in digital circuits once you get into the 10s of uV. You are in great shape for most of today’s digital ICs.

I only use the LT1763 for digital supply pins of DACs and the Crystek clock. Some would argue you need the lowest possible noise for clocks. And this is generally true. The reason the LT1763 is a good fit for the clock we use is because that clock in essence has a form of local regulation and decoupling internally. It is in fact a small circuit board. They need it that way because of the way they generate their output signal at low phase noise. 🙂 I won’t say much more than that. But suffice it to say it is a very well designed clock. if I were using a lesser clock I might choose a lower noise supply, but would anyone notice? Who knows.

It is key to look for line an load regulation (output impedance) when evaluating voltage regulators for digital use. Also, proper bypassing in digital circuits cannot be ignored, and it is far more critical than the choice between any two good voltage regulators.

As you can see no small amount of thought goes into choosing these things. And the measurements and listening tests bear this out.


There has been two versions of the Trident. Here is the comparison of the two side by side.

Trident V3 (there was no V2) [link] has the following:

  • A better error amp (OPA 2009)
  • A better local feedback scheme at the shunt.
  • A better layout with a spot for SMT CCS resistor – R4.
  • Some other very small circuit tweaks
  • Much more robust transistors. They will very easily handle any TPA app.


Experiments with measuring unlocks when the DPLL is set with lower values have shown that shielding of the DAC chip and board results in less amount of unlocks [link], [link]. Other manufacturers such as Anedio [link] enclose the DAC chip within a metal shield.

Putting the DAC board inside a case will result in similar benefits and shielding the DAC chip adds additional protection against potential RF/EMI from other components and wires inside the case. Photo shows the shield made of a piece of copper with two pin connectors soldered to the plate, then connected to the GND header pin.

I had installed the AVCC board at the bottom of the DAC board. It is possible that installing the AVCC the normal way (on the top of the board) would provide shielding to the DAC chip.


The AVCC analog power module is by far the most important power supply if the Buffalo II (and III) DAC. According to Russ:

I would say that the AVCC module is *the* single most important regulator on the Buffalo [link].


The most critical supply in the cct is AVCC, and I *VERY* carefully designed the solution there. It is the result of 2 years research and development. [link]

Even so, some users have reported some sort of instability in the AVCC supply (likely inaudible, but measurable nevertheless) as shown below [link]:

I’ve run up against a problem in that there is a 258kHz sawtooth ripple of about 62mV on both AVCC outputs of the AVCC module. The excursions of the ripple are around 3.20 mV to 3.82mV. Both DVCC supplies are clean. The frequencies of the left and right side ripples are not synchronized.


One thing you could do that might resolve the issue easily – overcompensate the opamps (it is a dual) with 22pf (22-100pf should be OK) from -IN to OUT. This will slow down the error correction slightly but will make the error amp rock stable. Perhaps there is some EMI that the AVCC module is sympathetic to. The attached PIC shows convenient soldering points in case you wish to try it.


I tried fitting 0805 COG caps as per your annotated layout diagram. I found that 100pF got rid of the oscillation completely. 47pF had no effect on it by the way, so I went straight to your suggested maximum value.

There has been reports of the old AVCC causing a high pitch noise [link]

Note: the new version of the AVCC board will fix this problem by using a different opamp (OPA 2209) and adding the compensation. See below

New AVCC Module

A new AVCC supply is being developed by TPA [link]. Here is a photo of the prototype compared with the original version

According to TPA, the new AVCC module improves in the following areas:

  • Improved error amp (TPA indicated it is the OPA 2209. The original opamp is the LMP 7732. The two are pin compatible)
  • Better local feedback around at the shunt element by adding degeneration. This promotes better stability and RF rejection.
  • Compensation added to the feeback loop to give the circuit a much improved phase margin. It is as a result very stable and rejects EMI better. (This is very likely the same compensation described in the “AVCC instability” section below)

I may try updating the opamp and adding the compensation to the original version. Russ specifies that the opamp can be replaced with an OPA 2009 or OPA 2011 on the original Trident supply [link]

But before doing any mods, lets check the comparison of LMP 7732 with OPA2211 and with OPA2209

Parameter TI LMP7732
OPA2211 OPA2209
Input offset (max)
0.006 mV 0.030 mV
0.035 mV
CMRR (typical)
130 dB
120 dB
120 dB
Input Voltage Noise Density
2.9 nV/sqrHz
1.1 nV/sqrHz
2.2 nV/sqrHz
slew Rate
2.4 V/usec
27 V/usec
6.4 V/usec

Hmmm… There doesn’t seem to be much improvements switching from LMP7732 to OPA2209. The only real difference is the voltage capability of the OPA part which is a 36V part compared with the LMP part which is a 5.5V part. I think adding the compensation capacitors could result in good improvement.


My journey into DIY audio started with the OPUS DAC (WM8741) from Twistedpear audio. Unlike many other implementations, this DAC did not block the use of its software interface but had dedicated pins for interfacing with an external microprocessor. That got me interested in programming these chips. At the same time, Arduino was becoming popular and that enable me to jump into “HifiDUINO”. And so, I am thankful to the folks at TPA for getting me started in this hobby, and for all those that are happily using the Hifiduino code 🙂

  1. SunRa
    October 25, 2012 at 09:13

    Very cool article, thank you for posting all this useful info in one place, it is very much appreciated!

    • BlogGeanDo
      October 25, 2012 at 15:39

      That was one of my goals too: have everything handy in one place. It became difficult to find stuff especially since forum threads now run in the thousands of posts…

  2. avr300
    October 25, 2012 at 17:14

    Very nice writing.

  3. Coris
    October 25, 2012 at 18:27

    Very well done this article. Nice to have all in one place. Thanks for the work!
    Maybe one day one can find an answer to: why ESS9018 it behave (sonic/perceptual point of view) better at the higher clock frequencies than what is specified in the producer data sheet?

    • BlogGeanDo
      October 26, 2012 at 05:28

      It would be nice if Dustin were still answering questions in the forums. Yeah maybe we’ll figure more stuff in the future. I am still trying to find some hints in programming the internal filters. Seems the only shop is being able to do that and those are the folks who worked for ESS designing the DAC (so they have inside information)

  4. t28
    October 27, 2012 at 12:57

    Very nice.
    And it is sad that Dustin is no longer around.

  5. October 6, 2013 at 07:48

    Hi, how to play dsd with mac osx/amanero/buffalo2 ?

  6. September 14, 2016 at 15:21

    Urology doctor

  7. September 14, 2016 at 15:38

    serial number free

  8. September 14, 2016 at 15:39

    harrisburg dui attorney

  9. September 14, 2016 at 15:41

    Medical Marijuana Jobs

  10. September 14, 2016 at 19:12

    sexo guarras

  11. September 14, 2016 at 19:20

    chapter 13

  12. September 18, 2019 at 19:41

    Amazing post. Do you have any other ones you can share? I highlyrate super stuff. 🙂

  1. October 24, 2012 at 20:27
  2. October 12, 2014 at 03:13

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