I enjoy my TPA gear so much that I like to help others enjoy theirs with whatever experience I can share. Because I don't use the firmware, I can't definitively guide you, but I suggest you look here, near the bottom:
Buffalo III SE (Stereo Edition) Pro
Then compare that with the table at:
GitHub - twistedpearaudio/Buffalo-III-SE-Pro-On-Board-Firmware
The way I read this is that position 5 on the EXT_IO ("bottom" row, 3rd from left) indicates dip switch 1 position 1. If so, and your reported voltages line up, then that critical input setting on your B3 is for SPDIF. We know that Cronus is not feeding it SPDIF. [But RCA output jacks with SPDIF signal were so commonplace in decade-old gear... Can't you scrounge something that will put out wired SPDIF? An old TV or receiver?] Anyway, if this 'read' is correct, the DAC should lock or make sound using input to the B3's SPDIF connection. It might be worth your while to scrounge any old piece of gear with SPDIF-out.
Now, is it OK to simply ground EXT_IO position 5 considering your dip switch damage?
That's for Russ or Brian.
@Stefanhgm, I just saw Russ' statement that 3.3v = off = open. I believe that reverses what I just said above. If I interpret your measurements correctly, then the B3 is running in serial mode, using I2S at 32bits. Still, Russ' suggestion to test SPDIF seems not too tough for a DIYer...
Last edited:
Take a look...
Take a look at this website:
belleson.com
They have comparisons of various regulators (measurements).
As a pre-reg, the Dexa is likely fine, as the second stage regs are going to matter more to the circuit. I like using the Bellesons a lot, and they have a wide range of regulators to suit just about every possible need, from low current to high, etc. I find them to be superb.
Take a look at this website:
belleson.com
They have comparisons of various regulators (measurements).
As a pre-reg, the Dexa is likely fine, as the second stage regs are going to matter more to the circuit. I like using the Bellesons a lot, and they have a wide range of regulators to suit just about every possible need, from low current to high, etc. I find them to be superb.
PureSync Firmware
+1!
I am waiting for the Sync firmware to be available before ordering 9038 pro board.
Btw, demand for this firmware is increasing. I counted at least 4 other users interested in PureSync so far;
Barrows, Luca72c, Greg Steward and Blitz
+1!
I am waiting for the Sync firmware to be available before ordering 9038 pro board.
Btw, demand for this firmware is increasing. I counted at least 4 other users interested in PureSync so far;
Barrows, Luca72c, Greg Steward and Blitz
+1!
I am waiting for the Sync firmware to be available before ordering 9038 pro board.
Btw, demand for this firmware is increasing. I counted at least 4 other users interested in PureSync so far;
Barrows, Luca72c, Greg Steward and Blitz
Me too, but only if it can include input switching to allow for both i2S and SPDF inputs. My modified version of the current 'Beta' version does this but I am sure that the final TPA firmware will be superior.
yes
+1! also, my understanding is that with the sync mode firmware in place one can use a lower master clock rate to suit even very high data rates? I am interested in DSD 256 and 512 specifically.
+1!
I am waiting for the Sync firmware to be available before ordering 9038 pro board.
Btw, demand for this firmware is increasing. I counted at least 4 other users interested in PureSync so far;
Barrows, Luca72c, Greg Steward and Blitz
+1! also, my understanding is that with the sync mode firmware in place one can use a lower master clock rate to suit even very high data rates? I am interested in DSD 256 and 512 specifically.
Indeed, that is also my understanding. For DSD;
In Async mode, one needs minimum 3 x Fs clock masterclock
Whereas in Sync mode, one needs 2 x Fs clock masterclock
Practically, this would make a big difference, e.g. for DSD 256 (~11-12 Mhz)
In Async mode, minimum master clock is 33-36 Mhz and since these are rather less common frequencies, one probably would end up getting more common 45-49 Mhz clocks
However, in sync mode, they can work with 22-24 Mhz clocks.
Anybody please correct my if I am wrong.
PureSync Firmware interested users
Great, the list is growing!
So far at least 6 users;
- barrows
- Luca72c
- Greg Steward
- Blitz
- MartinC700
- syracuze
I am hoping that this will encourage Russ and Brian to publish the new Firmware soon
Great, the list is growing!
So far at least 6 users;
- barrows
- Luca72c
- Greg Steward
- Blitz
- MartinC700
- syracuze
I am hoping that this will encourage Russ and Brian to publish the new Firmware soon
Had a Lot off problems with Belleson oscilating or not working at All. I use the Mini for Avcc in a Buffalo dac.
never...
had any problem with a Belleson oscillating as long as I had a .1 µF right at then put pin.
had any problem with a Belleson oscillating as long as I had a .1 µF right at then put pin.
Can anyone recommend a simple and cheap way to get an SPIDF signal for debugging the Buffalo? What about the ministreamer: USB Audio Streaming : miniStreamer ?
Many DVD players have a SPDIF ouput, check around you or buy one (cheaper than cheap used!) but you need CDs Or buy a card like this:
PCM2704 USB to S/PDIF USB Sound Card analog output digital SPDIF output | eBay
Or buy a card like this:PCM2704 USB to S/PDIF USB Sound Card analog output digital SPDIF output | eBay
Thanks for your hints. I actually had an old DAC with SPIDF output and it worked with my Buffalo DAC . So, I just need to fix my PCM input from the BBB-Hermes-Cronus now: https://www.diyaudio.com/forums/twi...tic-cape-beaglebone-black-64.html#post5572274
. So, I just need to fix my PCM input from the BBB-Hermes-Cronus now: https://www.diyaudio.com/forums/twi...tic-cape-beaglebone-black-64.html#post5572274
Glad to hear the B3 works with SPDIF. My only suggestion going forward is to double check *every* connection, voltage and polarity, pin alignment, socket seating, ... everything!
Then - if I were you - I would discontinue testing with the volumio distro. I'm correct that you've never heard a peep from it, right? I suggest you change to the basic MPD-based botic distro until you're getting sound from B3. Make sure 'aplay -l' and 'aplay -L' report correct ALSA pathways are present. Then use speaker-test or 'play' (a SoX utility) or 'aplay' (including appropriate parameters!) to debug. Only when you know your hardware is working would I switch to a different BBB operating system or player software.
You mentioned the miniStreamer - it is a versatile little board. When all is running, you can use a miniStreamer to input SPDIF into the BBB. Then any ALSA tweaks can be applied to (converted) SPDIF inputs as well as normal PCM. [I use one to input from a TV into my BBB, which then performs speaker crossover duties using ALSA filters. However, I don't use Volumio so no guarantees there!]
Last edited:
How to wire XLR to chassis?
Hey ... really enjoying the B3SE with Mercury so far, best DAC I've heard! (and I've had quite a few from Ayre, Bryston, PS Audio etc)
I've been using SE, and want to wire up the XLR outs to the chassis.
I'm a bit confused about this though, and need a bit of assistance.
Initially, I thought that I need to use a shielded twisted pair and wire like so:
Mercury GND -> Socket (1) with Shield
Mercury (+) -> Socket (2) with one wire
Mercury (-) -> Socket (3) with second wire
I've found this RANE article, and it recommends to connect as so:
Mercury GND -> Chassis
Mercury (+) -> Socket (2) with one wire
Mercury (-) -> Socket (3) with second wire
Socket (1) -> Chassis
(shield seems redundant in this scenario).
Sound System Interconnection
What is the correct approach? I don't currently have anything going to Chassis except IEC ground.
Attaching a pic of my build.
Thanks !
Hey ... really enjoying the B3SE with Mercury so far, best DAC I've heard! (and I've had quite a few from Ayre, Bryston, PS Audio etc)
I've been using SE, and want to wire up the XLR outs to the chassis.
I'm a bit confused about this though, and need a bit of assistance.
Initially, I thought that I need to use a shielded twisted pair and wire like so:
Mercury GND -> Socket (1) with Shield
Mercury (+) -> Socket (2) with one wire
Mercury (-) -> Socket (3) with second wire
I've found this RANE article, and it recommends to connect as so:
Mercury GND -> Chassis
Mercury (+) -> Socket (2) with one wire
Mercury (-) -> Socket (3) with second wire
Socket (1) -> Chassis
(shield seems redundant in this scenario).
Sound System Interconnection
What is the correct approach? I don't currently have anything going to Chassis except IEC ground.
Attaching a pic of my build.
Thanks !
Attachments
I followed your advice and used the prepared Debian distro including Botic by twluke: https://www.diyaudio.com/forums/twisted-pear/258254-support-botic-linux-driver-258.html#post5515941. Below are the outputs of the commands you mentioned.
I checked everything on Cronus. Looks okay for me :-/. When I run "speaker-test" I cannot measure a signal at D1, D2, BCK.
Still no sound. I attached a picture of the current situation. Happy for every help!
Attachments
Last edited:
number 2
I prefer to use connection scheme number 2 above, this conforms with AES guidelines for wiring "balanced" connections, and I wire all my components this way. Keep the pin 1 to chassis connection as short as possible. I run a short wire from ground of the Mercury to the chassis, and make sure that all chassis panels are electrically continuous, which may require removing some anodizing or paint. Essentially this scheme assumes that your XLR cable is wired "correctly", that is with a twisted pair (or perhaps quad) for pins 2, and 3, and that pin 1 is connected to a full coverage braided shield, ideally with no drain wire. Here is a great paper on grounding, differential signaling, and balanced connections from Bruno Putzeys
I prefer to use connection scheme number 2 above, this conforms with AES guidelines for wiring "balanced" connections, and I wire all my components this way. Keep the pin 1 to chassis connection as short as possible. I run a short wire from ground of the Mercury to the chassis, and make sure that all chassis panels are electrically continuous, which may require removing some anodizing or paint. Essentially this scheme assumes that your XLR cable is wired "correctly", that is with a twisted pair (or perhaps quad) for pins 2, and 3, and that pin 1 is connected to a full coverage braided shield, ideally with no drain wire. Here is a great paper on grounding, differential signaling, and balanced connections from Bruno Putzeys
Last edited: