The noise is present regardless whether the data is native or upsampled/converted. I'm using a similar setup to twluke - HQPlayer to BOTIC configured as an NAA. The only difference is that my main system is Windows 10 based instead of Linux. I've been using this configuration and software for quite some time without any issue. Originally with a BII and then with the 9028 Pro and sync clocking from last fall. I prefer to play DSD unaltered so I noticed this as soon as I installed the firmware. I've programmed three chips, the latest with a fresh download from GitHub and the result is always the same. The workaround for me is to resample everything to DSD256. The sound improvement with sync mode is worth that change in my listening setup and I can live with things that way. Just wanted to makes sure that the problem was reported.
Hi Pawlus,
I have no doubt you are hearing the noise - but I can absolutely say running in 128FS mode is not even remotely the cause - as I am listening that way right now (Cronus(45/49)/Hermes Amanero) direct sync mode to DSD64(DSF) albums with absolutely pure sound.
I am using this firmware:
GitHub - twistedpearaudio/Buffalo-III-SE-Pro-On-Board-Firmware at WithDisplay
What could be happening is that the lower sample rate is easier to pick up (or at least hear) as EMI if you have some faulty wiring. Or there could be some other issue related to the source. You can also get some bleed through effect if the wiring is off causing some strange effects - especially white noise.
I am happy to help - but I am absolutely certain it is not 128fs mode with 45/49mhz clocks that is the cause both because I spoke with ESS directly about implementing that feature - and because I am using it myself!
Cheers!
Russ
I have no doubt you are hearing the noise - but I can absolutely say running in 128FS mode is not even remotely the cause - as I am listening that way right now (Cronus(45/49)/Hermes Amanero) direct sync mode to DSD64(DSF) albums with absolutely pure sound.
I am using this firmware:
GitHub - twistedpearaudio/Buffalo-III-SE-Pro-On-Board-Firmware at WithDisplay
What could be happening is that the lower sample rate is easier to pick up (or at least hear) as EMI if you have some faulty wiring. Or there could be some other issue related to the source. You can also get some bleed through effect if the wiring is off causing some strange effects - especially white noise.
I am happy to help - but I am absolutely certain it is not 128fs mode with 45/49mhz clocks that is the cause both because I spoke with ESS directly about implementing that feature - and because I am using it myself!
Cheers!
Russ
New firmware for basic LCD display.
For anyone interested here is firmware that handles both "pure-sync" (128-fs) mode and shows you a display of the current volume.
Also note that this firmware allows for clock gearing if you like (normal or div2) - this is handy when you want to consume less power and you don't plan on running 384khz etc. Another thing for people to tweak as they desire.
The display I am using in the pic is a VFD display with a 4-bit compatible LCD interface.
GitHub - twistedpearaudio/Buffalo-III-SE-Pro-On-Board-Firmware at WithDisplay
Cheers!
Russ
For anyone interested here is firmware that handles both "pure-sync" (128-fs) mode and shows you a display of the current volume.
Also note that this firmware allows for clock gearing if you like (normal or div2) - this is handy when you want to consume less power and you don't plan on running 384khz etc. Another thing for people to tweak as they desire.
The display I am using in the pic is a VFD display with a 4-bit compatible LCD interface.
GitHub - twistedpearaudio/Buffalo-III-SE-Pro-On-Board-Firmware at WithDisplay
Cheers!
Russ
Attachments
Last edited:
Hi Pawlus,
I have no doubt you are hearing the noise - but I can absolutely say running in 128FS mode is not even remotely the cause - as I am listening that way right now (Cronus(45/49)/Hermes Amanero) direct sync mode to DSD64(DSF) albums with absolutely pure sound.
I am using this firmware:
GitHub - twistedpearaudio/Buffalo-III-SE-Pro-On-Board-Firmware at WithDisplay
What could be happening is that the lower sample rate is easier to pick up (or at least hear) as EMI if you have some faulty wiring. Or there could be some other issue related to the source. You can also get some bleed through effect if the wiring is off causing some strange effects - especially white noise.
I am happy to help - but I am absolutely certain it is not 128fs mode with 45/49mhz clocks that is the cause both because I spoke with ESS directly about implementing that feature - and because I am using it myself!
Cheers!
Russ
Your second post regarding the latest firmware release got me thinking. I’m not using volume control and you and others obviously are. I connected the pot sent out with the DAC last night and found that the noise doesn’t start until you get to a certain volume level. It then increases until you reach max at which point it pretty much overwhelms the music (at least on DSD64). Set at a level below where the noise kicks in, the sound is clean. This might explain why you don’t hear it and why others who posted described it as being faint.
Hi Pawlus,
On my rig - even at 0db the feed is perfectly clean with DSD64. Even on the scope with a generated DSD sine wave and silence.
Are you sending phase mode DSD? Sometimes Cronus will have problem with phase mode because of the assumptions it makes about edge alignment. Normal mode is always better.
The volume control does not really work that way (if the noise is caused by a digital problem anyway) - if it were loud enough to perceive you would hear it at any reasonable listening level. This further reinforces the idea that you might have some interaction between your output and your input. Sync mode would definitely highlight this - as you don't have a DPLL to filter out the phase baddies.
On my rig - even at 0db the feed is perfectly clean with DSD64. Even on the scope with a generated DSD sine wave and silence.
Are you sending phase mode DSD? Sometimes Cronus will have problem with phase mode because of the assumptions it makes about edge alignment. Normal mode is always better.
The volume control does not really work that way (if the noise is caused by a digital problem anyway) - if it were loud enough to perceive you would hear it at any reasonable listening level. This further reinforces the idea that you might have some interaction between your output and your input. Sync mode would definitely highlight this - as you don't have a DPLL to filter out the phase baddies.
Last edited:
Sorry - I should have explained.
The ES9028/38 have a register for "clock gearing".
What it does is basically "gear down" the clock by dividing it by 1, 2, 4, or 8. This is intended as power saving feature (in fact ESS calls that out in the DS) - it allows you to run the DAC with less current for lower sample rates.
BTW in PureSync mode DSD64 plays exactly the same for me with the clock geared or not. Still - reducing the power required could have other positive effects for some.
I learned a lot chatting with ESS both about PureSync and clock gearing.
Cheers!
Russ
Clock gearing...
Hi Russ,
Very interesting. So one could run a 45.1584 masterclock in (sync), and the 9038 would divide it down as per needed for each incoming sample rate, essentially providing the lowest clock rate which will work with each sample rate. If this saves energy it suggests that the clock rate used by the DAC is determining the final running rate of the DAC, yes? Theoretically, reducing that rate might have two effects: lower resolution? And/or lower RF noise production.
Do you suppose my thinking is on the right track? One of the reasons i like to oversample in software (beside the fact that a computer can take advantage of much higher processing power for the task), is to make the DAC do less work, with the hope that when it does less work, it produces lower RF, which may lead to more natural sound quality.
Hi Russ,
Very interesting. So one could run a 45.1584 masterclock in (sync), and the 9038 would divide it down as per needed for each incoming sample rate, essentially providing the lowest clock rate which will work with each sample rate. If this saves energy it suggests that the clock rate used by the DAC is determining the final running rate of the DAC, yes? Theoretically, reducing that rate might have two effects: lower resolution? And/or lower RF noise production.
Do you suppose my thinking is on the right track? One of the reasons i like to oversample in software (beside the fact that a computer can take advantage of much higher processing power for the task), is to make the DAC do less work, with the hope that when it does less work, it produces lower RF, which may lead to more natural sound quality.
I think it would have a couple of effects - it would lower the headroom for the OSF - and possibly alter its function? (I will investigate this)
It would definitely make life easier for your supplies - as for omnipresent random HF hash from the modulators (that's how this kind of DAC works after all) - I am confident this would really only change the frequency characteristics of that component - not the amplitude. In short - you're still going to want a filter on your output stage.
The key would be detecting the sample rate - this would require re-locking after the signal is initially detected and the appropriate gearing applied. This could be a bit annoying.
I may just have to give it a try. I actually have been doing this manually via the switches since the first prototype.
I like the way you think.
Cheers!
Russ
It would definitely make life easier for your supplies - as for omnipresent random HF hash from the modulators (that's how this kind of DAC works after all) - I am confident this would really only change the frequency characteristics of that component - not the amplitude. In short - you're still going to want a filter on your output stage.
The key would be detecting the sample rate - this would require re-locking after the signal is initially detected and the appropriate gearing applied. This could be a bit annoying.
I may just have to give it a try.
I actually have been doing this manually via the switches since the first prototype. I like the way you think.
Cheers!
Russ
DSD normal vs phase modulation.
Here is a good illustration of phase modulation vs normal modulation in DSD.
From Cronus as very high rates it is much better to stick with normal modulation. Phase modulation works - but timing can be tricky and finicky at high rates. It also has zero SQ benefits over normal modulation.
Here is a good illustration of phase modulation vs normal modulation in DSD.
From Cronus as very high rates it is much better to stick with normal modulation. Phase modulation works - but timing can be tricky and finicky at high rates. It also has zero SQ benefits over normal modulation.
Attachments
Last edited:
Adding to observations others have made:
Mac with Audirvana
Amanero
Sync mode (Russ's firmware)
Cronus with 2X divider and 45/49 clocks
DSD128 works fine, a few clicks at track start but otherwise OK
DSD64 - no dice, some random noise mostly. Amanero shows DSD64 on pin registers. Tried various settings in Audirvana but none gave positive results with DSD64.
That said, blue book CD converted to DSD128 fed to the B3SEPro is phenomenal - there is nothing hiding in the mix, the clarity, drive and separation are all superb (I am sure much is owed also to the Mercury stage). FYI the DAC is hooked up to a sleeper of an amp, JVC Z1010TX into DIY Ergo IX monitors. Would love to hear the DAC into my Manley / Zu setup but its way too hot on SOCAL to run tubes at the moment!
Mac with Audirvana
Amanero
Sync mode (Russ's firmware)
Cronus with 2X divider and 45/49 clocks
DSD128 works fine, a few clicks at track start but otherwise OK
DSD64 - no dice, some random noise mostly. Amanero shows DSD64 on pin registers. Tried various settings in Audirvana but none gave positive results with DSD64.
That said, blue book CD converted to DSD128 fed to the B3SEPro is phenomenal - there is nothing hiding in the mix, the clarity, drive and separation are all superb (I am sure much is owed also to the Mercury stage). FYI the DAC is hooked up to a sleeper of an amp, JVC Z1010TX into DIY Ergo IX monitors. Would love to hear the DAC into my Manley / Zu setup but its way too hot on SOCAL to run tubes at the moment!
Last edited:
Ah ok - it seems VOX resamples to pcm - so forget that player... but issues am not having any issues with DSD via DoP from A+ or mpd. Still - I am a bit stumped... I will investigate further...
It's really odd that only DSD seems to be affected... PCM playback is always problem free in puresync mode.
I really appreciate the reports!
It's really odd that only DSD seems to be affected... PCM playback is always problem free in puresync mode.
I really appreciate the reports!
Last edited:
If bypass_osf is enabled, the audio input becomes automatically oversampled at 8 x fs, that may form a condition of 128fs. My understanding is that is why there is no issues even when playing a 44.1/44k PCM sources without resampling.
Actually OSF bypass is not enabled in my case and any sample valid rate is working correctly. 44.1, 88.2, 176.4, 352.8 etc... OSF is working as expected according to the DS (turning it off has an immediate nasty glaring effect).
Also - OSF bypass actually just removes the OSF - leaving it up to you supply an 8X filtered sample yourself. Basically you provide your own digital OS filter and just use the DACs basic modulators as output. Turning it off does not resample or oversample - quite the opposite it disables that oversampling - see the DS for details.
I have a theory about what is going on now that I can reproduce it, but honestly DSD is an edge case for me - I deal mostly in PCM.
My observation is that I have had success with players that do DoP well. Especially MPD/Volumio etc (even A+ did fine with DoP 1.0 and DSD64)...
I am wondering if when in fs128 with a sync clock that the DSD/PCM autodetection gets confused (I have actually seen that in the past with the ES9018 - but not puresync of course). We may want to explicitly only accept DSD (turn off PCM/DSD auto detection) - because some players use an extra long DoPmarker/preamble.
In any case the puresync firmware is beta precisely for this reason! So keep the information coming - and I will continue testing on my end.
Cheers!
Russ
Also - OSF bypass actually just removes the OSF - leaving it up to you supply an 8X filtered sample yourself.
Basically you provide your own digital OS filter and just use the DACs basic modulators as output. Turning it off does not resample or oversample - quite the opposite it disables that oversampling - see the DS for details. I have a theory about what is going on now that I can reproduce it, but honestly DSD is an edge case for me - I deal mostly in PCM.
My observation is that I have had success with players that do DoP well. Especially MPD/Volumio etc (even A+ did fine with DoP 1.0 and DSD64)...
I am wondering if when in fs128 with a sync clock that the DSD/PCM autodetection gets confused (I have actually seen that in the past with the ES9018 - but not puresync of course). We may want to explicitly only accept DSD (turn off PCM/DSD auto detection) - because some players use an extra long DoPmarker/preamble.
In any case the puresync firmware is beta precisely for this reason!
So keep the information coming - and I will continue testing on my end.Cheers!
Russ
Last edited: