I performed a few experiments to check the feasibility of 90/98 clocks for DSD512 play under Amanero with Hermes/Cronus.
First the Amanero complex was connected to a BBB running Arch Linux to receive a native DSD512 source played by MPD on it and the output was sent to B3SEpro via Teleporter (and Otto II) as shown in the picture.
Results: The 90/98 clocks (actually 90MHz in this case) on the Cronus worked well for playing DSD512 in async mode. The SQ was quite satisfactory. The 45/49 clocks from Crystek also worked well in this setting, showing no stuttering in playing DSD512, though hampered by a continuous rumbling background noise.
Then the Amanero complex was directly connected to the B3SEpro, receiving upsampled DSD512 sources via USB from HQ player running on a linux machine of i7 6700k.
Results: There was severe pulsating noise when the DAC was set to sync (slave) mode by disconnecting the onboard XO, almost masking the music sound of DSD512. The DAC appeared trying to lock but could not achieve even after 10 minutes waiting. The situation became slightly improved when the sampling was changed down to DSD256 but could not eliminate the noise.
My tentative conclusion: It appears quite difficult to get optimal DSD512 sound in sync mode even using 90/98 clocks. Async appears to work quite well with these high speed clocks, whether using Amanero alone or using it in combination with Hermes/Cronus: probably reflecting the advantage of onboard XO, which was nicely placed in the vicinity of the Sabre DAC chip on the B3SEpro.
The development of Amanero firmware appears still in progress. My personal impression is that you can always resort to Botic-BBB/Hermes/Cronus if you really want to enjoy the sound of DSD512.
Regards,
Attachments
There are actually a few on-board firmware tweeks one could pursue if they plan to run dedicated synchronous master clock that I think definitely could make DSD512/1024 more solid.
The first would be to set the 128fs_mode register - this forces sync mode. The datasheet is somewhat ambiguous on it's effect for DSD (because it only mentions PCM) - but it is worth trying.
If anyone wants to try it I will create a branch for the on-board firmware.
The first would be to set the 128fs_mode register - this forces sync mode. The datasheet is somewhat ambiguous on it's effect for DSD (because it only mentions PCM) - but it is worth trying.
If anyone wants to try it I will create a branch for the on-board firmware.
Last edited:
Hi Russ, thank you for this encouraging suggestion. Though I'm quite satisfied with the current firmware of B3SEpro for ordinary DSD512 play in async mode, I'd like to try this particular firmware. It will be fine, if it is provided with a .hex file. I remember an AVR Dragon is sleeping in the corner of a box.
Regards,
Here it is for anyone who wants to try it:
AVR - ATTiny85 Fuse bytes:
Low: 0xE2
High: 0xD5
Ext: 0xFF
This firmware does not support SPDIF input - DSD/PCM only.
Switch one position one is reassigned to:
On = Normal Operation - DAC master clock can be async or sync.
Off = Sync Master Only (128FS flag set) - DAC master clock must be in sync with serial data.
Cheers!
Russ
AVR - ATTiny85 Fuse bytes:
Low: 0xE2
High: 0xD5
Ext: 0xFF
This firmware does not support SPDIF input - DSD/PCM only.
Switch one position one is reassigned to:
On = Normal Operation - DAC master clock can be async or sync.
Off = Sync Master Only (128FS flag set) - DAC master clock must be in sync with serial data.
Cheers!
Russ
This is the change for that branch
Comparing master...SyncMode * twistedpearaudio/Buffalo-III-SE-Pro-On-Board-Firmware * GitHub
Comparing master...SyncMode * twistedpearaudio/Buffalo-III-SE-Pro-On-Board-Firmware * GitHub
Last edited:
Wondering if anyone has compared PCM vs. PCM converted to DSD both fed into a BIIIPRO? - I did briefly using Audirvana and quite liked the result, but the realtime conversion (to DSD128) was too much for my 2009 MacBook Pro which sounded like a jet engine trying to cool itself down! As a result I haven't been able to conduct any really valid long term comparisons.
With the technology that is in the new ESS chips would one expect any significant advantages is feeding DSD vs PCM?
With the technology that is in the new ESS chips would one expect any significant advantages is feeding DSD vs PCM?
Hi Russ, thank you for your quick support. With the given hex file, I think the preparation of this experimental firmware chip went well. Please let me know if there is something wrong with my setting. BTW, I added a 10K R between Vcc and Reset and a 0.1uF C between Vcc and GND for this procedure to avoid verification error.
Code:
root@parabuntu:/usr/src/avr# avrdude -pt85 -cdragon_hvsp -Pusb -u -Uflash:w:"Buffalo-3-SE-Pro-OB-SyncMode-PCM_DSD.hex":a -Ulfuse:w:0xE2:m -Uhfuse:w:0xD5:m -Uefuse:w:0xFF:m
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.15s
avrdude: Device signature = 0x1e930b (probably t85)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "Buffalo-3-SE-Pro-OB-SyncMode-PCM_DSD.hex"
avrdude: input file Buffalo-3-SE-Pro-OB-SyncMode-PCM_DSD.hex auto detected as Intel Hex
avrdude: writing flash (2014 bytes):
Writing | ################################################## | 100% 3.67s
avrdude: 2014 bytes of flash written
avrdude: verifying flash memory against Buffalo-3-SE-Pro-OB-SyncMode-PCM_DSD.hex:
avrdude: load data flash data from input file Buffalo-3-SE-Pro-OB-SyncMode-PCM_DSD.hex:
avrdude: input file Buffalo-3-SE-Pro-OB-SyncMode-PCM_DSD.hex auto detected as Intel Hex
avrdude: input file Buffalo-3-SE-Pro-OB-SyncMode-PCM_DSD.hex contains 2014 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 3.55s
avrdude: verifying ...
avrdude: 2014 bytes of flash verified
avrdude: reading input file "0xE2"
avrdude: writing lfuse (1 bytes):
Writing | ################################################## | 100% 0.06s
avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xE2:
avrdude: load data lfuse data from input file 0xE2:
avrdude: input file 0xE2 contains 1 bytes
avrdude: reading on-chip lfuse data:
Reading | ################################################## | 100% 0.05s
avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: reading input file "0xD5"
avrdude: writing hfuse (1 bytes):
Writing | ################################################## | 100% 0.06s
avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xD5:
avrdude: load data hfuse data from input file 0xD5:
avrdude: input file 0xD5 contains 1 bytes
avrdude: reading on-chip hfuse data:
Reading | ################################################## | 100% 0.05s
avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0xFF"
avrdude: writing efuse (1 bytes):
Writing | ################################################## | 100% 0.06s
avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0xFF:
avrdude: load data efuse data from input file 0xFF:
avrdude: input file 0xFF contains 1 bytes
avrdude: reading on-chip efuse data:
Reading | ################################################## | 100% 0.05s
avrdude: verifying ...
avrdude: 1 bytes of efuse verified
avrdude done. Thank you.Results: As in the case with Amanero, playing DSD512 with 90MHz was hampered by continuous pulsating, periodic noise, similar to the noise with xruns in Alsa. The pulsating interval became gradaually longer and sporadic after waiting patiently, making the music sound more audible but the noise never ceased...
Then I changed the clocks to 45/49 combo: I was surprised to hear very clear DSD512 sound with this sync-only setting. This was a great bonus but there was something odd: with the regular jumper setting for 45/49 clocks on the Cronus (1 x 2), the rate of playing music became twice faster, like using a 90/98 combo and the rate became normal when the jumper was set to 1 x 4. I'll be happy if this can be explained.
BTW, during this experiment, the Vin of noise-rich B3SEpro with 90/98 combo measured 4.38V while 5.07V with noise-free 45/49 combo.
So, I'd like to conclude that your sync-only firmware is, for now, working quite well, though there may remain something to be refined further. Thank you so much for your great support.
Best Regards,
Attachments
It sounds like you have a sagging supply. If that is an old LCDPS you will want to replace the series resistor with a wire.
Thanks for the report!
I am pretty certain that playback speed issue would have to be on the source side.
It would also be helpful to try some high rate pcm.
Cheers!
Russ
Thanks for the report!
I am pretty certain that playback speed issue would have to be on the source side.
It would also be helpful to try some high rate pcm.
Cheers!
Russ
Thank you for your experiment and for tying out Russ's modified firmware for sync only mode. It would seem that going that route would negate the need for 90/98 clocks for DSD512.
Russ, if the buffalo.c code is changed as below, would I effectively be able to have:
Switch 1 On: SPDIF with normal mode
Switch 1 Off: DSD with sync only mode?
Code:
if (sw1.input_mode == INPUT_MODE_SERIAL) {
r1.auto_select = R1_AUTO_SELECT_DSD_SERIAL;
r1.input_select = R1_INPUT_SELECT_SERIAL;
R10_MASTER_MODE_SYNC r10;
r10.byte = R10_DEFAULT;
r10.fs128_mode = R10_128FS_MODE_ENABLED;
i2cSendByte(DAC_ADDRESS, 10, r10.byte);
} else {
r1.auto_select = R1_AUTO_SELECT_DISABLE;
r1.input_select = R1_INPUT_SELECT_SPDIF;
}I'm using the SPDIF input for a direct AV source to Buffalo connection while the serial input is connected to the FIFO and Amanero. Therefore only the serial input would require the sync only mode.
The Buffalo dac is stereo mode (there is no official mono option at present - this is defined in the default firmware). It is balanced.
To obtain single ended output this is achieved in Russ's i/v conversion by a balanced-to-single-ended converting circuit.
So, no "switch" - you take the balanced or single ended output from the Mercury (for example).
Both options are of course stereo.
Hellokitty:
As Goto said: with a DAC like this producing single ended output is always correctly done at the I/V stage - (Balanced to SE conversion) there is nothing to do at the DAC. Even if you could - it would be a very bad idea since a large part of the good DNR performance is due to the balanced output.
In any case the ES9028/38 etc... does not allow you to change the phase of the inverting outputs like the ES9018 did. So no - what you are saying is not applicable or desirable for this chip.
With the default firmware what you get is stereo output - both channels balanced of course - and if your I/V stage supports it (Mercury etc do) - you get singled ended output.
As Goto said: with a DAC like this producing single ended output is always correctly done at the I/V stage - (Balanced to SE conversion) there is nothing to do at the DAC. Even if you could - it would be a very bad idea since a large part of the good DNR performance is due to the balanced output.
In any case the ES9028/38 etc... does not allow you to change the phase of the inverting outputs like the ES9018 did. So no - what you are saying is not applicable or desirable for this chip.
With the default firmware what you get is stereo output - both channels balanced of course - and if your I/V stage supports it (Mercury etc do) - you get singled ended output.
Easy enough to give it a try
Looks like it should be fine.
BTW - this little programmer works fine (it can be found easily)
Tiny AVR Programmer: Attiny: Amazon.com: Industrial & Scientific
It makes it super easy to use whatever firmware you like.
Cheers!
Russ
Dual-Mono firmware
Here is experimental (I have no need for it myself) Dual-Mono firmware for the B3SE-Pro.
Left channel will be the DAC with the address jumper (on GPIO header) open (ADDR 0x90) Right channel will be the DAC with the address jumper closed (ADD 0x92)
To use this firmware you need to make sure that there is no controller on one of DACs (we will call it the slave DAC) so that there is only one I2C master.
You must also remove L5 or Short R7 (either is fine) on the slave DAC. This will disable the port expander on that board. This is important - otherwise the port expander on the slave board will conflict with the master.
A single controller will be controlling both DACs and so you need to connect the two I2C headers between the two DACs. Only connect GND,SDA,and SCL - do not connect 3.3V on the I2C headers.
This firmware should work for SPDIF, PCM, and DSD.
Analog outputs will be same phase on both sides (unlike mono mode in old ES9018 B3/B3SE firmware).
if anyone tries it and runs into any issues - let me know. I will try to get it sorted
Comparing master...dual-mono * twistedpearaudio/Buffalo-III-SE-Pro-On-Board-Firmware * GitHub
The hex file is in the Release directory.
Cheers!
Russ
Here is experimental (I have no need for it myself) Dual-Mono firmware for the B3SE-Pro.
Left channel will be the DAC with the address jumper (on GPIO header) open (ADDR 0x90) Right channel will be the DAC with the address jumper closed (ADD 0x92)
To use this firmware you need to make sure that there is no controller on one of DACs (we will call it the slave DAC) so that there is only one I2C master.
You must also remove L5 or Short R7 (either is fine) on the slave DAC. This will disable the port expander on that board. This is important - otherwise the port expander on the slave board will conflict with the master.
A single controller will be controlling both DACs and so you need to connect the two I2C headers between the two DACs. Only connect GND,SDA,and SCL - do not connect 3.3V on the I2C headers.
This firmware should work for SPDIF, PCM, and DSD.
Analog outputs will be same phase on both sides (unlike mono mode in old ES9018 B3/B3SE firmware).
if anyone tries it and runs into any issues - let me know. I will try to get it sorted
Comparing master...dual-mono * twistedpearaudio/Buffalo-III-SE-Pro-On-Board-Firmware * GitHub
The hex file is in the Release directory.
Cheers!
Russ
Last edited:
With this SyncMode firmware, the MCLK is always defined by 128fs. For DSD128 of 44.1K family, it is 128 x 44.1 x 2 (dual). For DSD512, this becomes 128 x 44.1 x 8 (octa) = 45MHz. So this would be no surprise to find the 45/49 clocks are well working with DSD512. Using 90/98 may become redundant other than for DSD1024. This is my humble assumption.
That's correct - in this mode you would only need 90/98 clocks if you want PCM at ~700Khz or DSD1024 - but lower sample rates would still work just fine as long as they are in sync with the master clock.
I think Twluke's initial experiment was hampered by a sagging supply at the very high sample rates - otherwise it should have worked as expected.
I had some time to try the 128fs sync mode firmware myself and it worked for generated DSD64/128/256/512 as well as 44.1khz - 384khz PCM(I2S) with 90/98Mhz and 45/49mhz clocks.
Cheers!
Russ
I think Twluke's initial experiment was hampered by a sagging supply at the very high sample rates - otherwise it should have worked as expected.
I had some time to try the 128fs sync mode firmware myself and it worked for generated DSD64/128/256/512 as well as 44.1khz - 384khz PCM(I2S) with 90/98Mhz and 45/49mhz clocks.
Cheers!
Russ
Last edited: