Introducing the Buffalo III-SE-Pro 9028/9038

[francolargo]

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.

 

[marcelooms]

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?

 

[francolargo]

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.

 

[stephen1212b]

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?

 

[marcelooms]

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]

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. 😁

 

[pixelpusher]

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.

 

[stephen1212b]

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]

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

 

[alq]

Hi,

How to make Amanero / Hermes / Cronus / Buffalo IIISE PRO 28 DAC work with ASIO driver and DSD Transcoder?
Is this known problem or I have corrupted DAC firmware?

 

[francolargo]

Hi,

How to make Amanero / Hermes / Cronus / Buffalo IIISE PRO 28 DAC work with ASIO driver and DSD Transcoder?
Is this known problem

I am confident that your problem with super audio CD transcoding has not been reported here.

or I have corrupted DAC firmware?

This may not be an either-or situation as you suggest, but re-flashing the firmware (both amanero and Buffalo3Pro) is well described here in the TPA forum. A quick search should find reliable instructions. Good Luck.

 

[alq]

Hi francolargo,

I figured out the problem eventually. Attiny85 is dead, not readable.
Can you please let me know which firmware is correct for the Buffalo-IIISE PRO (ES9028).

This one:

https://github.com/twistedpearaudio/Buffalo-III-SE-Pro-On-Board-Firmware/releases/tag/v1.0

Or this one:

https://github.com/twistedpearaudio...e/blob/master/Release/Buffalo-3-SE-Pro-OB.hex

Regards,

 

[BrianDonegan]

First one.

 

[alq]

First one.

Ok, thanks.

 

[alq]

After re-flashing Attiny85 nothing changed. This Amanero/Hermes/Cronus/BuffaloIII only works with default amanero USB driver.

It does not work with ASIO driver in DoP mode.



My big mistake...

 

[SCompRacer]

Greetings folks. I can't get my BIII SE Pro 9038/Mercury to run in synch mode. Not even a flicker on the lock LED. Works and sounds great in asynch, just want to try synch. (My prior 9018 setup sounded better to me in synch). Now it's kind of a challenge put to me....lol Current config pictured.

Prior, the LCDPS powered the Hermes-Cronus boards, Amanero (TP firmware) powered via USB cable from source and the 9V 30VA transformer secondaries were split to Centaur and LCDPS. Now both secondaries are connected to the Centaur which powers BIII SE and Hermes-Cronus, set at 5v.

PCM to DAC, no DSD.

I tried two different 3" Ufl to connect Cronus to BIII XO. XO regulator removed. Cronus divider set to 1/2. 45.1584/49.152MHz Clocks.

I tried a switch between DAC and Centaur power, powered Hermes Cronus then switched DAC board on. Tried different DPLL settings doing this, powering DAC down, pull USB cable and restarting after dip switches reset.

OS enabled, tried disabled. PCM format I2S, 32 bit, automute enabled, IIR 47.44K, various DPLL settings (I am aware 5 is the low bit), all off (0000), all on (1111, 0001), etc.

Any other suggestions? Thx...

 

[pixelpusher]

Hi SCompRacer
I went through this same thing a few months ago. After much frustration I finally got Sync mode working with stock firmware. I have DPLL set wide open, that is (1111). Try different clock divider settings and make sure the DAC is fully warmed up.
I use BBB with GentooPlayer running HQPlayer NAA. Sadly GentooPlayer is no longer available for the BBB. GentooPlayer guy says there's not enough people using the BBB. I tried the PureDSD software but I think the clock was off. Could never get it right. Diana Krall sounded like a little kid. LOL

 

[SCompRacer]

Greetings pixelpusher! Thx for the suggestions! I've been thinking about trying the BBB and I2C as I could never get I2C to work with Arduino. Still using firmware chip.

 

[SCompRacer]

I pulled the Amanero Hermes Cronus. I'll purchase new XO's for it and look the boards over and try synch again.

I have a discontinued Sonore Audiobyte USB interface in there now. It was/is a highly rated USB interface. And it works in synch mode with my BIII SE Pro 9038.

Roon recognizes the Audiobyte as an unrecognized I2S device though. That means no native DSD option is offered in Roon. We can change firmware in Amanero so Roon recognizes it as a native DSD capable device, but there is no firmware support for the Audiobyte to do that.

 

[stefanhgm]

Hey everyone,

I was looking for an USB streamer for my Buffalo-IIISe-Pro with Amanero USB + Cronus. The Allo USB Signature Player looked like a good choice to me. However, there is also the Allo Digi One Signature Player that would provide an SPIDF signal and many people consider it superior to the USB Signature Player. Since I had several problem with the Amanero USB + Cronus input and since it would decrease complexity of my build I was wondering whether I could use the Allo Digital One Signature Player to directly feed SPIDF into the Buffalo without making sound quality sacrifices?

I think Russ pointed out earlier that the Cronus is always beneficial, but I just wanted to be sure before settling on the Allo USB Signature Player and the Amanero USB + Cronus input.

Having used these chips longer than probably most anyone on the planet My opinion is that the very best solution for SPDIF will always be to run async. In fact for that setup you will be doing yourself a huge favor not to bother with sync mode at all

There are several impediments to success in such a scheme. First and most important is that real success with Cronus requires its sources be able to accept it's master clock - your SPDIF sources can't... You would need a FIFO (which will incur a lag - not good for live audio or watching video)

So one cool option is that the ES9028/38 allows you to assign GPIOs to SPDIF input. The default firmware could be altered to allow for that - then you could have 2 SPDIF sources (one consumer level coax, and one TTL/CMOS) without needing any external switching. If anyone is interested I can create a branch that does that.

So in short - if you are expecting SPDIF by all means you can still use Cronus. Cronus will provide you a super clean jitter free source - even when you run the DAC itself Async!!! This is not a bad way to go at all!

Cheers!
Russ

Cheers!