SRC4382: non constant output delay for SRC4382

Hi Alessandro, 

What delay are you referring to? The net group delay of the part should be the combination of the interpolation filter and decimation filter delays, which will be much higher than 500ns.

If you're trying to synchronize multiple devices are you driving them with the same MCLK, BCK, LRCK?

Best,

Zak

Hello Zak,

thanks for answering.

Yes, indeed the overall delay is what you said, but i'm telling this:
-i have two resamplers mounted on two different devices.
-the two devices are feeded with the very same aes-ebu signal
-the ASRCs can be reprogrammed to fit different configurations: in one configuration
it should produce a 37KHz sampled output, in another it should produce a 195KHz output.
Changing between the two configurations is done reprogramming the internal PLL, switching
the external MCLK to a proper frequency (about 18 and about 25MHz) and switching the ASRC
input from A to B.
-here comes the issue: if i feed both devices with the very same aes signal, and i compare
the two analog converted outputs, i see that the two outputs have not the same delay.
Sometimes the relative delay could also be zero, but it depends on how the devices are powered up.
The problem is that, switching between the two configurations, the relative delay between the two signals
can be any value between about +/- 10uS.
Moreover, any relative delay i get, it can be changed if i disturb the MCLK: say i have 1uS of delay,
i ground the MCLK for a while and release and the ASRC locks with 12uS delay.
I ground again the MCLK (no internal registers are touched) and it re-locks with, say, 5uS delay and so on; no
"delay jump" is observed when disconnecting/reconnecting the AES signal.

It seems like, regardless the whole resampling delay stated in the datasheet, the output phase/delay is
related on how the PLL locks to the incoming signal. I don't care about the absolute I/O delay, it can be
any value, but it is important that it is always the same.

I know that the two devices should be feeded by the same MCLK (both are running in master mode, so they will
produce their BCLK and LRCK), but as i wrote before, they are not mounted on the same equipment.
Their MCLKs are externally provided, so the frequencies amongst the devices are exactly the same, but the
phase relation of each MCLK could be different: anyway, phase-aligning two MCLKs on two devices, had no positive effect.

Moreover, the person who started this thread
e2e.ti.com/.../src4382-phase-difference-amongst-tx-output-pins

is using the two ASRCs like they should be used, with their common MCLK, LRCK and BCLK, but it seems that he's experiencing the
same problem.

The maximum i achieved until now is that, turning off and on the ASRC block with register 0x01 once i sent the new configuration, i have a
delay uncertainty of +/-1uS maximum when using 37KHz output and +/-10uS when using 195KHz output; for our application the
first is barely acceptable, while the second is not.

Many thanks.

Hello Zak,

Just for the sake of completeness, in my previous post i stated that phase jumps occurs only if i disturb the SRC4382 MCLK
line and/or if i reprogram its internal pll registers; in no case i have observed phase shifts when connecting and reconnecting the
aes-ebu input signal.

Meanwhile i made other tests: i connected two PCM5100 in slave mode to the two SRC4382 outputs and their converted
outputs are always perfectly aligned. No matters what you can do to disturb this: interrupting the MCLK, disconnecting
and reconnecting the input signal, always result in perfectly aligned outputs.
The PCM5100s are clocked only by the SRC4382 BCLK and they willl generate their internal MCLK.

The SRC4382 output is then used by an FPGA, we are looking into its gut and, for this reason i ask 
a couple of questions:
-i need to change the ASRC output rate from about 37 to about 195KHz  (in one step, not continously),
is there a preferred way to do this ? Actually i simply change the MCLK, then i reload the SRC internal PLL registers,
then i reset it internally (with register 0x01 written to 0 and, after some time, written to 0x33). Please note that
this last action partially solved the issue when in low sample rate mode (37KHz) but not when running at the higher one,
moreover, a phase jump can be seen when i issue the reset command, even if i didn't change the internal PLL registers.
First question is: having to change the MCLK/PLL "on the fly", is there a preferred way/sequence to do this ?

-second question: why the PCM5100 never shifts ? I know it generates its internal clock based on incoming BCLK so, 
i think that, when anything at its input is changed, it smootly resets and restart always aligned.
That's why i ìm asking if  SRC4382 RDY and LOCK signals are deterministic.
If they are, can i combine them in some way to reset the internal fgpa guts?

Thanks.

Hey Alessandro,

I appreciate the detail you have provided. I have a question about your sequence though, you mention you reload the internal PLL registers and then reset the device? You are just powering down the blocks though writing 0x00, never issuing a reset by writing 0x80, right? A true reset would set the PLL values back to default so I could see in this case why you would see a phase jump. 

Assuming you are just powering down the block prior to changing PLL values, your sequence seems sound. You might try powering down the blocks though as the first step and then changing MCLK and adjusting the PLL values before powering these blocks back up. I think this would be the smoothest way to transition.

The PCM5100 has its own PLL to generate its clocks from BCK as you mentioned and should reset and ramp back up when anything at the input changes. Still I am somewhat surprised that you never have alignment issues with the lock time of this PLL as an added variable...

Unfortunately there is some variability in the RDY and LOCK signal timing and it wouldn't be very reliable to use them to keep your two boards synchronized.

Can you try the revised sequence I mentioned and see if this improves anything?

Best,

Zak