Insert Audio Algorithm here! 5535 eZdsp and Connected Audio Framework

Hi;

I'm headed down a similar road; I might start with the framework, but the final design will be using the board stand-alone to process audio in from mikes and play to headphones. I'd be very interested in what you find out, as I see the same problem - "insert something here" - my middle finger didn't work, so I'm interested in a tangible example. Ideally, FFT the data, filter it, then IFFT it back. I'd be glad the share notes with you.

I just got the board, so I'm not very far down the learning curve yet. I'd rather not get bogged down with the io stuff, rather concentrate on the processing in between.

Dave Wicker

Wow Ming Wei!

This is genius!, thanks for your comprehensive reply, now I got a much better sense of it, and came out with a simple test for this procedure. I include it here for future references:

In the section of "Insert Playback audio algorithm here"

        /*                                                                    */
        /* Insert Playback audio algorithm here */
        /*                                                                     */
        int i;
        for (i = 0; i < numOutSamps; i++){

        	*pbOutBufLeft = (*pbOutBufLeft) * 0;
        	*pbOutBufRight = (*pbOutBufRight)/2;

        	 pbOutBufLeft += 2;
        	 pbOutBufRight += 2;
        }
        /*****************************************/

Cheers!

However!

A new question arises!

If the samples are 32 bits, why are they stored in an Int16 location? when looping as in my previous reply, I have to increase the value of the pointer by 2, to account for this. 

This causes number of questions, such as how to perform operations on these numbers, or to add them with other samples as in a filter algorithm. 

Then, if we use for example a long value to store the addition of two samples, and then try to fit it back into the buffer which is... Int16? 32? bits, see the doubt?

At the moment I try to add *pbOutBufLeft with another Int16, put it into a "long" location and then divide it by two, to then cast it to Int16 and fit it again in *pbOutBufLeft... but then I think about the 32 bits...

Any word on this will be much appreciated. 

Best

roberto

Hi Roberto,

The actual bit per sample in the audio framework is 16 bit, but it sets to 32 bit per sample simply because of the way I2S with DMA works. The maximum number of bits per sample supported in C55x5 I2S is 32. The data transmitted by the DMA from I2S register is 32 bit per sample, no matter how many actual bits per sample is. The C55x5, on the other hand is a 16-bit machine, so the 32 bit per sample will be stored in two 16 bit words.

In the case of 16 bit per sample, the first word of a audio sample is the actual audio data and the second word is filled in with zero. It can be changed by the by setting I2S from left adjustment (current setting) to right adjustment. In your playback algorithm, you should always set  the second 16-bit word to zero. in your record algorithm, you should ignore the second 16-bit word.

To get to 24 or 32 bit per sample case, you will have to change the audio codec settings, I2S settings and USB settings to get there. In those cases, the second 16-bit word have been used for store the 16-23 bit or 16-31 bit. Only then, you will need 32 bit operation to process those audio samples.

Best regards,

Ming

Good!

Thanks again Ming, this also clarifies a lot, I figured it all had to do with the machine being 16 bits, however I also imagined the actual sample was larger than 16bits. 

Well, now with these concepts, altogether with the Teaching Rom, I have been exploring this framework.

Thanks a lot... again! Best!

Roberto