• Disclaimer: This Vendor's Forum is a paid-for commercial area. Unlike the rest of diyAudio, the Vendor has complete control of what may or may not be posted in this forum. If you wish to discuss technical matters outside the bounds of what is permitted by the Vendor, please use the non-commercial areas of diyAudio to do so.

Introducing the Buffalo III-SE-Pro 9028/9038

francolargo

Member
Paid Member
2007-03-12 8:07 am
Twin Cities, MN
What is the master clock when using this settings, the 100 MHz or the Cronus clocks? In other words, does te MCLK have to match the sample rate for this mode?
Both systems use the Cronus clocks in synchronous mode, so the MCLK is a "2 to the x power" multiple of the sample rate. I have found that unless 128*FSR is enabled, you can't completely turn off the DPLL. With register 0x0a set to 0x00 (128*fsr disabled = default), DPLL bandwidth set to 0x1(X) plays, but the setting 0x0(X) does not play. The first hex digit of register 0x0c is for PCM bandwidth, the second for DSD. So the setting 0x0f is PCM DPLL OFF, DSD DPLL wide open.
 
Last edited:
Both systems use the Cronus clocks in synchronous mode, so the MCLK is a "2 to the x power" multiple of the sample rate. I have found that unless 128*FSR is enabled, you can't completely turn off the DPLL. With register 0x0a set to 0x00 (128*fsr disabled = default), DPLL bandwidth set to 0x1(X) plays, but the setting 0x0(X) does not play. The first hex digit of register 0x0c is for PCM bandwidth, the second for DSD. So the setting 0x0f is PCM DPLL OFF, DSD DPLL wide open.
My synchronous clock would be of the 22.05... and 24... something MHz. This would be 4 times 128FSR. So should work I guess. Is the audible benefit worth the trouble? Would take some serious soldering and programming in my case, I can run async with the DPLL bandwidth at the lowest setting, So I dont think the DPLL is having to do much anyway?
 
Last edited:

francolargo

Member
Paid Member
2007-03-12 8:07 am
Twin Cities, MN
My synchronous clock would be of the 22.05... and 24... something MHz. This would be 4 times 128FSR. So should work I guess. Is the audible benefit worth the trouble? Would take some serious soldering and programming in my case, I can run async with the DPLL bandwidth at the lowest setting, So I dont think the DPLL is having to do much anyway?
I specifically compared sync mode + 128*FSR with DPLL at 1, versus DPLL off. With my highest resolution speakers the sound space collapsed in toward the drivers when the DPLL was running. With the powered monitors on my desk setup - 8” Yamahas (limiters disabled and critical opamps and caps replaced) - the difference was smaller but the effect still seemed significant. This was with all equipment well warmed-up and in their sweet spots.

My experience with controlling the DAC via I2C has been a learning experience. The 9018s were much easier to manage than the Pro series because their registers were much more stable. Slight ESD can change registers on the Pro series. For the Pro DACs keep I2C connections compact, tidy, somewhat shielded and galvanically isolated and all will work out. Programming is easy with Python - happy to share code.
 
Decided to try out sync mode. It sounds more natural to me, less hiding. For some reason 192 is distorted, all other sample rates seem ok. I am using standard firmware On a 38pro. I checked voltages with 5.10 applied to the DAC. 1.299, 3.30 and avcc 3.58 3.59 all seem fine. I did notice that sometimes on startup the lock led doesn’t light and the volume is low. I seem to recall reading about a bug that could cause this in some version of the firmware. For those who have tried is it worth going to the full sync version? If so is there a source other than buying a burner and flashing your own?
 
I specifically compared sync mode + 128*FSR with DPLL at 1, versus DPLL off. With my highest resolution speakers the sound space collapsed in toward the drivers when the DPLL was running. With the powered monitors on my desk setup - 8” Yamahas (limiters disabled and critical opamps and caps replaced) - the difference was smaller but the effect still seemed significant. This was with all equipment well warmed-up and in their sweet spots.

My experience with controlling the DAC via I2C has been a learning experience. The 9018s were much easier to manage than the Pro series because their registers were much more stable. Slight ESD can change registers on the Pro series. For the Pro DACs keep I2C connections compact, tidy, somewhat shielded and galvanically isolated and all will work out. Programming is easy with Python - happy to share code.
Thanks for the info and offer. I have been using an arduino and c++ to control the ES9038 volume, balance, filter and DPLL. Works fine, but I also had to use shielded cables and galvanic isolation to get it stable.
Tried DPLL set to 0, no sound just like your experience.
When I take the whole DAC apart for a wiring overhaul, I will try to implement sync as well. You got me curious! :) That would involve switching between the DAC and XMOS clocks. on't know if clock signals get extra jitter from relays though. We'll see.
 

francolargo

Member
Paid Member
2007-03-12 8:07 am
Twin Cities, MN
Thanks for the info and offer. I have been using an arduino and c++ to control the ES9038 volume, balance, filter and DPLL. Works fine, but I also had to use shielded cables and galvanic isolation to get it stable.
Tried DPLL set to 0, no sound just like your experience.
When I take the whole DAC apart for a wiring overhaul, I will try to implement sync as well. You got me curious! :) That would involve switching between the DAC and XMOS clocks. on't know if clock signals get extra jitter from relays though. We'll see.
If you simply switch power to the clock rather than switch the oscillator output, you avoid any added ‘jitter’ from switch contacts. In my desk rig I set up to switch to asynchronous mode for SPDIF input. The VDD_XO to the 100MHz clock is on a low current isolated relay (Omron G3VM-61G2) that easily runs via a GPIO-controlled Darlington. My other rig also uses asynchronous mode for SPDIF, but instead of switching clocks it continues using one of the cronus clocks instead of the XO on the Buffalo3. Do I hear a difference between the two asynchronous clocks? Nope! My SPDIF is rarely a hi-rez signal - usually nothing more than 48kHz/16 bit. Of course YMMV. 😁
 
  • Like
Reactions: 1 user
I recently changed from async to sync mode. Using the Cronus clocks and stock firmware. Initially had trouble getting a lock until I discovered that the DAC needs to be warmed up. I think it sounds better but was not able to make a definitive comparison. Could be placebo effect.
What did make a big improvement for me is HQplayer up sampling to DSD256.
 
In answer to my post 1144 above I can say the Buffalo is not the culprit. I built another Amanero Cronus driving a teleporter and the sync DAC plays 192 wonderfully. I now suspect the mc fifo master clock feeding a 4 ch version of the amanero firmware. I’ll explore if it’s my layout or a fault of the 4CH version of the firmware.

The low volume without lock led seems to be startup sequence related. I have to have a source playing or at least make certain that an external master clock is applied when the DAC first powers up or it defaults into this weird behavior. A quick power cycle on the DAC seems to do the trick.
 

francolargo

Member
Paid Member
2007-03-12 8:07 am
Twin Cities, MN
The low volume without lock led seems to be startup sequence related. I have to have a source playing or at least make certain that an external master clock is applied when the DAC first powers up or it defaults into this weird behavior. A quick power cycle on the DAC seems to do the trick.
You’re spot-on here. There must be a clock available for the DAC to initialize. Pin 1 of the GPIO header (square solder mask) can be momentarily grounded after the external MCLK is RTG. https://twistedpearaudio.github.io/blog/docs_b3sepro/manual.html