• 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

I was wondering if there are any specific settings for the onboard firmware for DSD512?

The reason that I'm asking is that when I feed the Buffalo with DSD512, I get no lock (no sound) but when I feed it DSD256 it locks and I get sound (sounds very good).
My current SW2 settings are OSF=on, IIR filter bandwidth=70K and DPLL=0b1111.
I'm using the Amanero with latest firmware connected directly to the Buffalo with u.fl cables (while I try figuring out why I can't get a lock on DSD512).
When I have the mcFIFO in between the Amanero and Buffalo, DSD is detected by the McFIFO when I play DSD512 upsampled material, therefore it seems like the Amanero is outputting a DSD stream.

Any ideas what could be causing the Buffalo not to lock on DSD512?
 
Yeah - unfortunately - ESS was a bit late with the update on their datasheet - but as soon as we knew we started offering the trident for that position at 1.3V.

Believe me - I was totally baffled why I couldn't get a lock on DSD512 for quite some time myself. The good thing is - this does not seem to effect PCM even up to 384khz (at least when I tried it) - only DSD.
 
-snip-
Any ideas what could be causing the Buffalo not to lock on DSD512?

Hi JoeyDD,

Since the old B3SE I've been using Amanero for playing upsampled DSD512 (native) by HQ player (via Roon) on linux (Ubuntu 16.04) without any problems and the current B3SEpros (both of 9038 and 9028) are far better working with this setting in terms of the SQ. My firmware setting for B3SEpro is quite simple: SW1 01111111; SW2 00110000. BTW 1.2V trident works fine and there is no need for tweaking.

Well, I have two Amanero boards in use for B3SEpros: one with the latest firmware of 2003be and the other with 2003be_71A, both support big endian (BE) because playing native DSD512 by Amanero on linux requires BE format. Your success in playing DSD256 may suggest Amanero recognizing the source as DoP, not native DSD.

The linux kernel provided by the author of HQ player, which I'm now using, supports both of LE (little endian) and BE on Ubuntu (xenial), so I can avoid this endianness issue. Also I occasionally use an Arch linux kernel on BBB for playing MPD which also supports BE via Amanero.

The latest Amanero firmware has an issue of channel swap which can be solved by a particular CPLD but this can not be used for Amanero-Hermes/Cronus because there is no slave mode version of its sibling. So, for now I've been using Amanero without Hermes/Cronus for playing DSD512 on B3SE and B3SEpros, only by adding an isolator (ISO7640fm) before sending signals to the B3SEs.

That said, my B3Sepros are now providing quite satisfactory DSD512 sound, whether via HQ player on Ubuntu or occasionally via MPD on BBB for playing original DSD512 source on Arch Linux.

Oh, one more thing. BBB-Botic/Hermes/Cronus is far more stable in playing DSD512 than Amanero when Botic system is used as an NAA for HQ player.

Regards,

Code:
root@musik2:~# uname -a
Linux musik 4.14.14-jl+ #8 SMP PREEMPT Mon Jan 22 22:17:04 EET 2018 x86_64 x86_64 x86_64 GNU/Linux

root@musik2:~# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: PCH [HDA Intel PCH], device 0: ALC887-VD Analog [ALC887-VD Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 1: ALC887-VD Digital [ALC887-VD Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 7: HDMI 1 [HDMI 1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 8: HDMI 2 [HDMI 2]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: Amanero [Combo384 Amanero], device 0: USB Audio [USB Audio]
  Subdevices: 0/1
  Subdevice #0: subdevice #0

root@musik2: less /proc/asound/card1/pcm0c/sub0#/hw_params
access: RW_INTERLEAVED
format: DSD_U32_BE
subformat: STD
channels: 2
rate: 705600 (705600/1)
period_size: 7056
buffer_size: 14112


[root@alarm ~]# uname -a
Linux alarm 4.15.14-1-ARCH #1 Sat Mar 31 02:06:05 UTC 2018 armv7l GNU/Linux

[root@alarm ~]# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Amanero [Combo384 Amanero], device 0: USB Audio [USB Audio]
  Subdevices: 0/1
  Subdevice #0: subdevice #0

[root@alarm ~]#  less /proc/asound/card0/pcm0/sub/hw_params
access: RW_INTERLEAVED
format: DSD_U32_BE
subformat: STD
channels: 2
rate: 705600 (705600/1)
period_size: 4096
buffer_size: 131072
 
Hi guys,

Thank you for your help.

I had set the DPLL to the highest setting 0b1111 but there was no change. I'm also waiting to receive some shorter u.fl cables just in case.

My Amanero has the 2003be_71A firmware and the CPLD_1080_DSDSWAPPED (using it with Ian's McFIFO and McDualXO, so not in slave mode). It seems to be receiving DSD native from the RPi3:

mdp.conf:
Code:
audio_output {
                type            "alsa"
                name            "alsa"
                device          "hw:5,0"
                dop                     "no"

}

DSD512:
Code:
volumio@volumio:~$ cat /proc/asound/card5/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: DSD_U32_BE
subformat: STD
channels: 2
rate: 705600 (705600/1)
period_size: 32768
buffer_size: 131072

and DSD256:
Code:
volumio@volumio:~$ cat /proc/asound/card5/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: DSD_U32_BE
subformat: STD
channels: 2
rate: 352800 (352800/1)
period_size: 32768
buffer_size: 131072

I figured it's maybe the clock that's the issue, so I disconnected the McDualXO from the EXT-MCK input and connected the VDD_XO regulator. With the Amanero connected directly to the Buffalo I had a lock with DSD512.

It was my understanding that using 45.1584 and 49.1520 MHz XO for the McDualXO would work for DSD512, but now I'm wondering if maybe the 9028 requires a higher frequency clock connected to EXT_MCK? It would explain why it locked on DSD512 when using the onboard 100 MHz XO?
 
Although Russ seems to have had success with DSD 512 and even a 45.1584 clock...

Actually I have typically used ~90mhz clocks for that (on cronus sync or async) - but you can go lower in async with 100Mhz master clock.

To run DSD1024 you basically have to run sync (I have not tried it) - and I bet you probably have to set the register that enables explicit sync only mode.

The only time I have run DSD512 on cronus with ~45.1584 is if I run async (with 100Mhz MCK on the B3SE-pro)
 
Last edited:
Actually I have typically used ~90mhz clocks for that (on cronus sync or async) - but you can go lower in async with 100Mhz master clock.

To run DSD1024 you basically have to run sync (I have not tried it) - and I bet you probably have to set the register that enables explicit sync only mode.

The only time I have run DSD512 on cronus with ~45.1584 is if I run async (with 100Mhz MCK on the B3SE-pro)

In my case with BBB-Hermes and Cronus, if B3SEpros are set to async, both 45/49 and 90/98 clock combinations on the Cronus do work fine with DSD512 (native). This had been already confirmed in the combination of old B3SE (9018) and BBB-Hermes/Cronus.
 
So, in this case, the options would be to either a) run async (VDD_XO connected and no EXT_MCK connection) with the same clocks on McDualXO, or b) run in sync mode by changing at least the 45.1584 clock to 90.3168 MHz.
It looks like the hard part will be to find a decent 90.3168 MHz XO as it doesn't look like 90/98 XOs are very common, and then compare async vs sync modes. Any suggestions where I could source 90/98 XOs?