Thoughts about Druid v2

General
1

Hi Apos Team,

I’m a very enthusiastic Druid R2R owner and have been experimenting extensively with the DAC in a system using HQPlayer.

My current setup uses HQPlayer to perform the reconstruction and upsampling upstream, sending the Druid 705.6 kHz or 768 kHz PCM over USB. I’m using MUSES02 op-amps in the balanced output positions, an upgraded power supply, and the balanced XLR outputs into a transformer interface feeding a First Watt F8.

The results have been exceptional, and they’ve made me particularly interested in Druid V2.

I have one request/suggestion for the V2 development team: please give particular attention to the Druid’s internal clocking implementation for USB/high-rate PCM.

Since the Druid’s NOS/R2R architecture allows HQPlayer to perform the sophisticated digital reconstruction upstream, I think the combination has tremendous potential. In this application, however, the quality of the Druid’s local conversion timing remains important after the 705.6/768 kHz PCM stream arrives.

Rather than necessarily adding an external master-clock input, I’d love to see V2 concentrate on the fundamentals: high-quality low-phase-noise local oscillators, clean dedicated clock power supplies, careful clock distribution/layout, and good isolation between the XMOS USB section, digital logic, R2R ladder and analog circuitry.

I’d also be very interested to know more about how the current Druid handles clocking:

• Is the XU316 USB implementation asynchronous, with the Druid’s local oscillator ultimately controlling sample timing?

• Are separate oscillator families used for 44.1-kHz and 48-kHz multiples?

• How is the clock passed from the USB/digital section to the R2R conversion stage?

• Are any improvements to oscillator quality, clock power regulation or clock distribution planned for V2?

I realize some of this may be proprietary, but even a general description would be very interesting.

I think Druid has a somewhat unique opportunity here. A powerful HQPlayer server can perform extremely sophisticated reconstruction externally, while Druid concentrates on doing a relatively simple job extremely well: accurately converting the resulting high-rate PCM through a discrete R2R ladder and a high-quality analog output stage.

I’m currently building a dedicated Ryzen-based HQPlayer streaming appliance with a network NAA endpoint specifically around this concept, with the eventual intention of pairing it with Druid V2.

The current Druid has already substantially exceeded my expectations. If V2 improves the clocking, power delivery, PCB implementation and op-amp/output-stage flexibility while retaining the fundamental R2R/NOS philosophy, I think the HQPlayer + Druid combination could become an extraordinary high-value digital front end.

Thanks for creating such an interesting little DAC, and I’m looking forward to seeing what you do with V2.

Best,
A very happy Druid owner

1 Like
2

Druid sounds exactly for it’s price. There is nothing to be enthusiastic or happy about. Simple, cheap and a little noisy in background DAC. I rather disappointed especially how it pared with Gremlin.

3

This was way above my knowledge level, but Bella was kind of enough to help out so here’s what I’ve got:

Yes, the XU316 USB circuit requires a dual-clock design for 44.1k and 48k multiples

Yes, the separate oscillator families are used for 44.1k and 48k multiples. There are three oscillators in total: one for XMOS operation, and the other two for the 44.1k and 48k clock families.

The clock pass from the digital section to the R2R stage depending on the sample rate.

There are no plans for improvement here. The V2’s primary improvement is to allow higher current output to op amps. Our target is 1A, though we’re still working with the factory to validate feasibility.