I2S slave & clock recovery

[SirShagsalot]

Hi,

We have been trying to use the I2S_slave module from the lib_I2S in conjunction with clockgen.xc to implement a I2S slave PLL clock locked to the I2S clock.

We did so by in effect replacing ADAT by I2S in clockgen and defining an I2S_RX function based on SPDIF_RX with the relevant callback interface service routines, based on the lib_I2S documentation.

Documentation for clockgen is sadly worse than non-existent, as it's existence is barely acknowledged in the USB Audio documentation, yet is such a crucial component for SPDIF/ADAT and in our case I2S slave.

Unfortunately we seem have a few issues that cause our system to work incorrectly, specifically I2S data appears to be "loosing samples" causing input from I2S running at lower rates than the same SPDIF Signal sourced from the same signal source. We have manually verified the clock rates of BCK & WCK applied to XMOS to be correct and we can directly connect a ESS DAC Chip with internal ASRC to this I2S source and correctly decode the I2S signal to audio.

We are a bit snookered where to look and how to bets approach the rouble shooting. If anyone happens to have a working example of I2S slave with clock recovery vial C2100 PLL it would help a lot.

Greez SSAL

[SirShagsalot]

Just to answer my own post, we traced the problem to a non-compliance with the I2S specification in how the I2S_slave library has been implemented. I created another post as the system was not very clear my post was awaiting moderation:

http://www.xcore.com/viewtopic.php?f=37&t=5989

We are currently considering how I2S_slave may be modified to operate correctly. If this is doable we will be able to interface with Clockgen and have working system.

[Trycia31]

Hi,

We have been trying to use the I2S_slave module from the lib_I2S in conjunction with clockgen.xc to implement a I2S slave PLL clock locked to the I2S clock.

We did so by in effect replacing ADAT by I2S in clockgen and defining an I2S_RX function based on SPDIF_RX with the relevant callback interface service routines, based on the lib_I2S documentation.

Documentation for clockgen is sadly worse than non-existent, as it's existence is barely acknowledged in the USB Audio documentation, yet is such a crucial component for SPDIF/ADAT and in our case I2S slave.

Unfortunately we seem have a few issues that cause our system to work incorrectly, specifically I2S data appears to be "loosing samples" causing input from I2S running at lower rates than the same SPDIF Signal sourced from the same signal source. We have manually verified the clock rates of BCK & WCK applied to XMOS to be correct and we can directly connect a ESS DAC Chip with internal ASRC to this I2S source and correctly decode the I2S signal to audio. Sometimes after hours of debugging I just take a short break and relax on https://mostbet.net.in/ it really helps to clear my head before diving back into PLL timing issues.

We are a bit snookered where to look and how to bets approach the rouble shooting. If anyone happens to have a working example of I2S slave with clock recovery vial C2100 PLL it would help a lot.

Greez SSAL

Jumpin in late, but since you’re dealing with the I2S slave + clockgen.xc setup, here are a few areas that often get overlooked and can cause exactly the kind of intermittent “lost samples” you’re describing:

It’s worth double-checking whether your callback service routine timing is aligned with the LRCLK edges. In slave mode, even a small mismatch between word select and data line sampling can create dropped or duplicated frames without obvious clock errors. Also, make sure your bclk input isn’t being edge-synchronized twice (some examples in lib_i2s implicitly resync it, which can distort timing when the PLL already does that). If you’re feeding clockgen from the same MCLK domain, verify that the recovered PLL output actually meets jitter specs at higher sample rates. I’ve seen instability above 96 kHz when the feedback divider in the C2100 loop wasn’t tuned tightly enough.

You can also temporarily route your recovered clock out to a GPIO and scope both it and the incoming BCLK to confirm the lock stabilit, that usually shows whether the drift is at the clockgen or I2S layer.

There was a working reference in one of XMOS’s older USB audio repos, under app_usb_aud_xk_216_mc, where they used the C21xx PLL for S/PDIF but the structure maps directly onto I2S with minimal changes. Worth diffing their ISR timing macros with yours to see if you’ve got hidden latency in your ISR loop.

If you want, I can help you draft a minimal I2S slave clock recovery test harness (just clockgen + single RX task) so you can isolate the PLL before adding the full pipeline. Would that be useful?