A short update on the dual mono build. Opening up the DPLL helped a little but it's certainly livable with until I can experiment with the new dual mono syncmode firmware. The automute feature is proving a little over zealous at times in that 0.5-1 sec at the start of tracks gets dropped, gapless playback is effected and very occasionally it fails to activate which means I get a low freq pop when DSD changes to PCM.
Hi Russ,
I received a dual-mono kit of 9028pro the day before yesterday. Yesterday I assembled the dual-mono system and am now testing the sound of dual-mono system.
For audio signal transport, I used Hermes-BBB/Cronus boards as a clock master (45/49 clocks on board) and transport. The VDD-XOs from both of the master and slave DACs were removed with the slave sharing the same master clock from the master. A Mercury board was used for analog output with the output wiring as indicated by the instruction.
I used the slave as the right channel by placing jumper between GPIO 11 and 12 pins. Though this may be redundant, I placed a jumper between 11 and 10 on the master to secure its DAC address. Correct me if this is not necessary. Also, pin 1s were connected each other between the DACs as indicated.
For music player, I used an MPD capable of DSD512 running on a debian stretch with Botic driver and a HQ player running on an Ubuntu 16.04 linux system (i7 8700k) with its output to this debian system as NAA.
Results:
First of all, the dual-mono firmware (kindly enclosed in the kit, thanks Brian) worked very well. I've never experienced any annoying noise in playing music through this experiment. On MPD, both of PCM and DSD (up to DSD256) provided very clear sound but the system failed to play a DSD512 source: falling into a muted condition, though the software was still working. The HQ player which was set to playing only DSD worked up to DSD256 as well but also failed to play DSD512. Interestingly, the SQ of HQP in playing DSD became quite dull, losing its well acknowledged ability to produce good SQ.
The failure to play DSD512 may be due to sharing the MCLK between the master and slave. In this meaning it may be difficult to find any advantage of dual-mono with external clock master. PCM/DSD on MPD was not bad but so far it appears that this dual-mono system can not replace a single 9038pro with TrueSync setup.
There may be something wrong with my setup. If so, please let me know, thank you.
Regards,
I received a dual-mono kit of 9028pro the day before yesterday. Yesterday I assembled the dual-mono system and am now testing the sound of dual-mono system.
For audio signal transport, I used Hermes-BBB/Cronus boards as a clock master (45/49 clocks on board) and transport. The VDD-XOs from both of the master and slave DACs were removed with the slave sharing the same master clock from the master. A Mercury board was used for analog output with the output wiring as indicated by the instruction.
I used the slave as the right channel by placing jumper between GPIO 11 and 12 pins. Though this may be redundant, I placed a jumper between 11 and 10 on the master to secure its DAC address. Correct me if this is not necessary. Also, pin 1s were connected each other between the DACs as indicated.
For music player, I used an MPD capable of DSD512 running on a debian stretch with Botic driver and a HQ player running on an Ubuntu 16.04 linux system (i7 8700k) with its output to this debian system as NAA.
Results:
First of all, the dual-mono firmware (kindly enclosed in the kit, thanks Brian) worked very well. I've never experienced any annoying noise in playing music through this experiment. On MPD, both of PCM and DSD (up to DSD256) provided very clear sound but the system failed to play a DSD512 source: falling into a muted condition, though the software was still working. The HQ player which was set to playing only DSD worked up to DSD256 as well but also failed to play DSD512. Interestingly, the SQ of HQP in playing DSD became quite dull, losing its well acknowledged ability to produce good SQ.
The failure to play DSD512 may be due to sharing the MCLK between the master and slave. In this meaning it may be difficult to find any advantage of dual-mono with external clock master. PCM/DSD on MPD was not bad but so far it appears that this dual-mono system can not replace a single 9038pro with TrueSync setup.
There may be something wrong with my setup. If so, please let me know, thank you.
Regards,
Attachments
Thanks. It would be quite amazing. Can't wait for it...DSD512 and beyond should work fine with sync mode enabled.
I will create that branch soon - then you can have both "pure sync" and "dual mono".
Here you go.
Disclaimer: This code is experimental - and I am not set up to test it myself. That said - it was not much of a change.
GitHub - twistedpearaudio/Buffalo-III-SE-Pro-On-Board-Firmware at dual-mono-sync
Switch 1 Pos 1 - On(low) = Normal Operation
Switch 1 Pos 1 - Off(high) = Pure Sync Operation
Disclaimer: This code is experimental - and I am not set up to test it myself. That said - it was not much of a change.
GitHub - twistedpearaudio/Buffalo-III-SE-Pro-On-Board-Firmware at dual-mono-sync
Switch 1 Pos 1 - On(low) = Normal Operation
Switch 1 Pos 1 - Off(high) = Pure Sync Operation
Here you go.
Disclaimer: This code is experimental - and I am not set up to test it myself. That said - it was not much of a change.
GitHub - twistedpearaudio/Buffalo-III-SE-Pro-On-Board-Firmware at dual-mono-sync
Switch 1 Pos 1 - On(low) = Normal Operation
Switch 1 Pos 1 - Off(high) = Pure Sync Operation
Hi Russ, I downloaded the .hex file and copied it to an ATtiny85. The firmware chip worked like a charm and now I've just confirmed there is no problems with playing DSD512 on both MPD and HQ player. Dual-mono-sync works very well.
Thank you!
Now that is great news, thanks Russ! Thanks also to twluke for your various reports. It's disappointing although not surprising that dual mono 9028 does not match single 9038. Has the new firmware done anything to bring your perception of the two systems closer in terms of SQ? Did the new firmware improve the performance of HQP because I experienced the same thing as you report - although in my case it was a one off and not repeatable.
I will have a go at this later in the week.
I will have a go at this later in the week.
Hi Crom, don't worry about it. It's okay now.
With this new firmware of dual-mono-sync, the notable, high quality sound of HQP has returned without problems and I'm enjoying upsampled DSD512 sources by it, comparing with the other ones by another HQP via the single B3SE 9038pro with syncmode (Puresync by Russ). Both systems are well comparable in the SQ and for now I can not decide which would be better. In other words both are quite excellent reflecting the potential ability of syncmode in the ESS chips.
During the early stage after starting this dual mono system with syncmode, I experienced occasional static noise and transitory white noise for a few seconds. All resolved by twisting the clock cables to the slave DAC. Probably this will suggest some susceptibility to EMI or EMS in this high sampling system. Wiring really matters.
BTW this noise problem does not occur in the single 9038pro in syncmode which has been running for more than a month without power down. Hope your success.
Regards,
Hi Crom, thank you for advice. For now the wiring of clock line is okay and stable.
Regards,
Finally I've got around to trying to flash the dual mono syncmode firmware. The result is that the left channel (master DAC board) works fine but nothing out of the Right channel (slave).
This is the command I used:
/usr/local/bin/avrdude -C /usr/local/etc/avrdude.conf -p t85 -P usb -c usbtiny -Ulfuse:w:0xE2:m -Uhfuse:w:0xD5:m -Uefuse:w:0xFF:m -U flash:v:/Buffalo-3-SE-Pro-OB(2).hex:a
I've been using AVR burn-o-mat to do the flashing. Can anyone see what I've done wrong? THis is the output:
This is the command I used:
/usr/local/bin/avrdude -C /usr/local/etc/avrdude.conf -p t85 -P usb -c usbtiny -Ulfuse:w:0xE2:m -Uhfuse:w:0xD5:m -Uefuse:w:0xFF:m -U flash:v:/Buffalo-3-SE-Pro-OB(2).hex:a
I've been using AVR burn-o-mat to do the flashing. Can anyone see what I've done wrong? THis is the output:
Code:
/usr/local/bin/avrdude -C /usr/local/etc/avrdude.conf -p t85 -P usb -c usbtiny -Ulfuse:w:0xE2:m -Uhfuse:w:0xD5:m -Uefuse:w:0xFF:m -U flash:v:/Buffalo-3-SE-Pro-OB(2).hex:a
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e930b (probably t85)
avrdude: reading input file "0xE2"
avrdude: writing lfuse (1 bytes):
Writing | ################################################## | 100% 0.00s
avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xE2:
avrdude: load data lfuse data from input file 0xE2:
avrdude: input file 0xE2 contains 1 bytes
avrdude: reading on-chip lfuse data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: reading input file "0xD5"
avrdude: writing hfuse (1 bytes):
Writing | ################################################## | 100% 0.00s
avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xD5:
avrdude: load data hfuse data from input file 0xD5:
avrdude: input file 0xD5 contains 1 bytes
avrdude: reading on-chip hfuse data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0xFF"
avrdude: writing efuse (1 bytes):
Writing | ################################################## | 100% 0.00s
avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0xFF:
avrdude: load data efuse data from input file 0xFF:
avrdude: input file 0xFF contains 1 bytes
avrdude: reading on-chip efuse data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: 1 bytes of efuse verified
avrdude: verifying flash memory against /Buffalo-3-SE-Pro-OB(2).hex:
avrdude: load data flash data from input file /Buffalo-3-SE-Pro-OB(2).hex:
avrdude: input file /Buffalo-3-SE-Pro-OB(2).hex auto detected as Intel Hex
avrdude: input file /Buffalo-3-SE-Pro-OB(2).hex contains 2066 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 3.04s
avrdude: verifying ...
avrdude: 2066 bytes of flash verified
avrdude done. Thank you.This "Buffalo-3-SE-Pro-OB(2).hex" is an 8-month old hex file; not for dual-mono-sync. In the Release directory of the dual-mono-sync branch, you have to use the hex file below.
B3SEPro-OnBoard-Firmware.hex
BTW your hex file burning is okay.
Regards,
I see the link, thanks for pointing that out twluke.
I just downloaded the file at the ‘latest release’ link.
I’ll have another go.
Dual mono is actually more the edge case
Sync mode for stereo is available here:
Buffalo-III-SE-Pro-On-Board-Firmware/Release at SyncMode * twistedpearaudio/Buffalo-III-SE-Pro-On-Board-Firmware * GitHub
Sync mode for stereo is available here:
Buffalo-III-SE-Pro-On-Board-Firmware/Release at SyncMode * twistedpearaudio/Buffalo-III-SE-Pro-On-Board-Firmware * GitHub
Update and bug fixing:
I've now flashed the firmware (thanks twluke) and DAC boards initialise correctly. I now have music correctly playing out of both speakers but I get a lower level digital hiss/hash noise coming out of the right speaker (the slave DAC). I am continuing to troubleshoot and have tried the following so far:
1) Swapped I2S connections to the boards - no difference
2) Swapped Mclock cables between the boards - no difference
When I get some more time later in the week I'll look at the various regulator voltages and report back.
I've now flashed the firmware (thanks twluke) and DAC boards initialise correctly. I now have music correctly playing out of both speakers but I get a lower level digital hiss/hash noise coming out of the right speaker (the slave DAC). I am continuing to troubleshoot and have tried the following so far:
1) Swapped I2S connections to the boards - no difference
2) Swapped Mclock cables between the boards - no difference
When I get some more time later in the week I'll look at the various regulator voltages and report back.
Russ,
As some time has passed by, I really would love to try the 9038pro in dual mono and sync mode. Is the firmware mentioned above as well for the 38 ?
Can I order a second DAC incl. the right firmware installed for this application from you (could not see and options in the web shop) ?
It may look like an edge case, but I am trying to get the largest voltage swing at the lowest i/v-resistor to have only three tube stage in total between the DAC chip and the speaker...and I guess a second DAC and double output sounds better than a higher i/v resistor or a high step-up resistor in between...
Thanks a lot !
As some time has passed by, I really would love to try the 9038pro in dual mono and sync mode. Is the firmware mentioned above as well for the 38 ?
Can I order a second DAC incl. the right firmware installed for this application from you (could not see and options in the web shop) ?
It may look like an edge case, but I am trying to get the largest voltage swing at the lowest i/v-resistor to have only three tube stage in total between the DAC chip and the speaker...and I guess a second DAC and double output sounds better than a higher i/v resistor or a high step-up resistor in between...
Thanks a lot !
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.