I2S Ports synchronized by same clock in two parallel tasks

[MarcAntigny]

Hi,
We are developing using XU232-1024 chip for usb audio device. We aim at handling 16 outputs over I2S.
To do so, we use the reference design 6.15.2 with a modification in the audio/i2s part :
Instead of having one deliver task to handle 8 I2S IO, we have two deliver tasks running in parallel (that we call deliver1 and deliver2) that would handle each 8 I2S IO (to get the 16 I2S IO in total).
deliver1 task is managing the LRCLK and synchronizes with deliver2 when needed (at LRCLK change and to handle command from mixer).

The problem we have is that the I2S frame of deliver2 is one bitclock cycle behind the I2S frame of deliver1.

Yellow : LRCLK / Blue : Bitclock
The dotted vertical cursor corresponds to when the I2S frame from deliver1 starts.
The plain vertical cursor corresponds to when the I2S frame from deliver2 starts.
(my scope is only two channels so I couldn't display everything at the same time)

All I2S port are clocked with the same bitclock clock block, so both frames should be starting at the same time.
Do you have any idea of what is happening ? Could the synchronization of the port on the bitclock be broken because we are using two tasks ?

Cheers,
Marc

[aclassifier]

Sorry for not being able to help! But I have two somewhat related asides:

I am struggling with finding the (?) audio output driver for the 3.5 mm jack on the XK-USB-MIC-UF216 MIC_ARRAY board. Q1, any idea?..

So I stumbled upon your "we use the reference design 6.15.2". Q2: which one is this?

Update 1: Is this the one I'm looking for? AN00219: Low Resolution Delay and Sum Example as suggested in Microphone array AN00219 no sound

Update 2: I also know about this, but there is not so much "free code" there: (6.16.1alpha1).pdf]USB Audio Design Guide 110 pages!

[MarcAntigny]

Hi,
Unfortunately I am not sure I can help you on the XK-USB-MIC-UF216 MIC_ARRAY, I never used those boards...
About the "reference design 6.15", it is the software reference code available for Xcore-200 programming : https://www.xmos.ai/file/usbaudiodevice-software/
That is the basis of our development, and we did the modifications I mentioned in my first post to handle 8I2S IO.
Back to the topic, sadly we couldn't find any solutions for now...

PS : By the way, I don't know why but I couldn't find an access to the refereence design page from XMOS.ai website, I needed to go from Google directly to the page. I know that XMOS is moving towards their new AI chip, but I think it is disrespectful to companies that worked with their other chips since several years to hide this kind of thing / reducing support. I am not sure we will trust their new AI chip, if it is managed the way the support for Xcore 200 is.

PS2 : The forum xcore.com and the website xmos.ai are constantly unavailable. If someone from XMOS is reading this, please try something...

[akp]

Have you tried to simply get 8 I2S running in a single task? It might take some extra optimization, but your I2S clock frequency is pretty low. I can do 32 ch of TDM (4 x 8ch lanes) at a bit clock of 24.576 MHz so I think you should be able to do 16 ch of I2S at an LRCLK of 3 MHz.

[MarcAntigny]

Hi akp,
We didn't really investigate having 8 I2S on a single task. The main reason is because we have other threads communicating with the "deliver1 and deliver2" threads (for ADAT mainly), so we preferred a parallel approach that seemed to be the most reliable one (before discovering I2S dis-synchronisation). But maybe it could work, as long as it is not too long, we have a lot of processing to handle after reading I2S, so the quickest way is the better.

But to be honest, I am really surprised that there is no explicit reason of the delay between the two I2S frames. All ports are synchronized to the same clock, with software sync through channels between threads. If it is a known limitation on I2S port writing I could understand this, but I would like to be sure, before breaking architecture.

[akp]

I am sure there is no reason why the idea behind what you've done won't work. Most likely there is some software error in the implementation of deliver2 since that's the one that's delayed. Honestly you've got limited cores so I always find cores are a premium for me. If you free up a core and move the processing to a new pipeline stage on another core that will give you the same or better performance.