Lib I2S Issues
-
- XCore Addict
- Posts: 224
- Joined: Tue Jan 17, 2017 9:25 pm
Lib I2S Issues
I migrated a new design from XCore 200 to the new XE316 and due to the pin difference I had to move I2S to use the 4 bit port configuration. I'm having significant issues getting this to function properly at sample rates above 48 kHz. My device needs to function up to 192 with minimum 8 channels in and out. I'm using the 4-bit I2S Frame Slave component. One thing I see at higher sample rates is the i_i2s.init seems to keep firing even when restart_status = I2S_NO_RESTART;. Has anyone encountered this issue and found a solution?
-
Verified
- Experienced Member
- Posts: 69
- Joined: Wed Feb 17, 2016 5:10 pm
Would you describe it as working "perfectly" at and below 48kHz? a 4-bit port is slower than a 1-bit port in the following ways:
- For a given clock, the buffer is 4x shorter (in time, not in bits) so the CPU thread will need to tend to the port 4x as often
- To interleave/de-interleave the channels from the buffer requires a series of zip/unzip instructions
At what sample rate are you seeing it start to fail?
- For a given clock, the buffer is 4x shorter (in time, not in bits) so the CPU thread will need to tend to the port 4x as often
- To interleave/de-interleave the channels from the buffer requires a series of zip/unzip instructions
At what sample rate are you seeing it start to fail?
-
- XCore Addict
- Posts: 224
- Joined: Tue Jan 17, 2017 9:25 pm
48 kHz seems fine, when I go to sample rates above this, I notice a few skips at 88.2 and 96 kHz, but then above that seems completely unworkable with the timing. I also notice this, which was posted AFTER we spent $$$$ for these PCBs. Highly unfortunate. https://github.com/xmos/lib_i2s/issues/141
-
Verified
- XCore Legend
- Posts: 1158
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
Things you could try to use your pcb:
- #pragma unsafe arrays in relevant places
- bump the core clock freq
- #pragma loop unroll in relevant places
- make sure compiling everything with - O3
- put the i2s related threads in high-priority mode
- #pragma unsafe arrays in relevant places
- bump the core clock freq
- #pragma loop unroll in relevant places
- make sure compiling everything with - O3
- put the i2s related threads in high-priority mode
Technical Director @ XMOS. Opinions expressed are my own
-
- Active Member
- Posts: 38
- Joined: Sat Jul 08, 2023 5:15 am
Other ideas:
- depending on what your other tasks are doing, put core in fast mode (can’t remember if lib_i2s does this by default)
- xscope tracepoints at begin/end of I/O loop (mod N*Fs so you don’t affect experiment too much) to check meeting timing requirements
Debugging XMOS code is challenging are there are quite a few things I wish I’d known when I started. This forum has been very helpful though.
- depending on what your other tasks are doing, put core in fast mode (can’t remember if lib_i2s does this by default)
- xscope tracepoints at begin/end of I/O loop (mod N*Fs so you don’t affect experiment too much) to check meeting timing requirements
Debugging XMOS code is challenging are there are quite a few things I wish I’d known when I started. This forum has been very helpful though.
-
- XCore Addict
- Posts: 246
- Joined: Mon Jan 08, 2018 4:14 pm
as said above the timing required to feed the 4 bits port is 4 time less than in the normal 32bit buffered mode, so you also have to optimise the whole I2S deliver loop by splitting the whole number of instructions available between 2 transfer evenly between each of the 4 port access. typically the time taken by the 8 channel transfer between decouple and i2s task becomes a critical one.