> IN 6713 KIT tutorial programmes are running as per
requirement . i
> am analising programme with memories.( that is very helpful to me ,
> ie, which type of running, programme memory space in every fomula( c
> plus plus).
Ok, it sounds like you're doing fine. When you have specific questions,
please let us know.
-Jeff
> On 4/2/11, Jeff Brower
wrote:
>> Krishnan-
>>
>>> u are taking a 440Hz sine wave in from the board,
>>> storing it in a buffer and outputting it.
>>>
>>> kindly help to me for the ideas of input buffer,
>>> output buffer , buffer size and how to programme
>>> it in c6713 trg kit
>>
>> 1) Please post to the group and not to me.
>>
>> 2) I am not processing a 440 Hz sine wave, the OP (Tom) is.
>>
>> 3) For programming examples on the C6713 DSK, I strongly suggest the Rulph
>> Chassaing book that I mentioned below.
>>
>> -Jeff
>>
>>> On 3/30/11, Jeff Brower wrote:
>>>> Tom-
>>>>
>>>>> Basically, I'm taking a 440Hz sine wave in from the board, storing it
in
>>>>> a
>>>>> buffer and outputting it. When I view the
>>>>> FFT of the data stored in the buffer it shows a 440Hz sine wave as
>>>>> expected. Now, for some reason, when I do some
>>>>> operations my outputted signal is affected. For instance, if I call a
>>>>> function a few times, some distortion is
>>>>> introduced in the outputted signal. When I view the FFT of the input
>>>>> signal it no longer peaks at 440Hz: the peak is
>>>>> now at a higher frequency value for some reason. The more function
calls
>>>>> I
>>>>> make, the more distorted the output signal
>>>>> is and the higher the peak of the FFT is. For instance, if I uncomment
>>>>> all
>>>>> the code below and run it, the FFT peaks at
>>>>> around 6kHz, despite the fact that I'm feeding a 440Hz signal to
the
>>>>> board
>>>>> and should in theory be getting a 440Hz
>>>>> sine wave out of it.
>>>>>
>>>>> A friend of mine suggested it might be something to do with stack size,
>>>>> but changing the stack and/or heap options in
>>>>> the linker build options has had no effect.
>>>>>
>>>>> Any ideas why this is happening?
>>>>
>>>> It's happening because you're processing on sample-by-sample
basis,
>>>> polling
>>>> for each sample. That means you're
>>>> wasting a lot of CPU time a) waiting for samples, and b) due to the
>>>> overhead
>>>> of repeating everything for each sample
>>>> instead of operating on an array of samples. For example, if
you're
>>>> sampling rate is 8 kHz, then you have 125 usec
>>>> between samples, not enough time to do BUFFER_SIZE sets of function
calls
>>>> and all other overhead.
>>>>
>>>> The solution is to change to buffer-based operation, using "double
>>>> buffering": your ISR inputs the sample, adds it to
>>>> a buffer, then exits -- nothing more. When the first buffer is filled,
>>>> your
>>>> ISR sets a flag (or does an swiPost under
>>>> DSP/BIOS) and then a foreground task processes the buffer. Meanwhile
the
>>>> ISR keeps on going with buffer 2. When
>>>> buffer 2 is full, the same thing happens and your code flips back and
>>>> forth
>>>> between buffers.
>>>>
>>>> This approach eliminates polling and reduces overhead, and will probably
>>>> be
>>>> enough to get your code functioning
>>>> smoothly in real-time. Once that is working, as an extra credit
>>>> enhancement, you can add DMA to your code, so you get
>>>> just one interrupt per buffer, instead of one per sample -- even more
>>>> efficient.
>>>>
>>>> For more info, you can search on "ping pong buffers", dual or double
>>>> buffering, swiPost, etc. Also if you get a copy
>>>> of this book:
>>>>
>>>>
>>>>
http://www.amazon.com/Digital-Signal-Processing-Applications-Topics/dp/0471690074
>>>>
>>>> it gives some audio processing examples for the DSK6713, and covers this
>>>> topic. Probably your Prof already knows
>>>> about this book and/or has a copy available.
>>>>
>>>> -Jeff
>>>>
>>>>> Here's my code:
>>>>>
>>>>> --------------
>>>>>
>>>>> float ambisonicsPanner(float position, int order) //position of each
>>>>> speaker
>>>>> {
>>>>> return(pow(0.5 + 0.5*cos(source-position), order));
>>>>>
>>>>> }
>>>>>
>>>>> short convolve(short speaker, short filter[restrict])
>>>>> {
>>>>> dly[N-1]=speaker;
>>>>>
>>>>> yn = fircasmfunc(dly,filter,N);
>>>>> return(yn>>15);
>>>>>
>>>>> }
>>>>>
>>>>> interrupt void c_int11() //ISR
>>>>> {
>>>>> sig = (short)input_sample();
>>>>>
>>>>> speaker1 = sig*ambisonicsPanner(0,order);
>>>>> speaker2 = sig*ambisonicsPanner(0.7854,order);
>>>>> speaker3 = sig*ambisonicsPanner(1.5708,order);
>>>>> speaker4 = sig*ambisonicsPanner(2.3562,order);
>>>>> /* speaker5 = sig*ambisonicsPanner(3.1416,order);
>>>>> speaker6 = sig*ambisonicsPanner(3.9270,order);
>>>>> speaker7 = sig*ambisonicsPanner(4.7124,order);
>>>>> speaker8 = sig*ambisonicsPanner(5.4978,order);
>>>>>
>>>>> spkConvL1 = convolve(speaker1,HRIR_L_1);
>>>>> spkConvL2 = convolve(speaker2,HRIR_L_2);
>>>>> spkConvL3 = convolve(speaker3,HRIR_L_3);
>>>>> spkConvL4 = convolve(speaker4,HRIR_L_4);
>>>>> spkConvL5 = convolve(speaker5,HRIR_L_5);
>>>>> spkConvL6 = convolve(speaker6,HRIR_L_6);
>>>>> spkConvL7 = convolve(speaker7,HRIR_L_7);
>>>>> spkConvL8 = convolve(speaker8,HRIR_L_8);
>>>>>
>>>>> spkConvR1 = convolve(speaker1,HRIR_R_1);
>>>>> spkConvR2 = convolve(speaker2,HRIR_R_2);
>>>>> spkConvR3 = convolve(speaker3,HRIR_R_3);
>>>>> spkConvR4 = convolve(speaker4,HRIR_R_4);
>>>>> spkConvR5 = convolve(speaker5,HRIR_R_5);
>>>>> spkConvR6 = convolve(speaker6,HRIR_R_6);
>>>>> spkConvR7 = convolve(speaker7,HRIR_R_7);
>>>>> spkConvR8 = convolve(speaker8,HRIR_R_8);
>>>>> */
>>>>> // AIC23_data.channel[LEFT] >>>>>
spkConvL1+spkConvL2+spkConvL3+spkConvL4+spkConvL5+spkConvL6+spkConvL7+spkConvL8;
>>>>> // AIC23_data.channel[RIGHT] >>>>>
spkConvR1+spkConvR2+spkConvR3+spkConvR4+spkConvR5+spkConvR6+spkConvR7+spkConvR8;
>>>>>
>>>>> buffer[i] =(sig);//store input data into buffer
>>>>> i++; //increment buffer index
>>>>> if (i==BUFFER_SIZE) i = 0; //reinit index if buffer full
>>>>>
>>>>> output_sample(sig);
>>>>> return; //return from ISR
>>>>>
>>>>> }
_____________________________________
Reply by krishnan rani●April 2, 20112011-04-02
respected sir
IN 6713 KIT tutorial programmes are running as per requirement . i
am analising programme with memories.( that is very helpful to me ,
ie, which type of running, programme memory space in every fomula( c
plus plus).
regards
RR Krishnan
On 4/2/11, Jeff Brower wrote: > Krishnan-
>
>> u are taking a 440Hz sine wave in from the board,
>> storing it in a buffer and outputting it.
>>
>> kindly help to me for the ideas of input buffer,
>> output buffer , buffer size and how to programme
>> it in c6713 trg kit
>
> 1) Please post to the group and not to me.
>
> 2) I am not processing a 440 Hz sine wave, the OP (Tom) is.
>
> 3) For programming examples on the C6713 DSK, I strongly suggest the Rulph
> Chassaing book that I mentioned below.
>
> -Jeff
>
>> On 3/30/11, Jeff Brower wrote:
>>> Tom-
>>>
>>>> Basically, I'm taking a 440Hz sine wave in from the board, storing it
in
>>>> a
>>>> buffer and outputting it. When I view the
>>>> FFT of the data stored in the buffer it shows a 440Hz sine wave as
>>>> expected. Now, for some reason, when I do some
>>>> operations my outputted signal is affected. For instance, if I call a
>>>> function a few times, some distortion is
>>>> introduced in the outputted signal. When I view the FFT of the input
>>>> signal it no longer peaks at 440Hz: the peak is
>>>> now at a higher frequency value for some reason. The more function calls
>>>> I
>>>> make, the more distorted the output signal
>>>> is and the higher the peak of the FFT is. For instance, if I uncomment
>>>> all
>>>> the code below and run it, the FFT peaks at
>>>> around 6kHz, despite the fact that I'm feeding a 440Hz signal to
the
>>>> board
>>>> and should in theory be getting a 440Hz
>>>> sine wave out of it.
>>>>
>>>> A friend of mine suggested it might be something to do with stack size,
>>>> but changing the stack and/or heap options in
>>>> the linker build options has had no effect.
>>>>
>>>> Any ideas why this is happening?
>>>
>>> It's happening because you're processing on sample-by-sample
basis,
>>> polling
>>> for each sample. That means you're
>>> wasting a lot of CPU time a) waiting for samples, and b) due to the
>>> overhead
>>> of repeating everything for each sample
>>> instead of operating on an array of samples. For example, if you're
>>> sampling rate is 8 kHz, then you have 125 usec
>>> between samples, not enough time to do BUFFER_SIZE sets of function calls
>>> and all other overhead.
>>>
>>> The solution is to change to buffer-based operation, using "double
>>> buffering": your ISR inputs the sample, adds it to
>>> a buffer, then exits -- nothing more. When the first buffer is filled,
>>> your
>>> ISR sets a flag (or does an swiPost under
>>> DSP/BIOS) and then a foreground task processes the buffer. Meanwhile the
>>> ISR keeps on going with buffer 2. When
>>> buffer 2 is full, the same thing happens and your code flips back and
>>> forth
>>> between buffers.
>>>
>>> This approach eliminates polling and reduces overhead, and will probably
>>> be
>>> enough to get your code functioning
>>> smoothly in real-time. Once that is working, as an extra credit
>>> enhancement, you can add DMA to your code, so you get
>>> just one interrupt per buffer, instead of one per sample -- even more
>>> efficient.
>>>
>>> For more info, you can search on "ping pong buffers", dual or double
>>> buffering, swiPost, etc. Also if you get a copy
>>> of this book:
>>>
>>>
>>>
http://www.amazon.com/Digital-Signal-Processing-Applications-Topics/dp/0471690074
>>>
>>> it gives some audio processing examples for the DSK6713, and covers this
>>> topic. Probably your Prof already knows
>>> about this book and/or has a copy available.
>>>
>>> -Jeff
>>>
>>>> Here's my code:
>>>>
>>>> --------------
>>>>
>>>> float ambisonicsPanner(float position, int order) //position of each
>>>> speaker
>>>> {
>>>> return(pow(0.5 + 0.5*cos(source-position), order));
>>>>
>>>> }
>>>>
>>>> short convolve(short speaker, short filter[restrict])
>>>> {
>>>> dly[N-1]=speaker;
>>>>
>>>> yn = fircasmfunc(dly,filter,N);
>>>> return(yn>>15);
>>>>
>>>> }
>>>>
>>>> interrupt void c_int11() //ISR
>>>> {
>>>> sig = (short)input_sample();
>>>>
>>>> speaker1 = sig*ambisonicsPanner(0,order);
>>>> speaker2 = sig*ambisonicsPanner(0.7854,order);
>>>> speaker3 = sig*ambisonicsPanner(1.5708,order);
>>>> speaker4 = sig*ambisonicsPanner(2.3562,order);
>>>> /* speaker5 = sig*ambisonicsPanner(3.1416,order);
>>>> speaker6 = sig*ambisonicsPanner(3.9270,order);
>>>> speaker7 = sig*ambisonicsPanner(4.7124,order);
>>>> speaker8 = sig*ambisonicsPanner(5.4978,order);
>>>>
>>>> spkConvL1 = convolve(speaker1,HRIR_L_1);
>>>> spkConvL2 = convolve(speaker2,HRIR_L_2);
>>>> spkConvL3 = convolve(speaker3,HRIR_L_3);
>>>> spkConvL4 = convolve(speaker4,HRIR_L_4);
>>>> spkConvL5 = convolve(speaker5,HRIR_L_5);
>>>> spkConvL6 = convolve(speaker6,HRIR_L_6);
>>>> spkConvL7 = convolve(speaker7,HRIR_L_7);
>>>> spkConvL8 = convolve(speaker8,HRIR_L_8);
>>>>
>>>> spkConvR1 = convolve(speaker1,HRIR_R_1);
>>>> spkConvR2 = convolve(speaker2,HRIR_R_2);
>>>> spkConvR3 = convolve(speaker3,HRIR_R_3);
>>>> spkConvR4 = convolve(speaker4,HRIR_R_4);
>>>> spkConvR5 = convolve(speaker5,HRIR_R_5);
>>>> spkConvR6 = convolve(speaker6,HRIR_R_6);
>>>> spkConvR7 = convolve(speaker7,HRIR_R_7);
>>>> spkConvR8 = convolve(speaker8,HRIR_R_8);
>>>> */
>>>> // AIC23_data.channel[LEFT] >>>>
spkConvL1+spkConvL2+spkConvL3+spkConvL4+spkConvL5+spkConvL6+spkConvL7+spkConvL8;
>>>> // AIC23_data.channel[RIGHT] >>>>
spkConvR1+spkConvR2+spkConvR3+spkConvR4+spkConvR5+spkConvR6+spkConvR7+spkConvR8;
>>>>
>>>> buffer[i] =(sig);//store input data into buffer
>>>> i++; //increment buffer index
>>>> if (i==BUFFER_SIZE) i = 0; //reinit index if buffer full
>>>>
>>>> output_sample(sig);
>>>> return; //return from ISR
>>>>
>>>> }
_____________________________________
Reply by Jeff Brower●April 1, 20112011-04-01
Krishnan-
> u are taking a 440Hz sine wave in from the board,
> storing it in a buffer and outputting it.
>
> kindly help to me for the ideas of input buffer,
> output buffer , buffer size and how to programme
> it in c6713 trg kit
1) Please post to the group and not to me.
2) I am not processing a 440 Hz sine wave, the OP (Tom) is.
3) For programming examples on the C6713 DSK, I strongly suggest the Rulph
Chassaing book that I mentioned below.
-Jeff
> On 3/30/11, Jeff Brower
wrote:
>> Tom-
>>
>>> Basically, I'm taking a 440Hz sine wave in from the board, storing it
in a
>>> buffer and outputting it. When I view the
>>> FFT of the data stored in the buffer it shows a 440Hz sine wave as
>>> expected. Now, for some reason, when I do some
>>> operations my outputted signal is affected. For instance, if I call a
>>> function a few times, some distortion is
>>> introduced in the outputted signal. When I view the FFT of the input
>>> signal it no longer peaks at 440Hz: the peak is
>>> now at a higher frequency value for some reason. The more function calls
I
>>> make, the more distorted the output signal
>>> is and the higher the peak of the FFT is. For instance, if I uncomment
all
>>> the code below and run it, the FFT peaks at
>>> around 6kHz, despite the fact that I'm feeding a 440Hz signal to the
board
>>> and should in theory be getting a 440Hz
>>> sine wave out of it.
>>>
>>> A friend of mine suggested it might be something to do with stack size,
>>> but changing the stack and/or heap options in
>>> the linker build options has had no effect.
>>>
>>> Any ideas why this is happening?
>>
>> It's happening because you're processing on sample-by-sample basis,
polling
>> for each sample. That means you're
>> wasting a lot of CPU time a) waiting for samples, and b) due to the
overhead
>> of repeating everything for each sample
>> instead of operating on an array of samples. For example, if you're
>> sampling rate is 8 kHz, then you have 125 usec
>> between samples, not enough time to do BUFFER_SIZE sets of function calls
>> and all other overhead.
>>
>> The solution is to change to buffer-based operation, using "double
>> buffering": your ISR inputs the sample, adds it to
>> a buffer, then exits -- nothing more. When the first buffer is filled,
your
>> ISR sets a flag (or does an swiPost under
>> DSP/BIOS) and then a foreground task processes the buffer. Meanwhile the
>> ISR keeps on going with buffer 2. When
>> buffer 2 is full, the same thing happens and your code flips back and
forth
>> between buffers.
>>
>> This approach eliminates polling and reduces overhead, and will probably
be
>> enough to get your code functioning
>> smoothly in real-time. Once that is working, as an extra credit
>> enhancement, you can add DMA to your code, so you get
>> just one interrupt per buffer, instead of one per sample -- even more
>> efficient.
>>
>> For more info, you can search on "ping pong buffers", dual or double
>> buffering, swiPost, etc. Also if you get a copy
>> of this book:
>>
http://www.amazon.com/Digital-Signal-Processing-Applications-Topics/dp/0471690074
>>
>> it gives some audio processing examples for the DSK6713, and covers this
>> topic. Probably your Prof already knows
>> about this book and/or has a copy available.
>>
>> -Jeff
>>
>>> Here's my code:
>>>
>>> --------------
>>>
>>> float ambisonicsPanner(float position, int order) //position of each
>>> speaker
>>> {
>>> return(pow(0.5 + 0.5*cos(source-position), order));
>>>
>>> }
>>>
>>> short convolve(short speaker, short filter[restrict])
>>> {
>>> dly[N-1]=speaker;
>>>
>>> yn = fircasmfunc(dly,filter,N);
>>> return(yn>>15);
>>>
>>> }
>>>
>>> interrupt void c_int11() //ISR
>>> {
>>> sig = (short)input_sample();
>>>
>>> speaker1 = sig*ambisonicsPanner(0,order);
>>> speaker2 = sig*ambisonicsPanner(0.7854,order);
>>> speaker3 = sig*ambisonicsPanner(1.5708,order);
>>> speaker4 = sig*ambisonicsPanner(2.3562,order);
>>> /* speaker5 = sig*ambisonicsPanner(3.1416,order);
>>> speaker6 = sig*ambisonicsPanner(3.9270,order);
>>> speaker7 = sig*ambisonicsPanner(4.7124,order);
>>> speaker8 = sig*ambisonicsPanner(5.4978,order);
>>>
>>> spkConvL1 = convolve(speaker1,HRIR_L_1);
>>> spkConvL2 = convolve(speaker2,HRIR_L_2);
>>> spkConvL3 = convolve(speaker3,HRIR_L_3);
>>> spkConvL4 = convolve(speaker4,HRIR_L_4);
>>> spkConvL5 = convolve(speaker5,HRIR_L_5);
>>> spkConvL6 = convolve(speaker6,HRIR_L_6);
>>> spkConvL7 = convolve(speaker7,HRIR_L_7);
>>> spkConvL8 = convolve(speaker8,HRIR_L_8);
>>>
>>> spkConvR1 = convolve(speaker1,HRIR_R_1);
>>> spkConvR2 = convolve(speaker2,HRIR_R_2);
>>> spkConvR3 = convolve(speaker3,HRIR_R_3);
>>> spkConvR4 = convolve(speaker4,HRIR_R_4);
>>> spkConvR5 = convolve(speaker5,HRIR_R_5);
>>> spkConvR6 = convolve(speaker6,HRIR_R_6);
>>> spkConvR7 = convolve(speaker7,HRIR_R_7);
>>> spkConvR8 = convolve(speaker8,HRIR_R_8);
>>> */
>>> // AIC23_data.channel[LEFT] >>>
spkConvL1+spkConvL2+spkConvL3+spkConvL4+spkConvL5+spkConvL6+spkConvL7+spkConvL8;
>>> // AIC23_data.channel[RIGHT] >>>
spkConvR1+spkConvR2+spkConvR3+spkConvR4+spkConvR5+spkConvR6+spkConvR7+spkConvR8;
>>>
>>> buffer[i] =(sig);//store input data into buffer
>>> i++; //increment buffer index
>>> if (i==BUFFER_SIZE) i = 0; //reinit index if buffer full
>>>
>>> output_sample(sig);
>>> return; //return from ISR
>>>
>>> }
_____________________________________
Reply by Jeff Brower●March 30, 20112011-03-30
Tom-
> Basically, I'm taking a 440Hz sine wave in from
the board, storing it in a buffer and outputting it. When I view the
> FFT of the data stored in the buffer it shows a 440Hz sine wave as expected.
Now, for some reason, when I do some
> operations my outputted signal is affected. For instance, if I call a function
a few times, some distortion is
> introduced in the outputted signal. When I view the FFT of the input signal it
no longer peaks at 440Hz: the peak is
> now at a higher frequency value for some reason. The more function calls I
make, the more distorted the output signal
> is and the higher the peak of the FFT is. For instance, if I uncomment all the
code below and run it, the FFT peaks at
> around 6kHz, despite the fact that I'm feeding a 440Hz signal to the
board and should in theory be getting a 440Hz
> sine wave out of it.
>
> A friend of mine suggested it might be something to do with stack size, but
changing the stack and/or heap options in
> the linker build options has had no effect.
>
> Any ideas why this is happening?
It's happening because you're processing on sample-by-sample basis,
polling for each sample. That means you're
wasting a lot of CPU time a) waiting for samples, and b) due to the overhead of
repeating everything for each sample
instead of operating on an array of samples. For example, if you're
sampling rate is 8 kHz, then you have 125 usec
between samples, not enough time to do BUFFER_SIZE sets of function calls and
all other overhead.
The solution is to change to buffer-based operation, using "double buffering":
your ISR inputs the sample, adds it to
a buffer, then exits -- nothing more. When the first buffer is filled, your ISR
sets a flag (or does an swiPost under
DSP/BIOS) and then a foreground task processes the buffer. Meanwhile the ISR
keeps on going with buffer 2. When
buffer 2 is full, the same thing happens and your code flips back and forth
between buffers.
This approach eliminates polling and reduces overhead, and will probably be
enough to get your code functioning
smoothly in real-time. Once that is working, as an extra credit enhancement,
you can add DMA to your code, so you get
just one interrupt per buffer, instead of one per sample -- even more
efficient.
For more info, you can search on "ping pong buffers", dual or double buffering,
swiPost, etc. Also if you get a copy
of this book:
it gives some audio processing examples for the DSK6713, and covers this topic.
Probably your Prof already knows
about this book and/or has a copy available.
Apologies if I'm posting this twice but I'm not sure if it went
through the first time.
Basically, I'm taking a 440Hz sine wave in from the board, storing it in a
buffer and outputting it. When I view the FFT of the data stored in the buffer
it shows a 440Hz sine wave as expected. Now, for some reason, when I do some
operations my outputted signal is affected. For instance, if I call a function a
few times, some distortion is introduced in the outputted signal. When I view
the FFT of the input signal it no longer peaks at 440Hz: the peak is now at a
higher frequency value for some reason. The more function calls I make, the more
distorted the output signal is and the higher the peak of the FFT is. For
instance, if I uncomment all the code below and run it, the FFT peaks at around
6kHz, despite the fact that I'm feeding a 440Hz signal to the board and
should in theory be getting a 440Hz sine wave out of it.
A friend of mine suggested it might be something to do with stack size, but
changing the stack and/or heap options in the linker build options has had no
effect.
Any ideas why this is happening?
Here's my code:
--------------
float ambisonicsPanner(float position, int order) //position of each speaker
{
return(pow(0.5 + 0.5*cos(source-position), order));
}
short convolve(short speaker, short filter[restrict])
{
dly[N-1]=speaker;
yn = fircasmfunc(dly,filter,N);
return(yn>>15);
}
interrupt void c_int11() //ISR
{
sig = (short)input_sample();