Buffalo2-Sabre32 DAC MEGA Test

MOTIVATION

I Decided to figure out how the Sabre32 works in the Buffalo II implementation with respect to quantization bit depth, input mapping, polarity and true/pseudo balanced mode. The Sabre32 data sheet gives NO information in this area, but these topics have been discussed to some degree by the designers at diyaudio for the benefit of us audio tweakers. My starting point was post 35 by Dustin Forman in the monster ESS Sabre Reference DAC thread.

Although the information contained in that thread seems complete, it is not easy to understand. The ensuing discussion on the topic by different members of the forum left questions in my mind. Therefore, in order to get a better understanding the behavior of the DAC I had  to test it myself.

I wrote a huge case statement and used the rotary encoder to move from one test to another [another advantage of having a rotary encoder]. Here are the results.

For reference these are the Sabre32 Default register settings at power-on:

• Quantizer: 6-bit
• DAC Phase: In-Phase
• DACB Phase: Anti-Phase
• Differential: True
• Input Map: Normal

TEST RESULTS

Input mode tested: I2S and SPDIF. Results apply to both unless noted in the results column

#	Q	DACB Phase	Diff	Input Map	Results
1	6-bit	Anti-Phase	True	Normal	I2S:Sound is ~6dB lower –> Half of the DACs are not used; SPDIF: Normal sound. In SPDIF mode, the DAC is automatically set to STEREO mode, utilizing all the DACs
2	6-bit	Anti-Phase	True	B-II	Normal sound. In I2S, BII wiring corresponds to the input channel Remap, thus all the DACs are used
3	6-bit	In-Phase	True	Normal	No sound –> True diff cancels out sound as expected
4	6-bit	In-Phase	True	B-II	No sound –> Same as above
5	7-bit	Anti-Phase	Pseudo	Normal	I2S: Sound is ~6dB lower –> Half of the DACs are not used because they do not have input signals; SPDIF: Normal sound. In SPDIF mode, the DAC is automatically set to STEREO mode, utilizing all the DACs
6	7-bit	Anti-Phase	Pseudo	B-II	Normal sound as expected
7	7-bit	Anti-Phase	True	B-II	Normal sound –> True differential is also supported in 7-bit mode for both SPDIF and I2S
8	7-bit	In-Phase	Pseudo	Normal	I2S: Distorted sound, ~6dB lower –> Half of the DACs are not used and Pseudo diff does not cancels out sound; SPDIF: Distorted sound (heavier because all DACs are used). Not expected as DACBx being in-phase should cancel-out the sound of DACAx which is also in-phase
9	7-bit	In-Phase	Pseudo	B-II	Distorted sound, normal level –> All channels are used in both I2S and SPDIF. Pseudo diff seems not an exact anti-phase of the signal as there is no full cancellation. This is not expected behaviour
10	7-bit	In-Phase	True	B-II	No sound –> exact anti-phase cancels out sound as expected
11	7-bit	Half-Half-1	Pseudo True	B-II	I2S: Distorted, but less distortion than #9 –> Half the DACs anti-phase contributes to normal sound, half of the DACs in-phase contribute to distortion. SPDIF: Distorted sound full volume as all the DACs are used.
12	7-bit	Half-Half-2	Pseudo True	B-II	I2S: Distorted, but less distortion than #9 –> Half the DACs anti-phase contributes to normal sound, half of the DACs in-phase contribute to distortion. Should expect normal sound if using normal input map (In normal map, the DACs contributing to the distorted sound will not be connected). See test #28. SPDIF: Distorted sound full volume as all the DACs are used
13	8-bit	Anti-Phase	Pseudo	Normal	I2S: Normal sound –> In 8-bit, only half the DACs are used according to post 35 even though BII wiring only feeds half of the input channels; SPDIF: Normal sound as expected
14	8-bit	Anti-Phase	Pseudo	B-II	I2S: Normal sound –> In 8-bit. This test and test 13 shows that it does not matter whether in Normal or B-II input mapping; SPDIF: Normal sound
15	8-bit	Anti-Phase	True	B-II	Normal sound –> True differential is also supported in 8-bit mode for both SPDIF and I2S
16	8-bit	In-Phase	Pseudo	Normal	Distorted sound –> All channels are used in both I2S and SPDIF. Pseudo diff seems not an exact anti-phase of the signal as there is no full cancellation
17	8-bit	In-Phase	Pseudo	B-II	Distorted sound –> All channels are used in both I2S and SPDIF. Pseudo diff seems not an exact anti-phase of the signal as there is no full cancellation. As found in other tests, in 8bit mode the input mapping does not matter
18	8-bit	In-Phase	True	B-II	No sound –> As expected. In true differential, the anti-phase signal is the exact 180 degree signal
19	8-bit	Half-Half-1	Pseudo	B-II	Distorted sound
20	8-bit	Half-Half-2	Pseudo	B-II	Distorted sound
21	9-bit	Anti-Phase	Pseudo	Normal	Normal sound
22	9-bit	Anti-Phase	Pseudo	B-II	Normal sound
23	9-bit	Anti-Phase	True	B-II	Distorted sound. True differential is NOT supported when 9bit is used. In I2S I noticed increased volume of distortion. I don’t know what this means. I did not compare distortion levels when using SPDIF input
24	9-bit	In-Phase	Pseudo	Normal	Distorted sound
25	9-bit	In-Phase	Pseudo	B-II	Distorted sound
26	9-bit	Half-Half-1	Pseudo	B-II	Distorted, In I2S I noticed the least amount of distortion. I don’t know what this implies. I did not compare distortion levels when using SPDIF input
27	9-bit	Half-Half-2	Pseudo	B-II	Distorted sound
					Additional Tests
28	7-bit	Half-Half-2	Pseudo	Normal	I2S: Normal Sound, ~6 dB lower volume. –> Indicates that DAC channels 3,4,7,8 are not being used because they are in-phase pseudo differential and as such (if used) they should distort the sound according to tests 11 and 12; SPDIF: distorted, since all channels are used in 7-bit regardless of input mapping
29	9-bit	in-Phase	True	B-II	No sound. Although this seems to be the correct behavior, it does not agree with test #23, where the anti-phase signal results in distorted sound in true differential mode

The following tests (30-37) are designed to test one channel at a time with true differential mode. True differential works For 7bit and 8bit as tests 7 and 15 show for anti-phase and tests 10 and 18 show for in-phase. Now, selecting a single channel anti-phase with the rest in-phase for DACBx should result in normal sound (at lower volume level since only one DAC out of eight does not cancel out).

However,  the results below show that except for 6-bit, the sound is distorted. I cannot explain why the sound is distorted…

Input: I2S. for SPDIF I only tested 7bit, normal input mapping

#	Q	DACB Phase	Diff	Input Map	Results
30	6,7 8,9	in-Phase; ch1 anti	True	Norm B-II	Sound in LEFT channel only: 6bit: normal; 7,8,9bit: Distorted
31	6,7 8,9	in-Phase; ch2 anti	True	Norm B-II	Sound in RIGHT channel only: 6bit: normal; 7,8,9bit: Distorted
30	6,7 8,9	in-Phase; ch3 anti	True	Norm B-II	Sound in LEFT channel only: 6bit: normal; 7,8,9bit: Distorted. 8bit: also distorted but volume level is lower than ch 1,2,7,8
33	6,7 8,9	in-Phase; ch4 anti	True	Norm B-II	Sound in RIGHT channel only: 6bit: normal; 7,8,9bit: Distorted. 8bit: also distorted but volume level is lower than ch 1,2,7,8
34	6,7 8,9	in-Phase; ch5 anti	True	Norm B-II	Sound in LEFT channel only: 6bit: normal; 7,8,9bit: Distorted. 8bit: also distorted but volume level is lower than ch 1,2,7,8
35	6,7 8,9	in-Phase; ch6 anti	True	Norm B-II	Sound in RIGHT channel only: 6bit: normal; 7,8,9bit: Distorted. 8bit: also distorted but volume level is lower than ch 1,2,7,8
36	6,7 8,9	in-Phase; ch7 anti	True	Norm B-II	Sound in LEFT channel only: 6bit: normal; 7,8,9bit: Distorted
37	6,7 8,9	in-Phase; ch8 anti	True	Norm B-II	Sound in RIGHT channel only: 6bit: normal; 7,8,9bit: Distorted

TEST NOTES

1. When the sound is distorted, it is heavily distorted. Like a radio station not quite tuned into the correct frequency
2. In all tests DAC Phase is In-Phase (Each channel consists of a DACx and DACBx pair)
3. Normal input map: each channel maps to a separate input put (each pin requires input signal)
4. B-II input map: input pins are shared by two channels as specified here
5. Half-Half-1: DACB 1,2,5,6 In-Phase; DACB 3,4,7,8 Anti-Phase
6. Half-Half-2: DACB 1,2,5,6 Anti-Phase; DACB 3,4,7,8 In-Phase
7. All tests conducted with Buffalo II DAC without output stage. Balanced output feeds directly a UCD180HG balanced amplifier

CONCLUSION

From a theoretical point of view, there are still questions… From a practical point of view though, there are 6 configurations that are supported by the Buffalo II implementation of the Sabre32 DAC (that is, using the input remap to match the pin wiring):

1. 6bit, true differential
2. 7bit, pseudo differential
3. 7bit, true differential
4. 8bit pseudo differential
5. 8bit true differential
6. 9bit pseudo differential

I plan on adding these 6 selections on the next revision of the software.

REFERENCE

Sabre8 GUI application: [link]. This application also includes a help file where you can find out information about the register settings that is not included in the data sheet.

Buffalo III DAC

Buffalo III DAC, top layer

Buffalo III DAC, bottom layer

Starting from May of 2008, TPA has introduced new version of the Buffalo DAC about one year apart: Buffalo, Buffalo32, Bufflao II. Buffalo III is the 4th generation.

Whereas Buffalo II aimed maximizing the performance afforded by the Sabre32 DAC, Buffalo II aims at maximizing the features that are available in the Sabre32 DAC while retaining all the performance of Buffalo II.

FEATURE COMPARISON

Feature	BIII (B3)	BII (B2)
DAC Digital Power	External (Tridents)	Built-in LM1763 regulator with ferrite filtering
DAC Analog Power	External: AVCC board	External: AVCC board
Microprocessor Power	Built-in, separate from DAC power	Built-in, tapped from DAC power
SPDIF Inputs	8 separate sources, selectable	1 (Auto detect)
SPDIF Signal Comparator	None. Requires that SPDIF signals be TTL-level (3.3v)	Built-in. Can by bypassed
I2S Inputs	1 Source, 1-2-4 channels (1)	1 (Auto detect)
DSD Inputs	1 Source, 1-2-4-8 channels (1)	1 (Auto detect)
Output configuration	Mono, stereo, quad and 8-channel, depending on input configuration (2)	Mono and stereo
Volumite support	Global volume control (not per channel)	Global volume control (not per channel)
On-board dip-switch configuration	16-switches for input/output configuration control, filter selection and modulation bit-depth control	4-dip switches for MONO/Stereo, FIR filter (fast/slow) and IIR filter (PCM/DSD)
Arduino Support	No limits on input/output configuration (3)	Cannot support quad and 8-channel because the input pins have a fixed configuration
PCB	4-layer with routing and bypassing optimizations over B2	4-layer
Board Size	2.1” x 3.7”; same hole pattern as B2	2.0” x 3.3”

NOTES:

• (1) Sabre32 supports a single source clock (PCM or DSD bit clock) for I2S and DSD no matter the number of channels. It can support up to 4 I2S input L+R channels and 8 DSD channels. Supporting multiple I2S or DSD sources requires external MUX. Another way to understand this capability is the following:
• I2S can support dual-dac (Quad-channel), quad-dac (STEREO) and 8-dac (MONO)
• SPDIF and DSD can support single-dac (5-to 8 channel),  dual-dac (Quad-channel), quad-dac (STEREO) and 8-dac (MONO)
• (2) As shown in the layout diagrams, you can fix the input and output pin configuration with jumpers. This requires matching that configuration with the on-board dip switches
• (3) B3 obviates some of the need for an external controller because the on-board 16 switches enable a wider range of selection as compared with B2. Support for a display, however, requires an external controller such as Arduino or the forthcoming AC2

Update to the Musiland Power Mod

Minimizing Switching Regulator Residue in Linear Regulator Outputs is an application note describing the use of ferrite beads to eliminate high frequency spikes from switching supplies.

Designers frequently use linear regulators to post-regulate switching-regulator outputs. The benefits of this approach include improved stability, accuracy, and transient response, along with lower output impedance. Ideally, markedly reduced switching-regulator-generated ripple and spikes would accompany these performance gains. In practice, all linear regulators encounter some difficulty with ripple and spikes, particularly as frequency rises.

The USB power feeding the Musiland MINI in my setup comes from switching regulators inside the computer and thus prone to have spikes [I can't measure these with my low-end scope, but lets assume they are there].

Apple Aluminum Remote Codes

Update (5/17/12): A reader alerted me that the command code all Apple remotes is only 7 bit, with the last bit being a parity bit. If we then only use the 7 most significant bits, then there is no such thing as an “odd” code. All the codes for all versions of the remote are the same. I’ve summarized the new information here: [link]

Update: I’ve set up a separate page to gather all the relevant information regarding the Apple Remote in one place: [link]

Previous posts [link1, link2] discussed using the Apple aluminum remote as the IR remote of choice as in interface to Arduinto to control the volume in the Buffalo II DAC. In this post I  to explain the meaning of the codes emitted by the remote.

REMOTE CODES

The codes from the remote are:

Up key:     238 135 011 089
Down key:   238 135 013 089
Left key:   238 135 008 089
Right key:  238 135 007 089
Center key: 238 135 093 089 followed by 238 135 004 089
Menu key:   238 135 002 089
Play key:   238 135 094 089 followed by 238 135 004 089

in Hex:

Up key:     EE 87 0B 59
Down key:   EE 87 0D 59
Left key:   EE 87 08 59
Right key:  EE 87 07 59
Center key: EE 87 5D 59 followed by EE 87 04 59
Menu key:   EE 87 02 59
Play key:   EE 87 5E 59 followed by EE 87 04 59

Keep in mind that these are the codes I extracted from my remote.

The remote codes are sequences of 4-bytes. The first two bytes I believe, represent a company code as they are the same for every single remote from Apple, including the original white remote. You can see evidence here where the codes for the white apple remote have been extracted.

For the white Apple Remote, the codes are:

Up key:     EE 87 0B XX
Down key:   EE 87 0D XX
Left key:   EE 87 08 XX
Right key:  EE 87 07 XX
Menu key:   EE 87 02 XX
Play key:   EE 87 04 XX [same as center key and play key in Aluminum remote]

I use XX to indicate that this is different for each remote.

Notice that in order to maintain compatibility, the center key and the play key in the aluminum remote has the same codes [the second set of codes] as the play (center) key in the white remote

The fourth byte is the remote ID and it is used to pair the remote to a particular Apple device and it is different with up to 255 variations. These remotes have different IDs in order to support “PAIRING”. Pairing is a feature of Apple devices where you can set a device to listen only to a particular remote.

This ID can also be changed in the remote by pressing a combination of keys. This paper explains how this works and more. Basically you hold the menu key and the center key for 5 seconds and the ID increments by one. This is useful if you happen to have two remotes with the same ID and you need to pair them to different devices.

The third byte is the one that is mapped to the individual keys. Notice that the aluminum remote emits and additional set of codes in order to differentiate the center and play keys. In my code I ignore the first, second and fourth bytes and only use the third byte.

“ODD CODE”

There exist an “odd” set of codes for Apple Aluminum Remote that a reader found out while using remote code. The only difference with the “standard set” is that the third code is changed by the value of 1. I am not sure why this “feature”…

Update: Apparently, this set of code is not “odd” at all. Other readers have reported that their remotes emit this set of codes [link]

Update (6/5/11): the remote that comes with the Apple TV2 also emits this set of codes. I just tested mine and can confirm that this is the set of codes from the bundled remote. The Apple TV2 works with either remote (accepts both set of codes)

Up key:     EE 87 0A 68
Down key:   EE 87 0C 68
Left key:   EE 87 09 68
Right key:  EE 87 06 68
Center key: EE 87 5C 68 followed by EE 87 05 68
Menu key:   EE 87 03 68
Play key:   EE 87 5F 68 followed by EE 87 05 68

If you come across an apple remote that does not work, you can change the s/w to use this set of code instead. You can also enable the debug feature in the s/w in order to see what codes are emitted by the Apple remote.

This is the code section to change. For the “odd” codes change “case 11″ to “case 10″ and “case 13″ to “case 12″

switch(IRkey){
case 11: // 11 is the up key, we will use for volume up
…
break;
case 13: // 13 is the down key, we will use for volume down
…
break;
…

Troubleshooting

If all fails, you can test if the remote is actually emitting IR signals by pointing the remote to a video camera. [Apple remote troubleshooting doc]

Apple Remotes: Aluminum and Original

Musiland MINI Power Mod: Less Jitter?

Most people’s idea to improve the power of a USB device is to replace the USB power with an external linear supply. Although this kind of mod would improve the incoming power to the device, the ultimate noise performance is determined by the local regulators that directly feed the chips.

Additionally, because I value the convenience of using USB power, I took a different route: I decided to replace the local regulators with low noise types. The factory regulators are  AMS1117. The ones I am upgrading are LT1963. Noise density figures for the AMS1117 is approx 990 nV (3.3v regulator) and for the LT1963 is approx. 125 nV (3.3v regulator).

The AMS 1117 regulators are similar in noise performance as the very popular LM317 types. The LT 1963 are cousins of the LT 1763 used in Buffalo II. They have higher noise (but are still low noise) due to their higher current carrying capability.

Further Experimenting with SDTrans 3.0

Update (6/9/11): The latest version of the Hifiduino code with settings for the quantizer bit length greatly reduces this noise problem [link]

…Last day with SDTrans. My loan period is over

I would like to express my gratitude to Mr. Bunpei for graciously offering to loan me the latest version of the transport.