Home > Arduino, Code > Hifiduino Code and Buffalo III DAC

Hifiduino Code and Buffalo III DAC

HOW COMPATIBLE IS THE HIFIDUINO CODE WITH THE BUFFALO III DAC?

People have successfully used the HIFIDUINO code with the Buffalo III DAC, and I have generally said that “it should work”, but I had never tried to figure out whether there are any incompatibilities, inconsistencies or bugs when used with the Buffalo III DAC, primarily because I didn’t one have to test with.

I’ve now decided to do some theoretical study on how compatible is the HIFIDUINO code with at least the “commonly” (or default) STEREO or MONO configured Buffalo III DAC. I am doing this to satisfy my own curiosity and to give confidence and peace of mind to those using the code for the Buffalo III DAC, which I believe is now more widely used than the Buffalo II DAC. As audiophiles, we care as much about sound as the “perfection” of the audio chain :-)

BUFFALO III “DEFAULT” CONFIGURATION

Based on the BIII integration guide, the default STEREO configuration (jumpers, connections and dip-switch selection) for I2S and DSD is as such:

For reference, here is the configuration for Buffalo II on which I test my code. We will compare the Buffalo III input configuration with the input configuration of the Buffalo II DAC. If we find that the two are equivalent, then as far as the code is concerned, there is no incompatibilities to worry about. The code can’t tell whether it is controller a Buffalo II or Buffalo III DAC as they are based on the same chip and the only difference is how you configure the inputs.

ANALYSIS AND OBSERVATIONS

The first thing we observe is that the Bufalo III DAC default DSD configuration is “covered” by the BII input configuration. In other words, the wiring for the Bufalo III DAC for DSD is a subset of the wiring for the Buffalo II DAC. Both configurations require that you remap the inputs

How about for the I2S configuration?

Notice that the default Bufalo III DAC configuration for I2S does not require that the inputs be remapped. But for the DSD configuration, input remapping is required. Wouldn’t it be nice if for both configurations we can use the same “input remapped” setting? This would eliminate the need to be changing the input mapping configuration every time you switch between a PCM source to a DSD source

Thus, if we remap the inputs (which is just a software register setting), we can remove one of the jumpers and still feed all the internal DACs like this:

We notice that there is no use for Data 3; but we also know that there is no harm having a live signal on that pin (because the same thing happens in the BII without adverse effect) and thus, there should be no harm even if you leave the 3rd jumper in place.

With this equivalent configuration for the Buffalo III DAC for I2S, we also realize that it is covered by the Buffalo II input configuration.

FULLY COMPATIBLE

Because in the default configuration, the Buffalo III DAC input wiring is equivalent to the wiring of Buffalo II DAC, the HIFIDUINO code is fully compatible with the default STEREO configuration of the Buffalo III DAC, whether in its I2S mode or in its DSD mode.

By extension, therefor, the code is also fully compatible for a DUAL MONO BUFFALO III configuration.

HOW ABOUT 8-CHANNEL MODE?

The first thing to do in order to support 8-channel is to undo the input remapping. This can be done in register 14:

Register 14

|0|x|x|x|x|x|x|x| Source of DAC8 is DAC8 (D)
|1|x|x|x|x|x|x|x| Source of DAC8 is DAC6 (Use this to match BII input wiring)
|x|0|x|x|x|x|x|x| Source of DAC7 is DAC7 (D)
|x|1|x|x|x|x|x|x| Source of DAC7 is DAC5 (Use this to match BII input wiring)
|x|x|0|x|x|x|x|x| Source of DAC4 is DAC4 (D)
|x|x|1|x|x|x|x|x| Source of DAC4 is DAC2 (Use this to match BII input wiring)
|x|x|x|0|x|x|x|x| Source of DAC3 is DAC3 (D)
|x|x|x|1|x|x|x|x| Source of DAC3 is DAC1 (Use this to match BII input wiring)

Quantizer bit depth also affects input remapping as follows:

As you increase the quantizer bit size, the DAC internally turns off the digital sections for half of the DACs and replicates the output to all the analog sections of the DACs. Further increase of the quantizer bit size further turns off the digital sections for half of the remainder DACs resulting in using only one quarter of the digital sections of the internal DACs. Thus, whereas all the analog sections are always fully utilized, the number of channels available in the DAC depends on the quantizer setting as follows:

Setting
Quantizer Input Channels Used
Output
1 6-bit 8 (All) 8×1 – 8-Channle
2 7-bit 8 (All) 8×1 – 8-Channel
3 8-bi 4 (#1,#2,#5,#6) 4×2 – 4-Channel
4 9-bit 2 (#1 and #2) 2×4 -Stereo

This means that the only allowable quantizer setting for 8-channel is 6-bit and 7-bit. The current code supports all settings so in order to configure for 8-channle, you just make the correct selection in the user interface.

Therefor, the code can be made fully compatible with 8-channel by just making a small change in the code. When i get a chance I’ll incorporate this into the code and make it an option.

About these ads
  1. 2012/11/16 at 17:24

    Where can I read more about what the quantiser is for? I’m still a little sketchy on what it affects/is used for.

    • BlgGear
      2012/11/16 at 18:46

      In the Sabre32 Tab and look for “QUANTIZER SETTING”
      At the high level, it is related to the amount of noise generated in the DAC (but we are talking about noise that shows up in measurements and may or may not be heard)

  2. 2012/11/17 at 09:45

    You could add the possibility to use up to 8 inputs (or even more). This would make it even more compatible.

    There is one thing I don’t like very much about you code. This is the way the inputs settings are written to the EEPROM. Every time the the “select settings” menu is left all settings are written to the EEPROM, even when no settings have changed.
    The EEPROM has limited writing cylces, as you mentioned in my controller thread at diy audio. I have re-written this part of the code in a way that it checks if a setting has changed by comparing it to the value stored in the EEPROM. Only when a settings differs from the one stored in the EEPROM it stores the new setting. This saves a lot of writing cycles.

    I noticed that when fiddling around with the settings, the number of writing cycles easily exceeds a 1000. up to 100.000 writing cycles should be possible according to Atmel.

    • BlgGear
      2012/11/17 at 14:34

      Hi Corpius, thanks for your comment. And thanks for peer-reviewing my code. This is a good thing. Please continue to tell me which parts have issues/don’t like.

      You are right about the eeprom writing routine. I coded this a long time and did not reviewed and even forgot about it until know. At that time, I figure it would take me constant fiddling for 10 years before the EEPROM would fail. I also reasoned that if I listened to music half of those times, then that time frame would increase to 20 years :-)

      In addition, I was worried about code size and speed since I was using the smallest ATMEL chip of the time. So “speed” and small code size was a priority then.

      I think is very sensible to check before you write.

      I just had that first ATMEL chip failed, but I don’t think it was the EEPROM. Didn’t bother to trouble shoot the problem and just replaced with a new chip.

  3. Galvani
    2012/11/22 at 12:52

    hey glt

    thanks a lot for the code and the blog

    I am upgrading to buffalo III + teleporter + amanero setup (from BII)

    I’ve got the sidecar + spdif boards as well, but I was wondering if I wouldn’t be better off without them to get I2S as short as possible and without switches in the way. what do you think ?

    • BlgGear
      2012/11/22 at 17:18

      Unless you have to switch between I2S and another I2S/DSD source, there is no need to use sidecar. If you have spdif sources, then try the “smart wiring” I’ve documented to switch between I2S sources and spdif sources (requires some modification to the code). I have not personally tested this set up but even Russ said it should work. If you cannot mod the code, and have to switch between PCM/DSD and SPDIF, then you need to use sidecar. – I might write a version that will fully utilize the “smart wiring” configuration…

      Teleporter should be able to pass both PCM and DSD signals. So if your Amanero has to be situated far away, then use Teleporter to transfer the signals to the DAC.

      You know what they say: “less is more” :-). If things don’t work out, then start introducing more components…

  4. Galvani
    2012/11/22 at 21:04

    thanks for the advice…would you have the same approach for teleporter with amanero? is it better to use a long usb cable and keep the amanero combo inside the dac box or use teleporter/cat5 ?

    the other side of “less is more” is “if you already paid for it, you might as well use it” :)

    • BlgGear
      2012/11/24 at 03:42

      I would use longer USB cable and keep the Amanero near the DAC. The teleporter (as well as practically anything you add) will add jitter.

  5. Anonymous
    2014/04/05 at 19:20

    I use b11f. The line “if (digitalRead(4) == digitalRead(2))” uses hardcoded pins instead of the ones defined by VOLUPPIN and VOLDOWNPIN.

    • Anonymous
      2014/04/05 at 19:27

      Probably forgot about it :)

  1. 2012/11/28 at 15:16

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 )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 201 other followers