One reclocker before digital active crossover or four after, before DACS?

[daveing]

Finally putting some legs on my MiniDSP DDRC-88D active system.
When I do the reclocking - is it recommended to use one reclocker on the 88D input? Or am better served by having one on each of the four crossover outputs?

Or does the DDRC-88D do it for me? (though not mentioned in the literature from what I have seen)

Obviously, funding one reclocker is easier than funding four.

Thanks.

 

[Markw4]

Reclocking is something that can be advantageous to do before analog processing mixed signal system (analog and digital). In the context of dacs, reclocking might be done before an ASRC, and or done just before a dac. However, reclocking is only of much practical use if there is a very low phase noise master clock (MCLK) the clocks the entire system. Usually, that means MCLK will be external from other the built-in clocks in most dac equipment. Built-in clocks are often low cost, and surrounded by low cost support circuitry.

Whether or not its possible to import an external master clock into a system really depends on the architecture of the system. If a high quality master clock can be used then reclocking becomes more of a practical option. That said, some dacs may be more sensitive to clock jitter than other dacs. Depends on the dac architecture.

Regarding DDRC-88D, it has a Sharc chip inside to do DSP. Most likely it has its own low-ish cost clock and does ASRC inside the Sharc chip on incoming SPDIF-like digital audio streams (AES/EBU). Its ASRC performed in a noisy environment and not to the highest quality of some of the better stand-alone ASRC chips. Then DDRC-88D outputs SPDIF-like (AES/EBU) digtal audio that can be fed into a dac, where it will probably have to go through low-ish cost ASRC again in order to make it compatible with the dac's clock. IMHO, its stuff that is done in recording studios these days, but probably not in the best recording studios and or the best mastering facilities. IMNSHO, by the time all the bits are pretty mushed up it may not really all that hi-fi anymore. IME its kind of typical for MiniDSP, which is a brand in a cost-sensitive market.

Bottom line: Seems likely reclocking isn't going to be useful in this case. Sorry.

 

[daveing]

Thanks for your input Mark. And for adding clarity about the master clock controlling the various digital devices, rather than being a one-off insert. A youtube review I glanced over indicated the reclocker just gets injected into the chain before the DAC.

I'm building 4x ProtoDACs (sans RPi) and putting them in one chassis.
But are you saying there is no value in a master clock implementation in my instance unless the DDRC-88D is also a slave to the master clock?
Is the reason an IanCanada reclocker works in RPi/ProtoDAC applications because both devices are being mastered by the reclocker?

 

[Markw4]

In the ideal case all devices run off of one master clock including any digital mixer. If not, then there are multiple "clock domains" that have to be bridged. Also some of the clocks in some devices may not be all that great. Bridging clock domains can be done in a couple of ways: ASRC or FIFO buffer. FIFO buffer causes a time delay which can be on the order of one second or so. ASRC requires resamping the audio data to be synchronous with the new clock domain where the data is being sent to. FIFO buffering can ideally be bit perfect (except maybe periods of silence are changed in duration). ASRC involves calculations on the data and estimation of the ratio between the data's source exact clock frequency and the destination clock frequency. Any jitter in that process my be attenuated, but not necessarily below audibility. Jitter effects can be permanently baked in. Most commonly in studio work, ASRC is used, as FIFO time delays cause their own problems.

OTOH, if you have a fully integrated system from one manufacturer, maybe Merging Technologies can do it, then the need for ASRC may be minimized or unnecessary. If it is needed it can be done to arbitrarily high quality in terms of HD, although jitter effects between clock domains may not be fully eliminated, especially where jitter has random noise properties rather than periodic variation.

In your case, maybe you could run all your dacs from one master clock and run ASRCs for the dacs from that one master clock, and in that case reclocking just before the dacs might be beneficial.

Probably the best thing would be to go to where you could listen for yourself where there is a very high quality fully synchronous system and one with multiple bridged clock domains. Maybe you would decide whatever degradation there is doesn't matter too much for rock 'n' roll, but maybe it would be too much for symphony recorded with two condenser mics suspended over the middle seats of seating row 5 or 6. Also, you might never know how much problems you have unless you have a really good dac that exposes what changes the sound is going through with each step of processing.

There are diy dacs of that caliber, but not necessarily cheap to build even though diy.

 

[daveing]

Thanks for your efforts in filling in the blanks. I think I'm getting there.
So for my application:

DDRC-88D four spdif outs, to four spdif-I2S interfaces (e.g. Amanero Combo 384SE)
and
Master clock with four outputs (e.g. ART SyncGen or Aune XC1)

to four ASRCs that can accept external MCLK

then four sets FSCLK, BCLK & Data form the four ASRCs to four ProtoDACs?


Anybody got suggestions on an ASRC that accepts an external Master Clock?

 

[Markw4]

For an ASRC you might take a look at SRC4392. There are some others in that line, buts a very good and versatile one.

For a master clock, you might take a look at a thread at to see what sorts of issues might be involved: https://www.diyaudio.com/community/threads/general-purpose-dac-clock-board.413001/

And, may I ask what the 4 USB interface boards are for? Reason I ask is because it doesn't work to run parallel USB interfaces, if that's what is being considered.

 

[daveing]

Thanks for the link to the DAC clock thread.
Regarding the four USB interfaces - all I really need are four SPDIF interfaces. I was allowing for future use as individual DACs where the USB may come in handy.

SRC4392 boards appear to be thin on the ground. I couldn't find any. Do you know of some?

Another theoretical option, do you know of any interfaces that do what the Amanero Combo 384SE does (SPDIF & USB to I2S) that include ASRC to an external master clock?

 

[mdsimon2]

What problem are you attempting to solve with reclocking?

Michael

 

[Markw4]

There are USB interfaces with more than two channels, but none that I know of with ASRC. However, ESS dac chips have internal ASRC available, so that's always one possibility.

That said, the big, important thing about USB is that you don't need ASRC if you do it right. USB playback systems can be fully synchronous.

Regarding SRC4392 and some other stuff you might want to use, you might have to learn how to design a PCB. Its not too hard, but there is definitely a learning curve.

 

[bohrok2610]

When I do the reclocking - is it recommended to use one reclocker on the 88D input?

The key question is indeed is there any need for reclocking. Adding 4 ASRCs or reclockers just add costs and complexity without any guarantees for audible improvement.
Okto dac8 pro should be a good alternative for your setup. They do not recommend any extra measures for jitter reduction.

 

[daveing]

What problem are you attempting to solve with reclocking?

The key question is indeed is there any need for reclocking.

If I am putting together a multi-channel DAC I didn't want to leave any low to medium-level-effort performance on the table. A few guys on youtube have discussed reclockers lately, and Gabster preferred the ProtoDAC reclocked edition the best.
I have seen the OktoDAC 8 Pro and it's predecessor did really well on ASR. I'm not up for that budget though in the near future. At that price, getting three Sabaj A30a's to drive my three-ways and not working with DACs at all starts to look appealing. (but the 3E Audio amps do better...)

And Mark is testing my appetite for a serious education.

Tweaked ProtoDACs and apparently some inverting (?) may well leave me easily satisfied. I haven't settled for that yet though.
Is the inverting required in Australia? 🙂
And does my DDRC-88D's inverting switch achieve the correct flavour of inversion. (I cannot imagine how inversion would make a difference.)

 

[mdsimon2]

The closest thing to a low effort multichannel reclocking solution would be an IanCanada McFIFO/McDualXO. However, as Mark mentioned this will come with a latency penalty (100 ms) which will make it unsuitable for A/V applications.

Overall, your setup seems quite complicated. Why use I2S input DACs with a SPDIF output DSP? If you stick with this approach, I would consider a simpler SPDIF to I2S board rather than the Amanero. While the Amanero has the ability to act as a SPDIF to I2S board you are paying a lot for USB to I2S functionality you are not using.

I will also echo the Okto recommendation, it is more than just a multichannel DAC and offers a lot of useful functionality for DIY active speakers. It could easily replace the DDRC-88D and if you could sell the DDRC-88D for a reasonable price it would significantly offset the cost of the Okto. The Okto has the ability to implement DSP via XMOS -> https://github.com/fabriceo/AVDSP_DAC8 (see pdf instructions in documents folder for best info). Also, with the USB/AES mode it is also easy to implement DSP on an attached USB host (like a RPi running CamillaDSP -> https://github.com/mdsimon2/RPi-CamillaDSP).

Also, what source are you using?

Michael

 

[Markw4]

Inversion is just convenient way to switch the speaker wires around. Some speakers sound different if a kick drum hit moves the diaphragm out towards the listener, or else in away from the listener.

 

[daveing]

Overall, your setup seems quite complicated.

The Amanero was an example of something that I would know works.
But before we break out the other options:

Also, what source are you using?

The cheapest you can get - Chromecast Ultra, Blu-Ray & Xbox to TV, out through optical, $18 optical to coaxial adapter into the DDRC-88D.
When I get around to listening to my CDs, I'll copy my DDRC Dirac output settings to another input config for the Blu-ray player coaxial.

So the need for SPDIF to I2S? The ProtoDAC is the only low cost & simple DIY DAC that captured my interest. As soon as fellow DIYers demonstrated to novice me that it wasn't necessarily tied to the RPI, I settled on it. And I2S and master clocks are not too hard.

Alternative SPDIF to I2S interface modules I have spotted to the Amanero (and clones):

LHY DIR9001 module (Audiophonics) That unit has built-in reclocking but there's no way of synchronising the four modules. (TI's DIR9001 EVM actually has inputs for a master clock as that functionality is part of the DIR9001 package, but most (all?) third-party examples have not accommodated this.)

Wondom AA-AB41133 WM8804 module (Audiophonics). The module has similar functionality to LHY unit but is two-way (of no use to me). So extra parts, but if it does a better job...

What others does the community suggest?

And at a stretch, the other possibility is Mark's suggestion of having a board made for an interface chip that can accept a master clock input. DIR9001, SRC4392 or ...?

Speaking of master clock modules, does AMB's o1 module make the cut?


Thanks again Mark for the continued education, this time on inversion.

 

[rfbrw]

The DIR9001 does not reclock. The output master clock is recovered from the SPDIF datastream. The external clock is optional and is used in calculating the incoming sample rate for display purposes or for generating a pilot tone for downstream devices to lock to when there is no incoming SPDIF signal. The WM8804/5, the DIX9211 and the DIR in the SRC4392 don't either. The CS841x devices will allow you to clock data out with externally generated LRCLK and BCLK but that requires transmitter and receiver to share a common clock.

 

[mdsimon2]

So the need for SPDIF to I2S? The ProtoDAC is the only low cost & simple DIY DAC that captured my interest. As soon as fellow DIYers demonstrated to novice me that it wasn't necessarily tied to the RPI, I settled on it. And I2S and master clocks are not too hard.

I asked the question because the DDRC-88D is based on an I2S I/O board called the miniSHARC -> https://www.minidsp.com/images/documents/miniSHARC User Manual.pdf. It is highly likely you can hack it to directly get I2S out.

Do you plan on using Dirac?

Michael

 

[daveing]

The DIR9001 does not reclock.... The WM8804/5, the DIX9211 and the DIR in the SRC4392 don't either.

Do I have my terms mixed up?
I mean accepting an MCLK input from an external clock and applying that clock to internal operations.

Do I understand the following concepts correctly?

1. An ideal clock domain prevents jitter from forming.
2. Jitter only forms in resampling and/or interface operations.
3. An ideal clock domain is where one device (one device in the chain or an external clock) sets the master clock and all other devices in the chain receive an MCLK signal and apply it.
4. A reclocker is inserted somewhere chain, and removes jitter already in the signal path before it, and outputs an MCLK signal for all subsequent devices in the chain to receive and apply.
5. Having the last few devices in the chain receive and apply an MCLK signal only (without reclocking being applied) means that those last few devices do not add to the system's jitter, but also do not reduce the jitter already in the chain.

 

[daveing]

I asked the question because the DDRC-88D is based on an I2S I/O board called the miniSHARC... It is highly likely you can hack it to directly get I2S out.
Do you plan on using Dirac?

Well well. Thanks for that heads up.

I have implemented Dirac on my current 2.0 setup. It corrected a heap of bass loading as my family home doesn't allow for my rear-ported towers to be anywhere but against the wall.

Does hacking into the I2S bork the Dirac?

 

[mdsimon2]

Dirac shouldn't be an issue but you will need to investigate how the SPDIF I/O board is interfaced with the miniSHARC. If you weren't using Dirac you could get rid of the DDRC-88D and pursue a simple miniSHARC based solution (using the miniSHARC-4x8 plugin) which would be a lot less expensive and more straight forward.

The DDRC-88D has a bit more going on than a standard miniSHARC as it has ASRCs on the input and output, I imagine ASRC is handled by the SPDIF I/O board but I am not exactly sure and miniDSP doesn't give any info on the implementation. To be honest I never understood the point of the output ASRC given the fixed internal 48 kHz sample rate. The input ASRC makes sense as they want to get all of the inputs on the same clock domain as the DSP, but the output ASRC to match the sample rate of channels 1-2 seems unnecessary IMO. If the output ASRC is performed on the SPDIF I/O board you should be able to intercept I2S output of the miniSHARC (which will run at the internal 48 kHz sample rate) and route that to your DACs.

Michael

 

[bohrok2610]

Do I understand the following concepts correctly?

1. An ideal clock domain prevents jitter from forming.

No. Ideal clock domain is a prerequisite for low jitter but does not prevent jitter.

1. Jitter only forms in resampling and/or interface operations.

No. Jitter can result from e.g. digital processing, crosstalk, interference.

1. An ideal clock domain is where one device (one device in the chain or an external clock) sets the master clock and all other devices in the chain receive an MCLK signal and apply it.

Not exactly but single master clock is a prerequisite for synchronous operation.

1. A reclocker is inserted somewhere chain, and removes jitter already in the signal path before it, and outputs an MCLK signal for all subsequent devices in the chain to receive and apply.

Reclocking reduces jitter but does not remove it. Typically lower frequency signals are reclocked using MCLK and MCLK is not reclocked.

1. Having the last few devices in the chain receive and apply an MCLK signal only (without reclocking being applied) means that those last few devices do not add to the system's jitter, but also do not reduce the jitter already in the chain.

As said almost anything can add jitter.