One I2S source and Two DACs, what is the best solution to switch between them

My new setup will be a Windows 11 PC with a Pink Faun I2S Bridge https://www.pinkfaun.com/shop/bridg...tml#/521-additional_clock_for_i2s_bridge-tcxo

I collected everything to build an @iancanada DAC like this with the power supplies https://iancanada.ca/products/flagship-full-function-sync-clock-mode-ess-dac

The re-clocked output goes directly to the DAC

I'd also like to build another DAC and switch between the two. Or, build the Iancanada as a streamer and then just have both DAC's user HDMI I2S receivers and switch between those. What's the best way to do this?
 
The AliBlahBlah boards use plain 74HCxxx logic. They're nothing special.

Is there an eval board or something already laid out? I don't have any experience laying that stuff out
Sounds like an opportunity to learn KiCAD... 😉 You're only switching three signals - or four if you include MCLK. They're not super fast, except MCLK which tends to run at 30-some MHz. A connect-the-dots layout would be alright. Post it here for feedback.

Tom
 
Before we go too far here, what are the two dacs, how far apart will they be from each other, where will they get the master clock, are they using LVCMOS I2S, or LVDS I2S? Also, what level of signal integrity do you need? Is clock jitter an important factor for either or both of your dacs? How would you want to power the switch board?
 
My new setup will be a Windows 11 PC with a Pink Faun I2S Bridge https://www.pinkfaun.com/shop/bridg...tml#/521-additional_clock_for_i2s_bridge-tcxo

I collected everything to build an @iancanada DAC like this with the power supplies https://iancanada.ca/products/flagship-full-function-sync-clock-mode-ess-dac

The re-clocked output goes directly to the DAC
Just to recap the clocking:

CM8888 PCI-e I2S interface with the very expensive additional clock -> internal PLL for 44.1kHz freqs -> I2S -> plain FIFO in FiFoPi -> another clock on FiFoPi asynchronous to the CM8888 clock -> I2S + MCLK -> DAC. I.e. two quite expensive clocks. Effect of the first is nullified by the PLL and the FIFO. The second clock does not run synchronously to the player, i.e. large latency in the FIFO or dropouts (because the FIFO does not properly merge the two clock domains).

Just for comparison - a decent USB-I2S interface would provide a single master clock, no drivers required (no danger of the CM8888 driver unavailable for new OS versions), much cheaper.
 
Last edited:
  • Like
Reactions: sbelyo
Just to recap the clocking:

CM8888 PCI-e I2S interface with the very expensive additional clock -> internal PLL for 44.1kHz freqs -> I2S -> plain FIFO in FiFoPi -> another clock on FiFoPi asynchronous to the CM8888 clock -> I2S + MCLK -> DAC. I.e. two quite expensive clocks. Effect of the first is nullified by the PLL and the FIFO. The second clock does not run synchronously to the player, i.e. large latency in the FIFO or dropouts (because the FIFO does not properly merge the two clock domains).

Just for comparison - a decent USB-I2S interface would provide a single master clock, no drivers required (no danger of the CM8888 driver unavailable for new OS versions), much cheaper.
This sounds right to me. I just ordered the PCI-e bridge with it's standard clock and planned to rely on the FiFoPi. That bridge doesn't have an external connection for a master clock signal so I'll leave that as it is. My original plan was just to run the second DAC which is a TDA1541A build off of USB and call it a day but I thought performance may be better from the I2S out of the PCI-e bridge.

If that turns out to be the case I just wanted a solution that let me switch between the two and not swapping the cable when I wanted to listen to one or the other.

Since it doesn't look like there's an off the shelf product or someone's proven layout I'll just build what I have and compare the I2S bridge to USB from the motherboard with both DAC's and come up with a winner. If I2S is the winner I'll have to come up with a solution. I only went down this rabbit hole because it was suggested in a few threads to ditch USB conversion when you can and use I2S.
 
...it was suggested in a few threads to ditch USB conversion when you can and use I2S.
That's only true in some cases. For pre-built dacs in a box that have USB and or LVDS I2S inputs, either way may be a compromise. That's because switching between input sources inside the dac box is often done in a CLPD chip, which means there is going to be a certain amount of jitter you can't avoid.

OTOH, if building a dac and there is a choice of using USB or some other input format, often USB turns out to be the best choice (but only if you do it right). That way its possible to make a fully synchronous dac system with very low close-in phase noise.
 
it was suggested in a few threads to ditch USB conversion when you can and use I2S
I2S is a low-level datastream interface designed for short distances. In many cases it needs to be accompanied with MCLK signal which is not part of I2S. Some audio-gear manufacturers started marketing external I2S interfaces as something special. To avoid the I2S signal deterioration after a few inches, they convert it to LVDS differential and conveniently use the handy and inexpensive HDMI-cable wiring. Transferring only data, no control signals like volume etc.


A regular PC does not output I2S (unlike most ARM boards) therefore some available interface is required. PCI-e is fast, but short distance too (unless using special arrangements). The generated I2S is short distance - the PCI(e)-I2S bridges were designed for soundcards integrating the codecs on the same board. The LVDS conversion is needed, yet no MCLK is available on the DAC side. The PCI(e)-I2S chip do have a MCLK input to which the upstream chain up to the software player is slaved, but that signal would have to be transferred to (or preferrably from, of course) the DAC over LVDS.

USB is designed for external devices. The USB receiver generates again I2S, but to be consumed locally at the external device. Since the DAC is local to the USB receiver, both the receiver and the codecs can use the same local master clock, again clock-slaving the upstream properly (using the USB isochronous async protocol).

IMO there is no advantage of longer-distance I2S vs. properly implemented async UAC2.
 
  • Like
Reactions: sbelyo
That's only true in some cases. For pre-built dacs in a box that have USB and or LVDS I2S inputs, either way may be a compromise. That's because switching between input sources inside the dac box is often done in a CLPD chip, which means there is going to be a certain amount of jitter you can't avoid.

OTOH, if building a dac and there is a choice of using USB or some other input format, often USB turns out to be the best choice (but only if you do it right). That way its possible to make a fully synchronous dac system with very low close-in phase noise.
Thats a good point
 
I2S is a low-level datastream interface designed for short distances. In many cases it needs to be accompanied with MCLK signal which is not part of I2S. Some audio-gear manufacturers started marketing external I2S interfaces as something special. To avoid the I2S signal deterioration after a few inches, they convert it to LVDS differential and conveniently use the handy and inexpensive HDMI-cable wiring. Transferring only data, no control signals like volume etc.


A regular PC does not output I2S (unlike most ARM boards) therefore some available interface is required. PCI-e is fast, but short distance too (unless using special arrangements). The generated I2S is short distance - the PCI(e)-I2S bridges were designed for soundcards integrating the codecs on the same board. The LVDS conversion is needed, yet no MCLK is available on the DAC side. The PCI(e)-I2S chip do have a MCLK input to which the upstream chain up to the software player is slaved, but that signal would have to be transferred to (or preferrably from, of course) the DAC over LVDS.

USB is designed for external devices. The USB receiver generates again I2S, but to be consumed locally at the external device. Since the DAC is local to the USB receiver, both the receiver and the codecs can use the same local master clock, again clock-slaving the upstream properly (using the USB isochronous async protocol).

IMO there is no advantage of longer-distance I2S vs. properly implemented async UAC2.
This makes a lot of sense