The AES/EBU or SPDIF receiver cannot do that. It gets the clock synchronous to the incoming audio data by recovering it from AES/EBU or SPDIF signal. The transmitter combines master clock and data into a single data stream and the receiver separates them. The sender and receiver need to be in the same clock domain. That being said' you can break that link with an ASRC which can bridge clock domains making the output domain independent of the input domain. As the DDRC-88D uses such a device on the input and out of the DSP chip I don't suppose a third set would make much difference.
Are you sure? Have you taken one apart to verify?
Others claim that it least has 4x TI SRC4382 -> https://www.minidsp.com/community/threads/dirac-ddrc-88d-aes-clocking-questions.19550/. This would be consistent with how miniDSP implements ASRC when using the DIGI-FP on products like the OpenDRC-DI.
I have a good amount of experience with the miniSHARC and have personally used it in "Input Slave Mode" where the internal SHARC ASRC is used as well as "Master Mode" where clocks are provided by the miniSHARC to the DIGI-FP board which uses a SRC4382 for ASRC.
Again, the DDRC-88D is a bit of different beast with custom firmware but I've attached the relevant sections from the miniSHARC manual for reference.
Michael
Thanks for clarifying the jitter & clock concepts guys. It's very considerate.
Given the clarifications about the DDRC-88D, if I can tap the I2S outputs and send them directly to the ProtoDACs that would be really great.
Effectively the 88D would be reclocking the signal immediately before the DAC - the best I could hope for considering the ProtoDAC does not consider MCLK.
Given the clarifications about the DDRC-88D, if I can tap the I2S outputs and send them directly to the ProtoDACs that would be really great.
Effectively the 88D would be reclocking the signal immediately before the DAC - the best I could hope for considering the ProtoDAC does not consider MCLK.
If you could do that, then you might also be able to bring in a better clock from an external source. You would probably have be good at soldering small SMD stuff though.
I popped the 88D open to have a look. The built quality is pretty good.
The miniSHARC board is beneath what I expect is the SDIF to I2S and vice versa board. (It has four SRC4382 chips on it).
I couldn't split the two boards - I took the (riser) screws out but the boards are solidly connected. I expect they are bonded together in some fashion.
The I2S jumper (J2) is the near one in the second photo.
For the preliminary scoping of accessing the I2S signals coming from the miniSHARC:
- can I leave the top board intact while I connect to the four sets of miniSHARC I2S outputs at the exposed pins in the top board?
or
- no, the miniSHARC's I2S outputs need to bypass the top board.
What is reasonable electronics pratice?
Ultimately, I'd go to I2S on all my 88D inputs and remove the top board altogether.
The miniSHARC board is beneath what I expect is the SDIF to I2S and vice versa board. (It has four SRC4382 chips on it).
I couldn't split the two boards - I took the (riser) screws out but the boards are solidly connected. I expect they are bonded together in some fashion.
The I2S jumper (J2) is the near one in the second photo.
For the preliminary scoping of accessing the I2S signals coming from the miniSHARC:
- can I leave the top board intact while I connect to the four sets of miniSHARC I2S outputs at the exposed pins in the top board?
or
- no, the miniSHARC's I2S outputs need to bypass the top board.
What is reasonable electronics pratice?
Ultimately, I'd go to I2S on all my 88D inputs and remove the top board altogether.
MiniSHARC I2S outputs are single-ended so they are not intended for long connections so you should probably switch to I2S LVDS between devices. For this you would need I2S LVDS transmitters on all I2S outputs and receivers on DAC I2S inputs.
So it easily gets quite complicated without any guarantees for improvement.
So it easily gets quite complicated without any guarantees for improvement.
That would be on the fairly long side for something like a u.fl 50-ohm coax driven by series terminated CMOS circuitry. You would probably have to design a coax line driver board for it anyway. In that case may as well do it right and use LVDS. However, that means you need to convert back to LVCMOS at the receiving end. In that case you could also use LVDS to send a MCLK signal from the dac end back to the DSP board so you only have one clock domain in that part of the system.
Thanks for clarifying Mark & bohrok.
So an I2S sender per channel in the modded DSP box and an I2S receiver per channel in the DAC, as per the LHY send & receive boards?
https://www.audiophonics.fr/en/interface-modules/lhy-audio-send-p-19756.html
https://www.audiophonics.fr/en/interface-modules/lhy-audio-receiver-p-19755.html
Will these work or do we need something else?
So an I2S sender per channel in the modded DSP box and an I2S receiver per channel in the DAC, as per the LHY send & receive boards?
https://www.audiophonics.fr/en/interface-modules/lhy-audio-send-p-19756.html
https://www.audiophonics.fr/en/interface-modules/lhy-audio-receiver-p-19755.html
Will these work or do we need something else?
Those should work but I recommend that you first test the setup without those modules using short single-ended I2S wiring (<20cm). Once you got the I2S connection working it should be fairly straightforward to add those LVDS modules if you need longer connection.
Regarding the diyinhik USB board and their version of a reclocker, not all clock sources and not all reclocker circuits are designed equally well. The diyinhk probably (virtually certainly) should be expected perform in a way consistent with the cost point it was designed to meet.
Regarding going to LVDS or not, there are phase noise penalties for conversion between LVCMOS and LVDS, just as there are noise penalties from all sorts of other causes. If you have a good clock circuit at the dac and you export a copy of that clock to the I2S source, and if you reclock the I2S you get back without error then that would be a pretty good implementation whether or not conversion to LVDS was needed to make it work reliably.
Therefore, I would agree that if it works okay without LVDS then that's great. OTOH if it looks kinda marginal using only LVCMOS then maybe its worth the effort to use LVDS. Also, if it works okay now but its likely to be used in a more noisy environment later, then maybe better to play it safe and go with LVDS.
Regarding going to LVDS or not, there are phase noise penalties for conversion between LVCMOS and LVDS, just as there are noise penalties from all sorts of other causes. If you have a good clock circuit at the dac and you export a copy of that clock to the I2S source, and if you reclock the I2S you get back without error then that would be a pretty good implementation whether or not conversion to LVDS was needed to make it work reliably.
Therefore, I would agree that if it works okay without LVDS then that's great. OTOH if it looks kinda marginal using only LVCMOS then maybe its worth the effort to use LVDS. Also, if it works okay now but its likely to be used in a more noisy environment later, then maybe better to play it safe and go with LVDS.
Last edited:
All your assumptions are actually wrong.
As long as a data (music samples) is handled in the digital domain (hence any clock i implied or just there to forward/move data HW wise) no jitter can be introduced. Sloppy forwarding of data might introduce loss or repetition but that not jitter. Jitter applies to clocks and not data. Jitter is a deviation from the ideal point in time for a clock which is less than 1/10 of the clock cycle - greater deviations is referred to as Wander. It is not until a sample is to be converted to an analog level that clock jitter is of concern. DA conversion will introduce distortion in the resulting analog signal if a jittery clock is used in the D to A process.
//
Regarding the diyinhk USB board, IIUC some people have tried removing the clocks from it and instead bring in external clocking. Don't know how successful they were.
In my experience the biggest challenge when using the miniSHARC I2S output with multiple DACs is that it only has a single output for MCLK, BLCK and LRCLK. This is fine for a multichannel I2S input DAC but does not work well for multiple DACs as you need to split MCLK (if needed), BLCK and LRCLK.
I've had some success splitting BLCK and LRCK with short runs to two DACs, but I wouldn't recommend that approach. Using the McFIFO / McDualXO is a good solution for the miniSHARC as it acts as a fan out buffer for MCLK, BCLK and LRCLK, this makes interfacing multiple DACs with the miniSHARC very easy. However, the penalty is long, variable latency (from the FIFO) which is not good for audio / video applications.
I recently came across this fan out clock buffer -> https://kaamostech.com/product/clock-buffer-1-3/ which looks good for up to 3 DACs.
Michael
I've had some success splitting BLCK and LRCK with short runs to two DACs, but I wouldn't recommend that approach. Using the McFIFO / McDualXO is a good solution for the miniSHARC as it acts as a fan out buffer for MCLK, BCLK and LRCLK, this makes interfacing multiple DACs with the miniSHARC very easy. However, the penalty is long, variable latency (from the FIFO) which is not good for audio / video applications.
I recently came across this fan out clock buffer -> https://kaamostech.com/product/clock-buffer-1-3/ which looks good for up to 3 DACs.
Michael