Channel limits for I2S

[Zip]

I've been reading the manual for lib_i2s and I'm kind of confused about the resource usage limits. Looking in table 4, I see that with a MCLK of 24.576 MHz and 32-bit words, the MAX IN and MAX OUT is 1. Does that mean that I can only have one input data port and one output data port? I was hoping I could use XMOS chips to build a serious multichannel interface with 24 output channels and 16 input channels. That means 12 input ports and 8 output ports.

[Ross]

These values do look rather pessimistic and the table is a little hard to interpret, IMO. I will chase this internally for an update.

Though, for those kinds of channel counts we'd typically expect to use a TDM interface.

Are you just wanting to do I2S -> I2S or USB -> I2S?

[infiniteimprobability]

I've been reading the manual for lib_i2s and I'm kind of confused about the resource usage limits. Looking in table 4, I see that with a MCLK of 24.576 MHz and 32-bit words, the MAX IN and MAX OUT is 1. Does that mean that I can only have one input data port and one output data port? I was hoping I could use XMOS chips to build a serious multichannel interface with 24 output channels and 16 input channels. That means 12 input ports and 8 output ports.

I agree with Ross on this one - it's (very) pessimistic documentation. The "old" I2S (non-master, now deprecated) did struggle at high SRs due to having to many callbacks and not being optimised for best use of port buffers.
Since version 6.0.0 the "frame based" API is default (see changelog). I suspect the docs didn't get updated (our bad).

We actually test at 192kHz 8ch in 8ch out as part of the test test params and so it looks like the docs are lagging. We do this under fully a loaded chip so we know that I2S has 1/8 of the core MIPS max. Real world performance will be better.

Apologies for this and you were right to post a query about this. An issue has been raised to address the docs so it won't get lost - https://github.com/xmos/lib_i2s/issues/159

Internally, lib_i2s does lots of port activity at the start of each frame, loads up the output buffers and empties the input buffers. So you have the majority of the frame period (1/LRCLK) to execute the callbacks which exchange samples and check for restart.
The only things that affect performance are: number of IO (total number of input and output ports), how quickly the callbacks return and the LRCLK rate. Master clock rate is a don't care because we use internal hardware dividers to generate the bit clock.
32b I2S is slightly more efficient than 24/16b because we don't need to pre-set the port buffer count.

We also test for callback back-pressure up to 384 kHz for 6 in 6 out which is roughly where it runs out of stream. So 12 channels total at 384kHz for a fully loaded chip.

So you can definitely have 8 in 8 out at 192kHz with 62.5MIPS threads (worst case). You could likely double that with a few more MIPS (have say max 5 threads so each one gets 120MIPS) and short callbacks. Halve the max sample rate and you can double the channel counts as a rule of thumb.

However since you only have 16 x 1b ports per tile, and you need MCLK, LRCLK and BCLK, and you only get 2 channels per data line, you will be IO limited likely. There are ways around this:

1) Put an I2S slave on the second tile and get more data lines
2) Use 4b ports for I2S data. This does mean a hit in maximum sample/IO rate quicker but it might be enough.

What is your desired sample rate?