AnsweredAssumed Answered

Distortion present on one channel of 21469 audio but not others

Question asked by MikeSmithCanada on Mar 2, 2011
Latest reply on Apr 19, 2011 by DeepV

I am outputting identical copies of an audio signal to 8 channels on a 21469 Ez-kite lite audio kit -- but channel Left2 out is distorted. (see pictures)


Can somebody tells me if the following explanation makes sense


The code is a modification of the audio talkthrough ISR from the 21469 example directory


Heart Signal is a simple cosine generator -- the print statement is a simple check that the larger output signal on channel Left 2 is not the result of a software quiltch -- Left Channel 2 shows a signal with amplitude greater than 0.1


The ISR routine (Audio_Prempemtive Task) outputs the cosine signal to all channels

The TTCOS2011_AddTask -- activates a semaphore in a linked list to cause a task to run outside the ISR


Left Channel2 out is always distorted -- but right channel out 2 is only distorted when code is not optimized

Neither channel is distorted (or not obviously distorted) when the TTCOS2011_AddTask is shortened


Neither channel is distorted (or not obviously distorted) if the Receive_ADC_Samples() and Transmit_DAC_Samples( ) calls are put adjacent in the code


All these items suggest a timing issue -- race condition between the time the Transmit_DAC_samples( ) routine puts values into the Left and Right channel variables and when the back-ground DMA task whisks those values off to the DAC.


QUESTION 1 -- I could accept in principle that the output signal, under this race condition, would suffer from 'one-out ness', transmitting a signal value late, but I can't understand why the hardware makes the signal bigger than 0.1 ( I am currently believing that the race condition causes a sharp  discontinuinity in the signal which causes a high frequency ringing in the signal output from the DAC but because of Nyquist sampling issues associated with the DAC you only see a sampled version of that ringing which appears as an amplitude greater than 0.1


QUESTION 2 -- On the Blackfin, I would use a ssync( ) instruction to flush the write buffer. The 21469 audio example code (Transmit_DAC_Samples) does not flusgh any buffers -- I presume therefore there is no write back buffer issue on SHARC


QUESTION 3 -- If you are in the middle of an SHARC ISR, does that block the DMA activity until after the ISR routine is completed?



Mike Smith


volatile int x = 6;
void DoSomething(void) { x = 9; } // Force memory activity


const float deltaT = 1.0 / 10000; // Allow examination
unsigned int count = 0;   
double value = 0;
float signal = 0;


float HeartSignal(void) {


    value = 2 * PI * 3600 * count * deltaT;
    signal = 0.1 * cos(value);
    if (signal > 0.1) printf("Amplitude overflow\n");
    if (count >= 10000) count = 0; // Avoid cosine overflow
    return signal;


void Audio_premptiveTask(void) {
    static int inCount = 0;
//  Transmit_DAC_Samples();   // Putting Transmit here removes (reduces distortion)
    Left_Channel_Out1 =  HeartSignal( );
    Left_Channel_Out2 = Left_Channel_Out1; // Distorts with DebugNWC and ReleaseNWC
    Left_Channel_Out3 = Left_Channel_Out1;     Left_Channel_Out4 = Left_Channel_Out1;
    Right_Channel_Out1 = Left_Channel_Out1;
    Right_Channel_Out2 = Left_Channel_Out1; // Distorts with DebugNWC
    Right_Channel_Out3 = Left_Channel_Out1;     Right_Channel_Out4 = Left_Channel_Out1;
    if (inCount == (1 * processLength))  // Cause a task to run outside ISR
          TTCOS2011_AddTask(DoSomething, NO_DELAY, RUN_ONCE);
    if (inCount >= (2 * processLength))
        inCount = inCount - (2 * processLength);