XMOS chip buffering issue

Technical discussions related to any XMOS development kit or reference design. Eg XK-1A, sliceKIT, etc.
Post Reply
Bayanaa
Active Member
Posts: 33
Joined: Fri Feb 07, 2014 3:03 pm

XMOS chip buffering issue

Post by Bayanaa »

I am working on MC board for audio processing. I added dsp core between decouple and audio cores. dsp core includes c codes. I am using 4 channels to record audio. When I increase buffer length then mc board return audio samples weird as shown in figure below.

Smaller buffer length works OK. But length is more than 53 it return like below figure.
xmos.jpg
(22.22 KiB) Not downloaded yet
xmos.jpg
(22.22 KiB) Not downloaded yet
1. What is the problem?
I cannot find what is the reason for this.
2. How to solve this if buffer length is more then 100 or more?


here is part of source code in .xc

Code: Select all

#pragma unsafe arrays
static inline void doDspIn(int samples_in_pre[], int samples_in_post[]){
#pragma loop unroll
    for (int i=0;i<NUM_USB_CHAN_IN;i++)
        {
            cfunction(i,samples_in_pre);
            samples_in_post[i] = samples_in_pre[i];
        }
}
here is part of .c code named cfunction

Code: Select all

#define BUFFER_SIZE (53)
...
void cfunction(int iChan,int  * sampleFromXC)
{

    for(int iSample=0; iSample<BUFFER_SIZE; iSample++)
    {

                 bCh[iChan][iSample] = sampleFromXC[iChan];
                 sampleFromXC[iChan] = bCh[iChan][iSample];

    }
}

3. The function routine is wrong? So this problem is occurring?


markb
Member++
Posts: 18
Joined: Tue Oct 08, 2013 1:53 pm

Post by markb »

Hi Bayanaa,
I assume you are trying to run this program in real-time.
It is difficult to diagnose your problem from the small code segments you have included. However, here are some general guidelines about real-time dsp audio processing.

You have to read data from the channels faster than the audio sample-rate.
If you do not, one of the 2 following things happen:-
1) For 'streaming chan' audio data will be lost (new data overwrites old unread data)
2) For 'chan' the audio channel will block (waits for a read of the old data, this causes a loss of new data nearer the audio input)

Assuming your data rate is 48 KSamples/sec, and that the processor clock speed is 100 MHz,
then you will only have 2083 clock cycles to do DSP before you have to get another sample.
If you are using 4 channels of audio, this value drops to 521 cycles per set of 4 samples.

So short buffers are better for real-time processing. Buffers should NOT be used to collect an array of samples, and then do the same processing on each element of the array. Buffers add extra latency into the data-stream, which is generally a bad thing in real-time audio.

Buffers should be used to de-couple the input and output streams from the DSP. A single element/channel is sufficient for this. Buffers may also need to be used when doing DSP on a set of samples that all occur at the same time.
E.g. Mixing down 4 input channels of audio into one output channel.

Buffers may also be required for time-related audio effects, and filters. E.g. Delay, Reverb, Bi-Quad filters.
These buffers are in addition to those used to de-couple the DSP from the audio I/O, and these additional buffers sit inside the DSP modules.

Here are some links to DSP audio effects written for the SliceKit board, however the DSP algorithms should be portable to the MC platform, as they only interface to audio 'streaming channels'.

Loudness: https://www.xmos.com/node/16090?page=4
BiQuad Filter: https://www.xmos.com/node/16090?page=0
Short Delay: https://www.xmos.com/node/16090?page=5

Cheers Mark_B
Post Reply