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

DPLL Settings for DSD256 and 512 from HQPlayer

Hello all. I am planning to upgrade my Buffalo IIISE (9018) DAC, which currently uses a Sonore Audiobyte USB to I2S board that can only handle DSD up to DSD128. My source is a Small Green Computer Sonic Transporter i9 and player is a Sonore Signature Rendu Deluxe. Works great upsampling everything via HQPlayer to DSD128, but I'd like to explore the higher rates.

The new setup will feature the BuffaloIIISE Pro (9028) and a JL Sounds USB to I2S board capable of handling DSD512.

In preparation for the build, I was wondering if anyone who has done such a build could recommend the proper DPLL dip switch settings for the BIIIPro 9028 DAC to give a good lock on DSD256 and DSD512 with no extraneous noise while minimizing jitter. Of course I will do my own experimentation, but having a starting point is always helpful!

Thanks in advance for any advice given!!
 
Probably not much help for your question but FWIW…
I have the Buffalo III 9038 using the Beaglebone /Cronus /Hermes interface. The clocks are in sync mode so running DPLL open.
I use HQPlayer and convert everything to DSD 256. I can not get lock at DSD 512.
 
I'll report back when I build it. Right now I'm just assembling the Centaur PS and studying the JL Sounds board features/settings. I'll probably tackle the actual build around Christmas when I have time off...but I may give in to the build itch before that. ;-)
 
Probably not much help for your question but FWIW…
I have the Buffalo III 9038 using the Beaglebone /Cronus /Hermes interface. The clocks are in sync mode so running DPLL open.
I use HQPlayer and convert everything to DSD 256. I can not get lock at DSD 512.
Check this page linked below. It appears you need at least a 90MHz clock for DSD512, so unless your Cronus has one you will need to run async using the 9028 100MHz internal clock.

 
Magz, thanks for pointing that out. If you continue reading it was mentioned that the “PureSync” firmware would enable DSD with 45/49 clocks. I am tempted to try it but reluctant to go down that rabbit hole, can’t count on much support from Twisted Pear.

Markw4, I thought the widest setting (1111) would effectively disable the DPLL. Otherwise how would you disable it?
 
Setting the DPLL registers to zero will disable and bypass the DPLL. However, you may have to change some other settings to get it to work with that disabled. Also, you may also need to check the LOCK status bit to see if the dac is able to obtain lock without using the DPLL. If jitter is to high or if other clock timing problems then it may not lock on the I2S input signals without some DPLL activity.

In the datasheet should be some register settings for putting it in synchronous mode, and for setting CLK_GEAR which can be used to adjust MCLK to, IIRC, 256 times the frame clock frequency. Although I think it can still work with integer multiples of 256 times.
 
OK, so my build is complete. SGC Sonic Transporter i9 server, Sonore Signature Rendu SE Deluxe, JL Sounds Fully Isolated USB to I2S board, BuffaloIIISE Pro 9028 DAC.
Playing DSD512 from HQPlayer sounds great.
As far as DPLL settings go, I get a lock on the three highest settings, and lose it on the fourth. In the table below, that means 13, 14, 15 are fine but 12 and below are not. So I'm setting it on 13 for now. In the table, 1 is off and 0 is on, BTW.
 

Attachments

  • 1000008474.jpg
    1000008474.jpg
    87.6 KB · Views: 32
How are you powering the JL Sounds board? With two mutually isolated +5v power supplies? In not, they usually sound better that way. Might find lock will be easier too. In fact, not sure why you have to set DPLL so high unless something is making a lot of jitter.

Also, is the dac running from the JL Sounds master clock? If not, then what clock does the dac use? If its one of those Twisted Pear Chronus clock boards, IME they have problems.
 
Last edited:
JL Sounds board USB side is powered by the Rendu SE Deluxe, isolated side is powered by a Salas Reflektor-D shunt regulator.
DAC powered by a TP Centaur power supply.
DAC is running asynchronously from its internal 100MHz Crystek clock.

DSD is noisy, so the DPLL settings need to be wider for that. PCM works with much narrower settings.

My Zu Event USB cable has separate power and data lines, so I could try external power some day if I wanted to.
 
Last edited:
Crystek clock on the dac board? If so, how it it bypassed and powered? Maybe ferrite bead, then .1uf X7R bypass? Is there a dedicated voltage regulator IC for the clock? Just asking because such things can make a difference in some cases. Also IIRC, higher clock frequencies tend to produce more distortion in the audio output with these dac chips.

Anyway, Crystek clocks were found by @diyiggy to be sensitive to type/linearity of bypass dielectric. The clocks may work better with a more linear, .22uf, 805 size, Rubycon MU bypass cap. Also, IME, jumpering out ferrite beads may help too depending on how clean power is on the regulator side of the bead. Best would be a dedicated clock voltage regulator. IMHO, the benefits can be significant.

Overall best with the boards you have now would probably be to operate the dac chip in synchronous mode using the JL Sounds master clock signal instead of the 100MHz Crystek clock.

EDIT: Another question might be about the wiring between the JL Sounds board and the dac board. It should have one ground wire per I2S signal wire and the wires should be kept as short length as possible. 1-2cm would better than 5-10cm, for sure. Reason for mentioning this is that the DSD signals shouldn't require a loose DPLL setting. Tighter DPLL bandwidth tends to sound better which is probably why ESS recommends setting it to the lowest stable value. Could be there is a jitter problem and or could be there is a subtle timing problem of DCLK relative the DSD data signals. Another possible source of jitter problems can be tin plated pin header connectors; they should be gold for best stability. Reason is tin corrodes which can then cause noisy connections. Gold is used because it is corrosion resistant, especially thicker gold as used on pin headers.
 
Last edited:
I trust they know what they are doing and have tested the options very extensively.
I tried their stuff and other people's clock boards too. Tested extensively. Ended up designing my own. There is more to the story of course. If any interest the thread is at: https://www.diyaudio.com/community/threads/general-purpose-dac-clock-board.413001/


https://www.diyaudio.com/community/threads/return-to-zero-shift-register-firdac.379406/post-7852135
 
Last edited:
Crystek clock on the dac board? If so, how it it bypassed and powered? Maybe ferrite bead, then .1uf X7R bypass? Is there a dedicated voltage regulator IC for the clock? Just asking because such things can make a difference in some cases. Also IIRC, higher clock frequencies tend to produce more distortion in the audio output with these dac chips.

Anyway, Crystek clocks were found by @diyiggy to be sensitive to type/linearity of bypass dielectric. The clocks may work better with a more linear, .22uf, 805 size, Rubycon MU bypass cap. Also, IME, jumpering out ferrite beads may help too depending on how clean power is on the regulator side of the bead. Best would be a dedicated clock voltage regulator. IMHO, the benefits can be significant.
While earlier TP Buffalo boards did have ferrites, the Buffalo III does not. Also, a photo in a previous thread by @Magz shows the TP Trident regulators in place on the Buffalo, so the onboard Crystek 100MHz clock has its own dedicated regulator.
Overall best with the boards you have now would probably be to operate the dac chip in synchronous mode using the JL Sounds master clock signal instead of the 100MHz Crystek clock.
As @pixelpusher points out, the Buffalo III stock onboard firmware does not support synchronous mode, though a separate firmware release does. As to the performance difference, I prefer synchronous for PCM and I have used the clocks on a JLSounds I2SoverUSB board. They're decent, though with age the 45MHz clock is now causing some background noise. In that particular build, I also included the ability to change the DAC to asynchronous mode (for noisy SPDIF) and when in that setup, the 100MHz clock on the DAC is powered separately from the DAC's main 5v supply. In async mode an LT3042 isolates the ("clean-side") power into the 100MHz clock's Trident regulator. That sound is also excellent! Based on this experience, I wouldn't be overly concerned about running in async mode if most of the source material is resampled to DSD.

Enjoy the music!

Frank