Starterware/TMDSLCDK6748: Audio Feed Thru with DSP Library Demo

I would like to try to explain my problem in more general terms (but also specifically related to the C6748). As I understand it, the example project mcas_c674x_c6748_lcdkC6748  configures the codec and EDMS3 channels. It then uses direct memory access (DMA) to transfer data byte-by-byte between the codec input to loop back to the output. Please correct me if I'm wrong. 

What I'd like to do is insert a FIR filter in between the codec input and output. This means I need to somehow grab the data (either rxBuf or txBuf) and process it. I tried this first pass below for illustration, but I think it has problems:

            /* Copy the buffer */
            memcpy((void *)txBufPtr[lastSentTxBuf],
                   (void *)rxBufPtr[lastFullRxBuf],
                   AUDIO_BUF_SIZE);

            // FIR filter
            DSPF_sp_fir_gen((const float *) rxBufPtr[lastSentTxBuf], ptr_h, (float *)txBufPtr[lastSentTxBuf], NH, NY);


            /*
            ** Send the buffer by setting the DMA params accordingly.
            ** Here the buffer to send and number of samples are passed as
            ** parameters. This is important, if only transmit section 
            ** is to be used.
            */
            BufferTxDMAActivate(lastSentTxBuf, NUM_SAMPLES_PER_AUDIO_BUF,
                                (unsigned short)parToSend,
                                (unsigned short)parToLink);

Hopefully this will show the problem. Since the data is transferred to/from the codec in terms of  bytes, do I need to assemble the data into 4-byte chunks to re-create the original floating point number? If so, won't it introduce too much delay to be able to stream the audio in real time? The code I have above sends bytes to the filter, not floating point numbers (the parameters are of type float).  I would have to insert quite a lot of code to structure the data before and after DSP function. Also, am I inserting the dsp function in the right place? It seems that I cannot read the rxBuf/txBuf without triggering a codec operation.

I hope that makes sense. 

thank you,

Scott

Hi Scott,

I've notified the sw team. Their feedback will be posted here.

Best Regards,
Yordan

Hi Yordan,

Thank you for your response. Here is my latest code that I'm working on. It strips out one channel from the receive buffer, converts the byte-array to floats, calls the DSP function, then reverses the process.

        if(lastFullRxBuf != lastSentTxBuf)
        {  
            /*
            ** Start the transmission from the link paramset. The param set 
            ** 1 will be linked to param set at PAR_TX_START. So do not 
            ** update paRAM set1.
            */ 
            parToSend =  PAR_TX_START + (parOffTxToSend % NUM_PAR);
            parOffTxToSend = (parOffTxToSend + 1) % NUM_PAR;
            parToLink  = PAR_TX_START + parOffTxToSend; 
 
            lastSentTxBuf = (lastSentTxBuf + 1) % NUM_BUF;

            //strip off channel one
            deInterleave((void *)rxBufPtr[lastFullRxBuf], AUDIO_BUF_SIZE/4, buftemp);

            //convert char to float for filter
            charToFloat(buftemp, AUDIO_BUF_SIZE/4, inputDemoSignal);

            //Filter blockprocessing
            DSPF_sp_fir_gen_cn(inputDemoSignal,coeffsFilter,outputDemoSignal,NUM_OF_TAPS, NUM_SAMPLES_PER_AUDIO_BUF);

            //reassemble into 2-channel buffer
            interleave(outputDemoSignal, AUDIO_BUF_SIZE/4, (void *)txBufPtr[lastSentTxBuf]);


            memcpy((void *)txBufPtr[lastSentTxBuf],
                   (void *)rxBufPtr[lastFullRxBuf],
                   AUDIO_BUF_SIZE);

            /*
            ** Send the buffer by setting the DMA params accordingly.
            ** Here the buffer to send and number of samples are passed as
            ** parameters. This is important, if only transmit section 
            ** is to be used.
            */
            BufferTxDMAActivate(lastSentTxBuf, NUM_SAMPLES_PER_AUDIO_BUF,
                                (unsigned short)parToSend,
                                (unsigned short)parToLink);

It's still not working yet, but I would like to know if I'm on the right track.

thank you,

Scott

Hi Rahul,

Thank you for the information. Can you give me a file name or project name or something more specific? There are a lot of links, references, libraries, RTOS, to the project you referred to me. I have downloaded a lot of libraries but I'm not sure where the project or the demo code is located.

thank you,

Scott

Is it this project:
processor_sdk_rtos_k2g_4_00_00_04/demos/audio-preprocessing/realtime_demo_bios/k2g

Since I don't have the K2G board, I'm only interested in the source code. I only want to use it to understand the LCDK board, which I do have. 

thank you,
Scott

Rahul,
Thank you for the reply. I think the problem is that I have not asked the right question yet. You are probably giving me a great solution... to a different problem. Let me try restating my question.

I have asked for a demo showing the audio feedthru with DSP, but (after reading other posts), what I'm asking is this:

How can I use the rxBufPtr to take both right and left channels at once, and the original memcpy() function copies directly its value to txBufPtr?

This is actually a paraphrase of another post, so I think I'm having the exact same problem.

Also, this may partly answer my previous questions:

My Question: Since the data is transferred to/from the codec in terms of bytes, do I need to assemble the data into 4-byte chunks to re-create the original floating point number?

My Answer: No. You need to "deinterleave" the data into 16-bit signed integers. Then "reinterleave" the data into 2-channels into unsigned char. You can do any sort of DSP on the deinterleaved data.

The suggestons in the post (which I don't know how to reference here) is:
"A few things to try, and things that have helped me:

- When you copy to a local buffer, make sure it passes audio before adding processing.

- Keep an eye on data types. PCM data is a signed integer, the buffers in the example are unsigned ("Void *" I think... it's been a while). This can cause some odd distortion.

- It can be helpful to view the waveforms on an oscilloscope to try to discern what is happening to the data. This is one of the biggest helps for me.

- Don't forget that the filter needs some history (previous input samples) in order to work. The sample at time zero needs the previous "n" samples for calculation, where "n" is the length of the impulse response (or number of filter coefficients).

Your copy method should work, but you may want to try copying to a large(r) buffer. For example, I have in the past used a 4096 sample long buffer, copying the data in 1024 sample chunks, like a circular buffer. Use separate read and write offsets to copy to and from this buffer, reading at a point after your filter has processed the data."

I think I'd like to understand how the sampled are managed/transfered/encoded in the rx/txBufs. Are there any references to how the samples are encoded?
thank you,
Scott

Regarding the MCASP demo, do you know which format is being used (single slot, single serializer, multiple slot, single serializer, etc)?

I'd like to understand how the sampled are managed/transfered/encoded in the rx/txBufs. Are there any references to how the samples are encoded?