Problem with XMOS S/PDIF RX

[lokesh327]

Hello,

I am using XMOS board with S/PDIF slicekit.

I am using S/PDIF RX module in my application to read audio data from S/PDIF and follow the process of storing the samples in input fifos and create AVB Frames.

As I need only SPDIF RX to read data, I have just followed the sample application for S/PDIF_RX from xmos.

When I am reading the USB 2.0 document, found a interesting point that SPDIF RX should be synchronized with clockgen.

Do we really need the clockgen for S/PDIF RX.

As attached sample application file from XMOS, i have implemented the same algorithm to initialize the SPDIF Receiver and get samples over the streaming channel end.

Additionally, we noticed a small issue like sometimes we find a sample delay in the right channel. Can you also help me in getting the info from where the issue might occur.

[infiniteimprobability]

Using SPDIF as a source of data to feed into the AVB talker will need some work on the clock architecture. The incoming SPDIF stream has a clock encoded into it. Th SPDIF rx software reads the incoming stream and generates a PCM sample when it has successfully decoded a frame, and then outputs it over a channel end. This will happen synchronous to when a frame has been full received and decoded, which will be governed by the mclk of the transmitter.

To keep things bit-perfect, the AVB talker mclk will need to be synchronised to the incoming stream. That's where the clockgen task comes in (although it does more than that such as failing over to internal clock if no stream recovered clock available). Basically it counts samples and then drives a PLL to regenerate the mclk.

So some work to do, and a hardware PLL will be needed to get this right, unless you know that the AVB talker and SPDIF transmitter share the same clock. It is certainly doable though. The alternative is ASRC, but there is only some experimental module to do this here https://github.com/xcore/sc_dsp_filters), unless someone else knows of a solution.

This can all be done - but you will need to write some code to get the AVB talker to use the recovered clock from clockgen. The AVB listener can use the input stream derived clock - i.e. it can synch to the talker and recover the clock from the 1722 stream.

Do we really need the clockgen for S/PDIF RX.

Yes, or something like it.

As attached sample application file from XMOS, i have implemented the same algorithm to initialize the SPDIF Receiver and get samples over the streaming channel end.

That's fine - but will generate samples as they arrive, not necessarily when you want them if you are using a fixed local clock on the SPDIF rx end.

Additionally, we noticed a small issue like sometimes we find a sample delay in the right channel. Can you also help me in getting the info from where the issue might occur.

Not sure - might be if you are accidentally resampling asynchronously.. You could get occasional dropped or repeated sample.

[lokesh327]

Hello,

Thanks for the reply.

The SPDIF rx software reads the incoming stream and generates a PCM sample when it has successfully decoded a frame, and then outputs it over a channel end. This will happen synchronous to when a frame has been full received and decoded, which will be governed by the mclk of the transmitter

This means the system has to run with an avb listener also and make the media clock type as media_fifo_derived (synchronize based on incoming stream)

If I am using a media clock type as media_fifo_derived, I know that i will synchronize the local clocks using the PLL.

What if there is no incoming streams and this system should behave as ptp master. This system is designed with local clock for media clock type.

Is there any possibility that S/PDIF RX works without any stream synchronization when the media clock type is local_clock.

Thanks

[infiniteimprobability]

This means the system has to run with an avb listener also and make the media clock type as media_fifo_derived (synchronize based on incoming stream)

Yes

If I am using a media clock type as media_fifo_derived, I know that i will synchronize the local clocks using the PLL.

That's right - it will lock it's media clock to the talker

What if there is no incoming streams and this system should behave as ptp master. This system is designed with local clock for media clock type.

The PTP clock is completely separate - it runs as it's own autonomous task on all endpoints and just provides a global time service to the media clock server when required. The key here is to think about the media clock.
If there are no incoming media streams, then there can be no outgoing media streams! The talker can be assigned as the master (media) clock source (see simple_demo_controller.xc - avb.set_device_media_clock_type(0, DEVICE_MEDIA_CLOCK_LOCAL_CLOCK);
_

Is there any possibility that S/PDIF RX works without any stream synchronization when the media clock type is local_clock.

Not quite sure what you mean here - SPDIF always has a clock embedded into the stream. So if you are receiving an SPDIF stream, you either need to synch to that or apply ASRC because they run at different rates...

[lokesh327]

Hi thanks for the reply,

I have been working on this issue from last couple of weeks.

Luckly SPDIF works fine and now also started programing on XCORE 200 board.

But still the problem of one sample delay or missing sample is still open.

Working on two different boards with module_spdif_rx still produces one sample delay on right channel. Is there any way to debug or does XMOS knows this issue.

Please help me in finding an alternative for this.

Thanks
Lokesh

[infiniteimprobability]

Glad you are making headway..

Working on two different boards with module_spdif_rx still produces one sample delay on right channel. Is there any way to debug or does XMOS knows this issue.

The spdif rx module has no buffering at all - it spits out valid words as soon as they arrive. So it would be Z-Y-X-Y-X etc.. always starting with left.

Clockgen.xc, the code responsible for receiving SPDIF (and recovering the clock) only transfers the sample pair onwards on successful reception of a Y frame, so left and right have to be synchronised. Beyond that, all channels in the stream are transferred during the same sample period.

So I can't see a mechanism by which the reference design could be delaying one of the samples. Are you 100% sure your source doesn't introduce the offset?

[lokesh327]

Hi,

Yes, the order receiving was changing here.

In the process, I read the data from spdif port and store it in buffers, so that the tread is also not distrubed.

when I see the data, on start up i get Left (X or Z) and Right (Y) order and after some time the order changes to Right (Y) or Left (X or Z). I directly store the received data from spdif port on buffers and later i check whether it is left or right.

What happends if the spdif clock have to resynchronize and start sampling from one clock before or one clock later to resync. Does this type of mechanism can happend in SPDIF module

I assume that both the samples are synchronized but the order of receiving data changes. Can this be because of clocking and synchronization issue.

Or is there any problem if the MIPS for SPDIF are sufficient. Can this effect the system.

If you need any measures please let me know so that i can update you the info.

Thanks
Lokesh

[infiniteimprobability]

What happends if the spdif clock have to resynchronize and start sampling from one clock before or one clock later to resync. Does this type of mechanism can happend in SPDIF module

The resynch mechanism counts samples received and then divides to get 300Hz output toggle, which is scaled back up for the MCLK. This is independent of the sample receive logic in clockgen which will only transfer samples on reception of a Y frame. So the phase of the clock is not going to be an issue I think.

I assume that both the samples are synchronized but the order of receiving data changes. Can this be because of clocking and synchronization issue

.
Not sure what you mean - I still don't think they can be out of order because each sample has it's channel position encoded and then decoded into the stream..

Or is there any problem if the MIPS for SPDIF are sufficient. Can this effect the system.

I believe SPDIF was designed for 50MIPS. Certainly on 62.5 (500/8) you will never run out of MIPS