Please note, that this output requires a very capable power source +15V/-15V It drowns 0.2mA.
At least a Salas Ultrabib grade psu would be recomended. Supercap psu prefered, otherwise its pointless.
Reclocks what? Usually when someone says reclocker, my eyes glaze over…
1 Like
Well… you know better, than anyone else. Audio data stream, either pcm or dsd or whatever, besides audio data, carry clock information. The source, typically a streamer, player have a common quality clock, ONE crystal built in, typically XO at best. And the clock accuracy affects sound quality dramatically. Reclocker boards usually carry better quality components, sc-cut oven controlled crystals, so they rewrite clock information within data stream with their own clock. Also these boards can act as a master clock source. They are more accurate, due to the fact of using two ocxo, for 44.1 and 48 grids. But that’s just theory… I’ve tried 3 different pair of clocks in my stack, a deafman would notice the difference.
If, let’s say a pi board or any other computing device, had 45mhz and 49mhz ocxo’s built in, and could output dsd datastream directly, not by i2s or i2c bus, but d1,d2, sck headers… your eyes would be at safe. Until such devices do not exist, we have to use these boards… as people say, to change dirty part into clean one.
Eversolo A8, contains some of the Ian’s boards, as shown in an teardown video, it could mean something.
Ian Canada makes excellent stuff. Swapping out the crystek 957 with the Ian Canada SC pure ultra low phase noise master clocks was a big step up improvement in my dsc3. I also use Ian’s UcPI super caps and the Shield pi pro mk3 for my RPI5 NAA!!!
No, it shouldn’t carry clock information. USB Audio Class as used in modern DACs doesn’t carry clock. And NAA connection doesn’t carry clock either. Clock is (should) be entirely owned by the DAC. And there’s no need to carry the clock around.
No, it should be DAC owning the clock. About 2 mm away from the D/A conversion stage.
Typical HQPlayer → NAA → DAC flow carries no clock anywhere. So there’s nothing to reclock.
Well, such things are all over. It is called USB Audio Class in asynchronous mode… Which is what all modern DACs support.
If you want to I2S or any other such thing. The only correct way is that the data goes towards the DAC, but the clock comes from the DAC towards the source. Otherwise it is incorrectly implemented. Hence no need for reclocking. USB Audio Class handles this through the asynchronous feedback. The DAC tells the source “send me more data” or “send me less data” depending on the DAC’s buffer fill status. And then the DAC’s internal clock pulls data out of this buffer at it’s own steady pace not caring about anything else in the world. And the asynchronous feedback ensures the DAC buffer is always filled about 50%.
1 Like
Ok Jussi, thank you very much for lecturing me, frankly. But your arguments rely entirely on USB Audio Class. Well, this is not the only way to feed the DAC with data, and surely not the best way. If i may, my religion forbids me from using USB for serious applications, audio included. It is the evolution of the LPT/COM/PS2 interfaces and it is not reliable for real-time applications. I have tens of different boards and cables on my table, trying to send data from NAA on pi5 directly to the DSC board input pins. Either via gpio direcly, using an virtual alsa audio interface, or via some boards, which are forbidden to be named here. Either way i will get rid from buffers and delays caused by them. But thank you again for pointing me, and other hqplayer users in this direction, who would know that DSD stream from hqplayer has the clock data purged. Your authority and expertise in this matter is undisputed of cause, i will change my approach considering new information.
What is better at the moment? USB can be as perfect as something can be (I have shown the measurements). Of course there are a lot of bad USB devices out there, so it is not automatically good. But it is also not bad by definition either.
I’m very happy to see measurement data for better solutions (measured from the DAC analog outputs).
I also know perfectly well how to make 8 channel DSD512 ethernet connected NAA input DAC that involves no USB at all. But it doesn’t need any reclockers either, because it is all run out of same crystal oscillator as the D/A stage itself. And the clock is just a feedback from the DAC side, as the DAC is “pulling the data” at it’s pace. Since there is only one master clock at the DAC side, there is no need for reclocking or such.
1 Like
Better? We talk about subjective thinking, better for what and for who ? For my needs any professional synchronous data transfer would be better. How would you deliver a live, multi source performance with delays between voice, instruments and other tracks like recorded orchestra etc? even if you mix all that before hqplayer, and then upsample AES Main output from the mixer, the band will hear their doing with some lag, they will just die 
I have tried everything, with minimal period sizes and buffers, still there is a delay for about 1 second. On a proper hardware, hqplayer engine itself, is pretty realtime, its only a matter of input and output.
Any device like a Hat or an PCIe board with outputs like these
must perform better then the USB connection, in theory… i just need to find and try them all.
I am not a professional, but i guess there should be some pro equipment used in television etc…
Of cause you do, it would be weird if you didnt, since its your code.
You will be laughing to the tears, but the version of DSC i use currently doesnt have clocks at all 
but it sounds phenomenal, it relies exceptionally on the clocks(ndk XO) of the xingcore U30 interface. That was the main reason for me to change this USB device with something better: a) better clocks like OCXO b) smaller or no buffer. I guees i will have to order few more DSC boards with clocks built in.
I may be wrong again, but my logic tells me something else. DSC DAC doesnt have any processing part/unit, it doesnt have a firmware… its and array of register shifters and resistors, that transform passing through data into current, real-time(will with the speed of current)… i wont be surprised at all, if some USB transport or a reclocker with 90mhz oscilator would feed it with DSD2048 successfully. In my understanding, the DAC is a soulless entity, that allows everything to be passed through it
If we talk about specifics, a beaglebone can output native DSD through its gpio, i have a DAC with this design. And Pavel added multichannel support for DSD in his PureOS. But beaglebone only has 100mbps Ethernet controller and the cpu itself won’t handle 8 channels at this high rate.
Pi 5 instead is a major step forward, compared to previous versions. The RP1 bridge allows to configure, if I remember correctly 28 pins on the gpio. They can be configured to anyone’s liking… input/output whatever for protocol or signal RP supports with proper overlay.
My HQPlayer’s ecosystem has less than 75ms delay whole path when doing 12ch DSD256 upsampling using minimum phase filter. Result was from built-in audio-visual pairing test of nVidia Shield Pro.
nVidia Shield Pro ~HDMI~ Arvus H2-4D Atmos Decoder ~AES67~ HQPe ~NAA~ NAA-RAV bridge ~Ravenna~ Merging Hapi Mk2
I agreed the latency / delay of HQP still has some room could be shorten. But the real issue would be synchronization between different USB hi-end DACs (it’s not a problem if you’re in Merging’s ecosystem).
2 Likes
If a NAA device, like a RPI has a reclocker HAT, it will embed his own clock into the stream anyways… but yeah… if the DAC itself carry TOP quality clock, the need for a reclocker device is pontless.
If you build and multichannel DSD system, it would be reasonable to use perfectly identical DACs, with mclk input prefered…
That is in case all DACs output into the same space, if its a multi room system, its not so critical.
If you use USB, there’s no audio clock carried over. So nothing to reclock.
If you are using for example the “I2S over HDMI cable” type thing, then it has a design fault where clock is at the source side (which is wrong, it should be going the other way around). This will reduce the output quality. Cables, connectors and additional circuitry will damage the clock. I have shown this with measurements.
For best performance, the clock must be very close to the D/A section with top notch PCB design. No matter what kind of clock you provide, if there is additional cabling and circuitry, or the PCB design is not perfect, the clock gets spoiled. So imperfect board design can completely spoil the fanciest and most expensive oscillator you can get. So reclocker cannot fix an imperfect design.
2 Likes
If you use a HAT, then you surely won’t use usb to feed the DAC. Reclocker HATs have direct native DSD out, like in the picture, I posted yesterday. But if you use USB, yes there is no point to reclock, because every }#%*ing amanero, xmos, xing board, has its own crapclocks and will reclock the stream again.
Btw, Jussi, can I ask you something? If by the chance, you remember 2.5.2 design, since you own one, technically, is there a way to solder an 4pin adapter to use swappable OCXOs?
Yeh but these clocks are not a few mm from the D to A conversion are they? Which is where they should be
The D to A measurements will be affected (if one cares)
I think you mentioned earlier you don’t care about measurements, which is fine.
But I prefer my DAC output to not look broken just personally
Holo Audio DACs have as good clocks as you would need. And IIRC, Amanero has fine clocks as well.
If you use a HAT, for proper performance it should have a clock input from the DAC to drive the RPi audio stack.
So in such case you must have it this way:
Data: RPi NAA → DAC
Clock: DAC → RPi NAA
DAC must own the clock, and it can be provided as reference back towards the source if necessary.
This is why I choose the SoC implementation carefully so that the SoC I/O can be slaved to the DAC’s clock.
Any adapter will likely degrade the performance so much that it likely makes the point of swapping the oscillator moot.
Thanks for clarifying one of the audio mysteries.
There are extremely expensive “oscillators for audio” pieces of equipment (for example, Esoteric’s Grandioso G1X has an MSRP of around 15,500 USD), and I was skeptical of such equipment. And in fact, Holo Audio DACs don’t have external oscillator inputs.
Ок, that was a stupid question. Should have studied 2.5.2 scheme more carefully. It is a zero-crossing DAC, or edge-triggered. It doesn’t use master clock at all. It relies exclusively on the clock data within DSD stream, so the quality of the analog output entirely depends on DSD stream quality on the input. That’s where Ian’s reclocker with SC-pure should deliver best.
It isn’t a mystery. Clocks are good for synchronising multiple devices. They can also improve on really poor clocking schemes even with the compromises they bring. It isn’t black and white to think external clocking is automatically bad. Just that where they really shine is probably not a compliment to the designer.