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.
H i F i D U I N O 
Where can I read more about what the quantiser is for? I’m still a little sketchy on what it affects/is used for.
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)
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.
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.
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 ?
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…
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” 🙂
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.
I use b11f. The line “if (digitalRead(4) == digitalRead(2))” uses hardcoded pins instead of the ones defined by VOLUPPIN and VOLDOWNPIN.
Probably forgot about it 🙂
I’m a bit puzzled: how do we know which DAC’s inside the chip are mapped to which DATA input pins? I cannot find this in the datasheet.
I understand the concept of remapping the DAC’s to other DAC’s but would like to understand how this relates to the mapping to the input pins of the DAC.
Or is it so that the mapping is as such:
– Data1 to Dac1
– Data2 to Dac2
– …
– Data8 to Dac8?
In the “normal” notation/configuration, one would assume Data1 corresponds to DAC1…
hot girls in yoga pants
jobs at mcdonalds