SPDIF TX configuration and timing problems between chained devices

Hello MaxDelius,

I need to study this a little closer and read your post a few times. I will not have enough time today to do this.

I just sent you a friend request so you can message me directly. I will look at this closer tomorrow and if you do not hear from me after tomorrow then message me.

The issue will probably fall into the fact that the SPDIF clocking is not correlated with any MCLK signal. So we have to use a PLL to recover the clock and then run the audio through a sample rate converter. This is for the SPDIF input.

The SPDIF output can either run directly off of the core/internal clocks or can run from the SPDIF input rate but the audio will also just be transferred out and not from the core.

Again, I need to study what you detailed...

Thanks,

Dave Thibodeau

Hello Dave,

Thank you, I will awaiting your answer then.

Thanks so much,
Max

Hello,

Today I had another deep dive into this topic and it seems like jitter is the problem of this chaining issues. Setting the SPDIF TX source to the SPDIF RX (0xF1C0 to 0x0002), I see quite high jitter on the TX-Pin (around 20ns), which is near eye-narrowing failure at higher samples rates. The higher the sample rate the less speakers I can daisy chain.

Setting the SPDIF TX source to DSP (0xF1C0 to 0x0001) and routing the SPDIF through the ASRC I get a significant lower jitter at the SPDIF RX output. This makes sense, since the clock is then referenced to the DSPs clocks in this case, right?
The problem with this is that I get around 53 samples group delay on every additional speaker, which is I guess due to the adding up of ASRCs in the chain. This creates interference in a stereo setup that is not tolerable for loudpeakers.

Is there any possibilty to recover the clock/signal with the PLL and send it to the Spdif TX Pin directly without the ASRC? Or another way to create a reference to the DSP clocks without adding delay to the TX signal?

Something I still do not understand is how the internals of the direct routing (TX source = RX) work, it seems that there is some sampling or anything else happing that creates jitter, rather than just an electrical thru connection, right?

Would appreciate your help on this,

Thanks,

Max

Hello Max,

You are touching on some areas that I have not fully experimented with. So I am going to give you a couple of different options to try. Let us know how it goes.

When you said "(TX source - RX)" were you meaning setting the SPDIF TX to source its data from the SPDIF RX like this:

Yes, this gets its data from the SPDIF RX but I am not sure exactly what happens with the clocks? It really should also source the clock from the SPDIF RX so it is in sync with the data!! This will cause some jitter because there is jitter on the SPDIF RX line of course. But it really should not be a lot worse!

So try that if you have not.

Now, I did write a program a while back where you can hack the program to have the core grab the SPDIF audio data directly from the SPDIF RX and send it to the SPDIF TX without using any ASRC.

The problem with this arrangement is that you will skip or repeat samples every once in a while due to sample rate differences.

I really wish I could have realized this way back when this part was designed to ask the designers to give us an option as to the source of the sample rate clocks for the SPDIF TX section. Being able to select the SPDIF RX or some other external source would have been super handy. But, I am not aware of any way to set the SPDIF TX block to any other sample rate clock except the DSP core. Now, you can set the DSP core to follow the SPDIF RX rate!! That would do it but I imagine you have other things going on in the core so that option is not really available.

Here is a screenshot of the program:

Here is the program but you will have to go into the registers and enable the SPDIF TX. For some reason I did not save it that way.

ADAU1452 SPDIFStereoWithOutASRC.dspproj

Dave T

Hi Dave,

DaveThib said:
When you said "(TX source - RX)" were you meaning setting the SPDIF TX to source its data from the SPDIF RX like this:

This is correct. This would be the setting that I was expecting to solve my problem as I assumed this was just passing the audio through the DSP without "altering it". But measuring the jitter before and after, let me to the assumption that there is something happening that makes the jitter worse.
Any chance that we can get any information on how this works on the hardware side?

DaveThib said:
Now, I did write a program a while back where you can hack the program to have the core grab the SPDIF audio data directly from the SPDIF RX and send it to the SPDIF TX without using any ASRC.

I already tried that too, but as you stated correctly this is quite unstable, I can't even get it really clean when matching core and spdif sample rates. But the fact that there is a register catching the samples from the receiver makes me think that there is some processing going on even if the TX is set to passthrough. Saying it is not simply a hardware passthrough.

And as you stated correctly there is a lot of other stuff going on (ADCs and DACs on serial ports), this is why I can't simply sync everything to the SPDIF stream.

DaveThib said:
Being able to select the SPDIF RX or some other external source would have been super handy. But, I am not aware of any way to set the SPDIF TX block to any other sample rate clock except the DSP core

Yes that would have been really nice. I assume there is no "hidden" registers to some feature like this?

Thanks for helping,

Max

Hello Max,

Sounds like you have been doing a great job in trying lots of different solutions.

I think your only solution is to "Y" the SPDIF signal and send it to all the DSPs externally. You might need some buffers but SPDIF is rather tolerant of small level issues so I do not think you would need buffers.

Then each DSP can take in the SPDIF and they will have to run through the ASRC to get to the core since the core will not be using the SPDIF-RX clocks as a start pulse. But, the issue of the daisy chaining will be gone if all of the DSPs are getting the same SPDIF signal directly.

This part was such an awesome design and really is so powerful yet easy to use and lots of great features for audio systems but with regards to being able to do a bypass of the SPDIF the designers dropped the ball. The clocks should have also been directly passed to the TX block not just the data. I do not think they thought anyone would be using this so they did not give it much thought. Most people will take in the data via the RX, process it, and then send this changed signal out of the TX port so it could be clocked on its own.

There are no hidden registers to be able to change the TX clock source. We did not even change this when we designed the sigma350 parts. You have an unusual use case.

Sorry I could not be of more help to find a secret work-around!

Dave T

Hi Dave,

Alright, thanks for your input and your ideas on this. It's a pity that this is not working as I expected, especially since this is part of an ongoing product implementation. It seems that a real "chip-external" hardware thru solution is the way to go then. I have not implemented this in the first place since I was assuming that the DSP can deliver this functionality internally. Its not well documented and a bit misleading, but I am smarter now and at least it serves the purpose of shedding some light on the matter and providing information for other designers here.

Thanks and all the best,
Max

S/PDIF is great for consumers because it is simple to connect and supported by gear over many decades. However, it's a design from 1992 (maybe earlier?) before the industry understood the importance of low-jitter clocking. There are significant challenges to achieving state-of-the-art quality for a couple of reasons.

First, the BMC coding of the signal means that important clock edges might be rising or falling, and may change in the middle of a stream. Whether it's the ADAU1466 or any other S/PDIF receiver, this poses a serious challenge for clock recovery. In a sense, choosing S/PDIF is asking for trouble these days because digital logic has different propagation delays for rising edges versus falling edges (it's better to choose just one, and stick to it, for consistent timing, but S/PDIF does not).

Second, S/PDIF pushes the clock from an unreliably-timed media source towards the final DAC, which creates a challenge. This scheme is sometimes called push-clock. Ideally, the DAC would clock itself, and the protocol would cause the media source to follow, i.e., pull-clock. The ideal is only possible with a bidirectional protocol, e.g., USB or ethernet (or FireWire).

Bottom line: If clock quality is critical to your design, then it would be better to choose a communications protocol other than S/PDIF. Popular choices these days seem to be AVB, Dante, or other ethernet protocols, as well as non-ethernet options like Analog Devices' A2B or proprietary designs (see Linn Exact link). I think it's great that AD offers S/PDIF I/O as an option on SigmaDSP, but it does create more challenges than other protocols. You might find a shorter path to success by adopting another protocol, while keeping the ADAU1466 as the core.