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?

 

Thanks

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) {
    count++;

 

    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;
    Receive_ADC_Samples();
//  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;
       
    inCount++;
    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);

 

    Transmit_DAC_Samples();
}

Outcomes