Reference ABX hardware design and implementation

[pma]

Some (incomplete) balanced input, I'm also not sure about what Pavel's point is.

It is a complete balanced input that can be used for SE signal just using -leg as common. Effect of parasitic ground/shield current is highly reduced.

 

[KSTR]

It is a complete balanced input

IMHO it is not complete, the re-referencing of the output differential signal to the local GND reference is missing. It is the first half of the the know high-Z INA circuit, but the second half, the subtractor is missing.

 

[pma]

IMHO it is not complete, the re-referencing of the output differential signal to the local GND reference is missing. It is the first half of the the know high-Z INA circuit, but the second half, the subtractor is missing.

Yeah, one needs to put a conventional difference amplifier behind it. But the circuit is ingeniouis. Not mine idea, but Purifi - as I am noting.

 

[KSTR]

124 dB is a measurement limit.

For reasons that are fully understandable, the AP is not fully optimized for measuring a low noise floor with a strong, near 0dBFS signal present.

 

[pma]

For reasons that are fully understandable, the AP is not fully optimized for measuring a low noise floor with a strong, near 0dBFS signal present.

You will always be somehow limited in the presence of 0dBFS signal. Specialized noise amplifier gives deeper insight in noise analysis.

 

[KSTR]

Yeah, one needs to put a conventional difference amplifier behind it.

Or integrate the re-referencing with an output CM servo loop as shown in the circuit I posted.

Not mine idea, but Purifi - as I am noting.

If the module itself does proper re-balancing/re-referencing then of course this input buffer with gain will work.

 

[KSTR]

You will always be somehow limited in the presence of 0dBFS signal. Specialized noise amplifier gives deeper insight in noise analysis.

Yep. For DACs it is advisable to have some small signal present to avoid muting or "dynamic range enhancment" kicking in. The standard linearity test also fails for that reason. AP's methods are outdated in many regards.

 

[ppierre]

I have also said - multiple times - that I personally wouldn't have a use for an improved box if it doesn't have HDMI

Wouldn't an "ABX software" be a better solution? For example combined with something like that : https://www.audiophonics.fr/en/hdmi-extractors/switch-splitter-hdmi-earc-p-20593.html

(Not tested)

 

[mcdn]

Wouldn't an "ABX software" be a better solution? For example combined with something like that : https://www.audiophonics.fr/en/hdmi-extractors/switch-splitter-hdmi-earc-p-20593.html

I think if Erin's needs could be easily met by an HDMI switcher box he'd already have one. I need some more clarification from him on the actual use cases before doing any design work there.

 

[mcdn]

Fair enough. It wasn't clear to me that your emphasis is so much on "future-proof digital inputs" with all the immense extra effort that comes with this, likely easily doubling the estimated price tag. Like @mcdn said already, ARC and eARC is not trivial to incorporate (licensing and all, and bascially we'd be designing a streamer core).
Integrating an I2S/SPDIF splitter with the needed functions (delay compensation, notably) is easy as cake in comparison (still needs an extra DSP or a beefy controller like a top-tier STM32), but it still would be sort of a completely extra project on top of the ABX comparator proper.

On the digital audio, you are spot on, especially now we have @Weeb Labs amazing DSPi project. I already have that side almost done as I was working on it anyway, which is why this part has been mainly about making sure the analog section is beyond reproach.

 

[amirm]

I think if Erin's needs could be easily met by an HDMI switcher box he'd already have one. I need some more clarification from him on the actual use cases before doing any design work there.

I am not clear either. One problem with HDMI is the handshake which can take seconds, glitch, pop, etc. All of this eliminates any chance of detecting small differences. By the time the second source plays, you have forgotten what the first was doing. I say from experience of trying to use an AVR for it.

There are high-end, custom HDMI switchers which cache keys, EDID, etc. to make switching faster but it would be outside the scope of any DIY project.

 

[Armand]

It is something I don't understand @hardisj?
The HDMI splitter can send signal to both AVR's. No need to interrupt that?
The two AVR's under test can be switched using the ABX tester. I would add the option to lift the ground connection to the AVR that is not active to make sure they don't create ground currents.

 

[mcdn]

I am not clear either. One problem with HDMI is the handshake which can take seconds, glitch, pop, etc. All of this eliminates any chance of detecting small differences. By the time the second source plays, you have forgotten what the first was doing. I say from experience of trying to use an AVR for it.

There are high-end, custom HDMI switchers which cache keys, EDID, etc. to make switching faster but it would be outside the scope of any DIY project.

I can imagine various scenarios - for example comparing the stereo downmix from two different AVRs - where this would be avoidable with some cunning. The whole digital side is a bit different than analog, since the only meaningful comparison is between different types of upstream processing. Bits are otherwise bits But I'll know more soon I hope.

 

[KSTR]

It is something I don't understand @hardisj?
The HDMI splitter can send signal to both AVR's. No need to interrupt that?
The two AVR's under test can be switched using the ABX tester. I would add the option to lift the ground connection to the AVR that is not active to make sure they don't create ground currents.
View attachment 548513

My thinking as well, and good find @ppierre . This should solve the digital splitting issue completely (assuming any downstream delays in the connected devices are manageable).

Manual states "When used as an eARC splitter 1x4, the eARC signal of the TV can be assigned to 4 amplifiers or sound bars through this splitter, which can support 4 amplifiers or sound bars to sound at the same time."

 

[KSTR]

So now we have, if I get that right:
- [x] eARC splitting : with helper device

- [x] simple DAI splitting, SPDIF(opt/coax)/AES3(XLR) and I2S(over HDMI) : can be managed with simple DSP like the DSPIi, or even larger uC, or a rPi, etc, plus some simple hardware.

- [x] analog line-level splitting : simple to add and can be done much better than the way it was done in the Van Alstine (passive splitting with 10k breakout resistors)

- [/] analog line-level ABX input switcher : mostly sorted (but switched RCA grounds might be required to avoid "GND" loops with arbitrary sources connected, and that has some further implications on the input circuitry (single relay is not enough, and galvanic isolation is preferred in the off state, for the GND and the HOT connection, so analog switches are basically out. I could detail on this later).

- [ ] speaker-level switching : tbd

 

[KSTR]

I also have some ideas and experience with cabling strategies, that is, it is not ideal to use RCA jacks directly as this prevents point-of-source sensing and point-of-load Kelvin connection. Rather, one would have speciality cables with RCA plugs only at the ends.

Also, ESD, RFI and overvoltage/backpower protection on all ins/outs must be handled transparently and in a robust way. It's those fine details that matter and require thorough consideration on any possible "what-if" scenario.

 

[mcdn]

So now we have, if I get that right:
- [x] eARC splitting : with helper device

Very much up in the air depending on requirements, but for sure we're not building and verifying an actual HDMI splitter/switcher, so it'll be a bought-in component of some sort if that's what's needed, with this unit providing the control.

- [x] simple DAI splitting, SPDIF(opt/coax)/AES3(XLR) and I2S(over HDMI) : can be managed with simple DSP like the DSPIi, or even larger uC, or a rPi, etc, plus some simple hardware.

Yes. It needs a slight modification to the DSPi firmware to allow 4 SPDIF inputs, but Troy's indicated on the DSPi Discord that he's happy to do that, and if not then I can maintain a small patch.

- [x] analog line-level splitting : simple to add and can be done much better than the way it was done in the Van Alstine (passive splitting with 10k breakout resistors)

At the moment the design simply has two sets of RCAs connected to the outputs of the OPA1612. Are you thinking of something else like separately buffered outputs?

- [/] analog line-level ABX input switcher : mostly sorted (but switched RCA grounds might be required to avoid "GND" loops with arbitrary sources connected, and that has some further implications on the input circuitry (single relay is not enough, and galvanic isolation is preferred in the off state, for the GND and the HOT connection, so analog switches are basically out. I could detail on this later).

Ground loops are a concern, but analog switches are strongly preferred for their silence. The flip side of the ground connection situation is that sharing the grounds makes handling DC offset marginally easier. I am looking at an optocoupler based ramping solution on the analog side, so DC offset pops could be mitigated by that but it doesn't help with ground loops per se: https://au.mouser.com/en/ProductDetail/Advanced-Photonix/NSL-32SR3?qs=Znm5pLBrcAKJr/WWV74khA==

- [ ] speaker-level switching : tbd

 

[KSTR]

Very much up in the air depending on requirements, but for sure we're not building and verifying an actual HDMI splitter/switcher, so it'll be a bought-in component of some sort if that's what's needed, with this unit providing the control.

What is missing in the shown device? It it can be set up to split eARC as required so one can feed two DUTs simultaneously with the same stream data. And it is cheap.

 

[KSTR]

The flip side of the ground connection situation is that sharing the grounds makes handling DC offset marginally easier.

The R-C-R cell doing the DC-blocking is directly at the input (think of it as part of the the DUT, not our device). What happens after that point doesn't matter for its function.

The acoustic noise of small signal relays can be shielded by simple sound-proofing a separate PCB (with only the relays).

Contact bounce cues would be mitigated because of the output side muting.

 

[mcdn]

The R-C-R cell doing the DC-blocking is directly at the input (think of it as part of the the DUT, not our device). What happens after that point doesn't matter for its function.

The acoustic noise of small signal relays can be shielded by simple sound-proofing a separate PCB (with only the relays).

Contact bounce cues would be mitigated because of the output side muting.

Thanks,

• Agreed on the R-C-R point. The bias and bleed resistors now return to each source’s RCA sleeve, so the DC blocking remains local when the return is switched downstream.
• Also agreed on the relays vs muxes. The mux on resistance of 1ohm is just too big, especially for the ground return but it will help to have something smaller for the signal too. And relays give us true galvanic isolation. They do make a sound though, so...
• I’ll compare simultaneous and staggered switching for cue mitigation. There will be some damping and isolation involved but I'm going to keep the relays soldered to the board for the prototype. If that doesn't work I can consider more extreme measures.
  • There's actually quite a lot of literature out there n acoustic noise from relay switching, but it boils down to "probably audible, test in your situation and mitigate"
  • It's still a worthwhile tradeoff for this iteration, as I think we can mitigate it.
    

The provisionally selected relay is the TE IM03GR, with <50mOhm contact resistance. Just for the input switching, the rest of the switching remains muxed.

Here's the latest circuit: