Xcore200 USB channel limitation

Technical questions regarding the xTIMEcomposer, xSOFTip Explorer and Programming with XMOS.
User avatar
infiniteimprobability
XCore Legend
Posts: 1116
Joined: Thu May 27, 2010 10:08 am
Contact:

Re: Xcore200 USB channel limitation

Postby infiniteimprobability » Tue Oct 16, 2018 5:28 pm

We can't accept 3Byte words because unpacking is not truly parallel to the other processes of the audio stream. For each channel, a sample is received from USB then unpacked then send to mixer. And then another sample for another channel and so on. So the mixing thread is waiting for every sample to be send (so to be unpacked before) and do nothing during this time. Unpacking/packing from 3 Byte thus adds some time that we can't waste on that (because of other tasks such as mixing etc...)


All of the cores run sequentially true. However the decouple task exchanges all channels in one sample period at a time (a frame). Un packing is only a few cycles per sample although you do have a lot of samples so maybe this is an issue in your case.

I think it would be orders of magnitude less effort to modify decouple than implement a new feature to the USB low level driver (pretty hard core assembler and in depth knowledge of USB).

You could either:

- Add a double buffer and pass the last unpacked samples using straight line code, then unpack into the other buffer
- If your mixer is on the same tile, use the "unpack after exchange" code but just pass a pointer across. That will save you 40 odd out instructions + memory loads..
MarcAntigny
Active Member
Posts: 46
Joined: Tue Feb 13, 2018 2:50 pm

Postby MarcAntigny » Wed Oct 17, 2018 1:40 pm

I think it would be orders of magnitude less effort to modify decouple than implement a new feature to the USB low level driver (pretty hard core assembler and in depth knowledge of USB).
Yes, we will try to modify the decouple to split the task between exchanging samples (IN/OUT with mixer) and packing/unpacking. It should let the decouple task do its packing/unpacking while the mixer task does its calculations (in a similar way to the communication between audio task deliver and mixer). Unfortunately the mixer is not on the same tile as the decouple so we can't only use a pointer.
I'll give you an update on my progress.
At the moment, I'm trying to use 3 Bytes per slot to benchmark the perf (and to check if the optimization is needed). But right now, it works fine for 30, 36, 38, 40 channels but for 32 and 34 channels I got a hashed output. Really disappointing.

Who is online

Users browsing this forum: No registered users and 31 guests