AVB-DC I2S slave

[akp]

I have an application where I would like multiple AVB-DC boards connected together but where I have the MCLK, LRCLK, BCLK recovered on one board (master) and then distributed down the line in parallel with my ethernet, so the other DC boards don't recover the media clock but get it directly from the primary DC board, and it doesn't configure the PLL or anything. Would this be very difficult to do?

My guess is it means initializing AVB with DEVICE_MEDIA_CLOCK_LOCAL_CLOCK rather than DEVICE_MEDIA_CLOCK_INPUT_STREAM_DERIVED, skip the PLL configuration, and further somehow figuring how to change I2S code from master to slave, presumably there is some xmos I2S code somewhere that supports both master and slave.

Any reason this shouldn't work?

Obvs I would have to cut the trace on the PLL output or something on the slave boards, that's not an issue.

[xsamc]

Hi akp,

I'm not aware of this setup having been investigated or attempted before by XMOS, as (if I'm understanding your description correctly) it discards a key piece of the functionality provided by our AVB solution. Can I ask why you want to configure you AVB-DC system in this way?

I imagine that to get this to work you'll need separate drivers for each clock line on the 'master' board. The clocks could then be transmitted over controlled impedance cable (such as Cat5) with series resistor termination, to ensure synchronisation these cables would need to be length matched.

The I2S library does have a slave mode, but I couldn't say how much effort would be required to integrate this into the AVB codebase.

Cheers,
Sam

[akp]

Hi Sam,

Thanks for the reply. Knowing it is possible theoretically means it is a feature I could add in later and use the AVB clock recovery for a first attempt to avoid lots of software development.

The reason for this is I want to use AVB to record lots of channels of audio and I need really good time synchronization so I can do analysis on the various channels (they have a known geometric relationship). My idea is to (essentially) use several AVB-DC circuits; up to 16 to give 64 channels. Honestly it isn't AVB that I need, but simply a method to put lots of audio channels on Ethernet, and AVB seemed like a good way to do that.

Typically the AVB recording is synchronized well enough for what I want (i.e. within the expected geometric variation) but there is an issue I have found and discussed here on the forums that can cause integer sample delays in the network https://www.xcore.com/forum/viewtopic.php?f=8&t=4388

Of course if the cycle slip issue were fixed that would solve my problems without resorting to another method of I2S synchronization. Like I said in the forum topic it seems like the playback is synchronized OK, it is the recording that suffers from this issue. So I don't know why playback would be OK but recording wouldn't be.

My network will be physically linear array so I expect something < 100ns delay end-to-end if I do a decent job of clock buffering (e.g. zero-delay buffers with low fanout).

Cheers,
Adam

[larry]

Tying I2S clocks together in LOCAL_CLOCK mode should work in principle. System clocks (25MHz) will run independently, but that won't cause trouble, because you will cut off the PLL sync signal (in LOCAL_CLOCK mode the signal is based off XCore's internal 100MHz reference timer). As long as I2S can receive data at the right rate and push it into media input FIFO, everything else in a talker node is sample driven and should work fine.

I wonder if another solution would work to allow you to record multiple channels with precise alignment. How about a distributed TDM16 data line and a central node, which is a multichannel USB audio device?

[akp]

Yes I had thought something along those lines. I really like to put the data over Ethernet but at the end of the day maybe USB is better. I actually only need something like 16kHz sampling so I could put many channels on a USB 2.0 bus.