DIX4192: jitter reduction by DIX4192?

I think that you want to use the SRC4392 for jitter reduction. The input and output clock domains are entirely separate, and the output jitter is wholly set by the quality of the oscillator you use for the output.

The DIX4192 datasheet states, in regards to its DIR: "Low Jitter Recovered Clock Output", and "The DIR core recovers a low jitter master clock, which may be used to generate word and bit clocks using on-chip or external logic circuitry."

For the application at hand, we are working with a particular board with a limited set of components, and we cannot involve any re-clocking that does not preserve the time synchronization of the incoming AES3 signal (although loss of phase synchronization would probably be acceptable).  We want to make sure we are getting the most out of the DIX4192 in regards to jitter reduction, and are wondering whether there is some particular configuration to achieve that, using none other than the clock(s) retrieved by the DIX4192 itself.

Is not the SRC4392 a functional-superset variation of the DIX4192, in every way except that the DIX4192 has no sample rate converter?  We do not want to use SRC4392 in place of the DIX4192, unless it offers some way in and of itself of achieving better jitter reduction while preserving time synchronization of the AES signal applied to its DIR, at its DIT (less the jitter).

Hi Brian and Andy,

The SRC4392 and DIX4192 have the same Jitter Attenuation and tolerance performance (the curves are basically identical).

Brian - can you put a number to the highly-jittered signal?

Tom Hendrick said:

Hi Brian and Andy,

The SRC4392 and DIX4192 have the same Jitter Attenuation and tolerance performance (the curves are basically identical).

Sorry, I should have been clearer -- I meant that he should use the SRC in the 4392 especially for the jitter-reduction capability. It gets set up DIR -> SRC -> audio serial port. As the output is clocked by a local low-jitter oscillator rather that the clock recovered from the AES data stream, the jitter performance should be better.

I made that suggestion prior to the post explaining the need to remain synchronized -- but synchronized with what? I believe the delay through the SRC block is constant.

Hi Tom,

The highly-jittered signal I applied was approximately 20ns p-p sinewave jitter.  I varied the sinusoidal jitter frequency from 100Hz to 100kHz.  Bur for frequencies below 200Hz, I increased the jitter amplitude to 40ns, then to approximately 100ns.  For these tests I am using a sample rate of 48kHz, thus 1UI ~= 163ns.

I do not quite understand the Figures 5, 16, 84 of the datasheet.  All three figures appear to be exactly the same as each other, including the scaling on the right-hand side, which is not clear as far as vertical axis correspondence.  Those figures lead me to believe that if I apply a highly-jittered signal (it's not clear how high: 1UI? 2UI?) of 200Hz sinusoidal jitter frequency to the DIX4192's DIR, that I should expect to see the DIT signal, when using the recovered clocks, exhibit significantly lower jitter (again, the exact amount is not clear) than what I applied to the DIR.  But I suspect that understanding is not correct.

So if anyone can explain those Figures (5 or 16 or 84) to me, that would help.

Thanks,

-Brian

Ideally, we would like to maintain AES11 frame synchronization between the XLR Input connector and the XLR Output connector, in other words from the DIX4192's DIR to its DIT.  Doing so would only be possible by either using the recovered clocks directly, or using a PLL in a way that would maintain, on average, phase synchronization between the recovered frame clock and the newly-created (jitter free) clock.  In this application, I was hoping a PLL inside the DIX4192 would effectively provide that.  Apparently it does so only to a very limited degree(?)

Admittedly, an SRC is one way to completely avoid any of these issues for cases where one has both an SRC and an external PLL circuit available.  For the application at hand, we don't really have the latter available.

-Brian

Brian Coykendall said:

Currently, this is how we are using DIX4192, per the register settings shown.  We could change these settings, if a different configuration will produce good jitter reduction.

AES3 INPUT XLR -> DIR of DIX4192 -> PortA of DIX4192 -> PortB of DIX4192 -> DIT of DIX4192 -> AES3 OUTPUT XLR

OK, I looked at your first post again and I think I see what you're doing.

I assume that there's a reason why you bring the signal received from the DIR out to Port A, then wrap it back around into Port B and then out on the DIT?

You can route the DIR output internally right to the DIT's input ... See the data sheet's "Functional Block Diagram" section 9.2 on page 12. Register 7's TXIS[] bits set to 10 will select that path.

Also, use the MCLK input for the transmitter's master clock, not the RXCKO from the DIR. If you use RXCKO, then any jitter on the receiver's recovered clock is now driving your transmitter. Also use MCLK for the DIR's PLL reference clock.

Good luck.

Re: I assume that there's a reason why you bring the signal received from the DIR out to Port A, then wrap it back around into Port B and then out on the DIT?

We actually have two DIX4192 devices, and have an allowable configuration wherein the DIT of each device must transmit the DIR audio of just one of the devices.  While it might be possible to effectively achieve that by simply daisy-chaining the DIR of the second device to the DIT of the first, or some other such method, I remain unsure as to whether doing so could present (worse jitter, loss of AES frame alignment or other) issues that wouldn't occur by using the PORTA and PORT B method.  We will also eventually derive an expanded application from this one, wherein we need the I2S clocks and data interface of both the DIR and the DIT.

But your second suggestion instills in me a glimmer of hope that there might be a way of achieving better jitter rejection than I am currently, without adding any components or board modifications, i.e. using nothing beyond what we already have available/accessible via our CPLD and other circuitry.  Our board contains clean (i.e. low-jitter) 24.576MHz and 22.5792MHz clocks, derived from a PLL/VCXO circuit, but alas, I'm aware of no feasible way we have to determine the sample rate of the incoming AES3 (besides relying on channel status information).  So I don't know how we could determine the frequency of the RXCKO so as to know which of those two to compare it to.  (If we knew it, our CPLD might have enough resources left over to do some clock division which might result in some jitter improvement by instead comparing the frame clocks).  Currently, the clean 24.576MHz clock is fed only to the RXCKI pin of each DIX4192, i.e. for use as the DIR's PLL reference clock as you suggested.  I don't know of any way by which feeding the clean but asynchronous 24.576MHz clock also to the MCLK pin, low-jitter glitch-free audio will be produced at the DIT, at 48kHz or any other sample rate.  If there is, please do indeed let me know!

Hi Zak,

Our PLL/VCXO is a PLL1707 driven by a very low jitter VCXO, whose control voltage we have heavily filtered.  The 24.576MHz and 22.5792MHz outputs of the PLL1707 are fed directly to a CPLD, where we use the 24.576MHz for the DIX4192's RXCKI.  I *could* also use one of those (via MCLK) as the master clock for the DIT of the DIX4192, but the reasons I currently am not are: a) we have no way of knowing the DIR's incoming sample rate, so I'd have no idea which of those master clocks to use and what divisor (if any) to use, and b) for our application, the DIT must preserve the phase synchrony of the sample rate of the DIR's incoming AES3 signal.  Within those constraints, it would be ideal to find some way to achieve better jitter reduction of a jittered incoming DIR signal than what we are currently getting, which is quite minimal.  But not at the expense of loss of AES11 synchrony.  We cannot tolerate any audio glitches, which would clearly occur unless we keep at least the audio path perfectly synchronized (we want to avoid involving sample rate converters).

Thanks,

-Brian

Brian,

Since the goal is to send one or the other incoming AES3s out of both DIXs' DITs, have you considered feeding all of the incoming AES3 signals to both DIXs? Use some logic to determine which input you want to use and selecting it by sending the same register setting to both DIXs?

Perhaps use the BYPASS feature of the DIR -- it doesn't decode the incoming signal at all and instead just passes it along to the DIT?

All of that said, without completely understanding your application, why is there a need to decode the incoming signals and re-encode them? Why not use use a mux to select which inputs feed the outputs? No DIX required.

Hi Andy,

Indeed I had initially not even included the DIX4192's in the audio routing, as a first step in bringing up the board.  However, we want to achieve jitter reduction, so I have since been using the decode/encode scheme.  One way or another, we will eventually need to use the decode/encode scheme regardless, for a subsequent application, and regardless of how we deal with the actual audio flow, we need to include the DIX4192's on the board because we are monitoring some of the information contained in their status registers.

-Brian

OK, so how about the suggestion of feeding both AES3 inputs to both DIXes and then letting application-level stuff select the correct input to feed the DITs? In other words, by not using the audio serial ports at all.

Rate estimation is easily done in the CPLD if you have enough resources. Or it can be done in a micro with a counter input, if available. Route DIR out to one of the audio serial ports, configure it as a master so LRCK follows the DIR out and measure LRCK with the CPLD.

Again, this assumes a board spin.