Hi all,
I recently experimented with the PEP5416 module, and found the DSP chip to be
too slow in processing the code to meet the audio real-time deadline. The idea
of my project is to take an audio input via the microphone port of the device
and distort the signal to generate a new audio output through the headphones.
I was wondering if anyone knew of another portable module that can be used, in
which the DSP chip can run at a higher clock speed. According to code composer
v3.1, the code I have (all fixed-point) takes roughly 16,000 clock cycles to
run. The old module required everything to be done in 13,000 clock cycles (156
MHz clock / 12 kHz AIC23 audio sampling rate).
The only portable platform I knew of was the PEP5416. Anyone know of another?
Thanks.
Need better DSP chip
Started by ●September 25, 2008
Reply by ●September 26, 20082008-09-26
> I recently experimented with the PEP5416 module, and
found the DSP chip
> to be too slow in processing the code to meet the audio real-time deadline.
> The idea of my project is to take an audio input via the microphone port
> of the device and distort the signal to generate a new audio output
> through the headphones.
>
> I was wondering if anyone knew of another portable module that can be
> used, in which the DSP chip can run at a higher clock speed. According
> to code composer v3.1, the code I have (all fixed-point) takes roughly
> 16,000 clock cycles to run. The old module required everything to be
> done in 13,000 clock cycles (156 MHz clock / 12 kHz AIC23 audio
> sampling rate).
>
> The only portable platform I knew of was the PEP5416. Anyone know of
> another? Thanks.
Your calculations seem to be based on code that's processing on per-sample basis.
Normally that's an inefficient method with high overhead. Typically it's faster to
collect a buffer of samples and use loops, which can be optimized, to process the
buffers. Also buffer based processing allows serial-port + DMA interrupt processing.
I guess you could say I suspect your algorithm and software design is a source of
slowness, rather than the DSP chip.
-Jeff
> to be too slow in processing the code to meet the audio real-time deadline.
> The idea of my project is to take an audio input via the microphone port
> of the device and distort the signal to generate a new audio output
> through the headphones.
>
> I was wondering if anyone knew of another portable module that can be
> used, in which the DSP chip can run at a higher clock speed. According
> to code composer v3.1, the code I have (all fixed-point) takes roughly
> 16,000 clock cycles to run. The old module required everything to be
> done in 13,000 clock cycles (156 MHz clock / 12 kHz AIC23 audio
> sampling rate).
>
> The only portable platform I knew of was the PEP5416. Anyone know of
> another? Thanks.
Your calculations seem to be based on code that's processing on per-sample basis.
Normally that's an inefficient method with high overhead. Typically it's faster to
collect a buffer of samples and use loops, which can be optimized, to process the
buffers. Also buffer based processing allows serial-port + DMA interrupt processing.
I guess you could say I suspect your algorithm and software design is a source of
slowness, rather than the DSP chip.
-Jeff
Reply by ●September 30, 20082008-09-30
Yes, I thought this might be an issue. My calculations seem to indicate that
something other than simple adds and multiplies are consuming a considerable
number of clock cycles.
I will of course look into implementing DMA and McBSP. Out of curiosity, without these tools, processing by buffers would take longer, correct?
Hi all,
>
>I recently experimented with the PEP5416 module, and found the DSP chip to be too slow in processing the code to meet the audio real-time deadline. The idea of my project is to take an audio input via the microphone port of the device and distort the signal to generate a new audio output through the headphones.
>
>I was wondering if anyone knew of another portable module that can be used, in which the DSP chip can run at a higher clock speed. According to code composer v3.1, the code I have (all fixed-point) takes roughly 16,000 clock cycles to run. The old module required everything to be done in 13,000 clock cycles (156 MHz clock / 12 kHz AIC23 audio sampling rate).
>
>The only portable platform I knew of was the PEP5416. Anyone know of another? Thanks.
>
I will of course look into implementing DMA and McBSP. Out of curiosity, without these tools, processing by buffers would take longer, correct?
Hi all,
>
>I recently experimented with the PEP5416 module, and found the DSP chip to be too slow in processing the code to meet the audio real-time deadline. The idea of my project is to take an audio input via the microphone port of the device and distort the signal to generate a new audio output through the headphones.
>
>I was wondering if anyone knew of another portable module that can be used, in which the DSP chip can run at a higher clock speed. According to code composer v3.1, the code I have (all fixed-point) takes roughly 16,000 clock cycles to run. The old module required everything to be done in 13,000 clock cycles (156 MHz clock / 12 kHz AIC23 audio sampling rate).
>
>The only portable platform I knew of was the PEP5416. Anyone know of another? Thanks.
>
Reply by ●September 30, 20082008-09-30
> Yes, I thought this might be an issue. My
calculations seem to indicate
> that something other than simple adds and multiplies are consuming a
> considerable number of clock cycles.
>
> I will of course look into implementing DMA and McBSP. Out of curiosity,
> without these tools, processing by buffers would take longer, correct?
>
> Hi all,
> >
> >I recently experimented with the PEP5416 module, and found the DSP chip
> to be too slow in processing the code to meet the audio real-time
> deadline. The idea of my project is to take an audio input via the
> microphone port of the device and distort the signal to generate a new
> audio output through the headphones.
You are cutting text from the replies that you get. Can you post again and include
what reply you are answering?
Otherwise I can't tell what you are talking about, and there is no way to help you.
-Jeff
> that something other than simple adds and multiplies are consuming a
> considerable number of clock cycles.
>
> I will of course look into implementing DMA and McBSP. Out of curiosity,
> without these tools, processing by buffers would take longer, correct?
>
> Hi all,
> >
> >I recently experimented with the PEP5416 module, and found the DSP chip
> to be too slow in processing the code to meet the audio real-time
> deadline. The idea of my project is to take an audio input via the
> microphone port of the device and distort the signal to generate a new
> audio output through the headphones.
You are cutting text from the replies that you get. Can you post again and include
what reply you are answering?
Otherwise I can't tell what you are talking about, and there is no way to help you.
-Jeff
Reply by ●September 30, 20082008-09-30
>> I recently experimented with the PEP5416 module, and
found the DSP chip
>> to be too slow in processing the code to meet the audio real-time deadline.
>> The idea of my project is to take an audio input via the microphone port
>> of the device and distort the signal to generate a new audio output
>> through the headphones.
>>
>> I was wondering if anyone knew of another portable module that can be
>> used, in which the DSP chip can run at a higher clock speed. According
>> to code composer v3.1, the code I have (all fixed-point) takes roughly
>> 16,000 clock cycles to run. The old module required everything to be
>> done in 13,000 clock cycles (156 MHz clock / 12 kHz AIC23 audio
>> sampling rate).
>>
>> The only portable platform I knew of was the PEP5416. Anyone know of
>> another? Thanks.
>Your calculations seem to be based on code that's processing on >per-sample basis.
>Normally that's an inefficient method with high overhead. Typically it's >faster to
>collect a buffer of samples and use loops, which can be optimized, to >process the
>buffers. Also buffer based processing allows serial-port + DMA interrupt >processing.
>I guess you could say I suspect your algorithm and software design is a >source of
>slowness, rather than the DSP chip.
-Jeff
Alright Jeff,
I am actually not intentionally cutting the text. When I post a followup, it only includes the text from the first post, despite the fact that I'm posting a followup to your comment. Not sure what's going on there.
My last post read that I buy what you're saying about the overhead resulting from single sample processing. The program I am running was written to filter buffers, so that isn't a problem. I also found from the clock profiler that many more cycles were being consumed than what simple adds and multiplies should take up.
If it becomes necessary to optimize the speed of these operations further, I will have to resort to using McBSP and DMA.
In any case, I won't yet resort to buying a new processor. I'll spend more time working with my current equipment. Thanks.
>> to be too slow in processing the code to meet the audio real-time deadline.
>> The idea of my project is to take an audio input via the microphone port
>> of the device and distort the signal to generate a new audio output
>> through the headphones.
>>
>> I was wondering if anyone knew of another portable module that can be
>> used, in which the DSP chip can run at a higher clock speed. According
>> to code composer v3.1, the code I have (all fixed-point) takes roughly
>> 16,000 clock cycles to run. The old module required everything to be
>> done in 13,000 clock cycles (156 MHz clock / 12 kHz AIC23 audio
>> sampling rate).
>>
>> The only portable platform I knew of was the PEP5416. Anyone know of
>> another? Thanks.
>Your calculations seem to be based on code that's processing on >per-sample basis.
>Normally that's an inefficient method with high overhead. Typically it's >faster to
>collect a buffer of samples and use loops, which can be optimized, to >process the
>buffers. Also buffer based processing allows serial-port + DMA interrupt >processing.
>I guess you could say I suspect your algorithm and software design is a >source of
>slowness, rather than the DSP chip.
-Jeff
Alright Jeff,
I am actually not intentionally cutting the text. When I post a followup, it only includes the text from the first post, despite the fact that I'm posting a followup to your comment. Not sure what's going on there.
My last post read that I buy what you're saying about the overhead resulting from single sample processing. The program I am running was written to filter buffers, so that isn't a problem. I also found from the clock profiler that many more cycles were being consumed than what simple adds and multiplies should take up.
If it becomes necessary to optimize the speed of these operations further, I will have to resort to using McBSP and DMA.
In any case, I won't yet resort to buying a new processor. I'll spend more time working with my current equipment. Thanks.
Reply by ●October 1, 20082008-10-01
Dr.
> >> I recently experimented with the PEP5416 module, and found the DSP chip
> >> to be too slow in processing the code to meet the audio real-time deadline.
> >> The idea of my project is to take an audio input via the microphone port
> >> of the device and distort the signal to generate a new audio output
> >> through the headphones.
> >>
> >> I was wondering if anyone knew of another portable module that can be
> >> used, in which the DSP chip can run at a higher clock speed. According
> >> to code composer v3.1, the code I have (all fixed-point) takes roughly
> >> 16,000 clock cycles to run. The old module required everything to be
> >> done in 13,000 clock cycles (156 MHz clock / 12 kHz AIC23 audio
> >> sampling rate).
> >>
> >> The only portable platform I knew of was the PEP5416. Anyone know of
> >> another? Thanks.
>
> >Your calculations seem to be based on code that's processing on per-sample basis.
> >Normally that's an inefficient method with high overhead. Typically it's faster to
> >collect a buffer of samples and use loops, which can be optimized, to process the
> >buffers. Also buffer based processing allows serial-port + DMA interrupt processing.
>
> >I guess you could say I suspect your algorithm and software design is a source of
> >slowness, rather than the DSP chip.
>
> -Jeff
>
> Alright Jeff,
>
> I am actually not intentionally cutting the text. When I post a followup,
> it only includes the text from the first post, despite the fact that I'm
> posting a followup to your comment. Not sure what's going on there.
I don't know either, but you're the only one I see doing this (at least recently), so
it would be a good idea to figure it out.
> My last post read that I buy what you're saying about the overhead
> resulting from single sample processing. The program I am running was
> written to filter buffers, so that isn't a problem. I also found from
> the clock profiler that many more cycles were being consumed than what
> simple adds and multiplies should take up.
Ok, that sounds like the ISR is just filling ping-pong buffers and not doing much
else, so you're in good position to optimize.
> If it becomes necessary to optimize the speed of these operations
> further, I will have to resort to using McBSP and DMA.
Yes that is a good idea, it will make a significant improvement.
> In any case, I won't yet resort to buying a new processor. I'll
> spend more time working with my current equipment. Thanks.
Sure.
-Jeff
> >> I recently experimented with the PEP5416 module, and found the DSP chip
> >> to be too slow in processing the code to meet the audio real-time deadline.
> >> The idea of my project is to take an audio input via the microphone port
> >> of the device and distort the signal to generate a new audio output
> >> through the headphones.
> >>
> >> I was wondering if anyone knew of another portable module that can be
> >> used, in which the DSP chip can run at a higher clock speed. According
> >> to code composer v3.1, the code I have (all fixed-point) takes roughly
> >> 16,000 clock cycles to run. The old module required everything to be
> >> done in 13,000 clock cycles (156 MHz clock / 12 kHz AIC23 audio
> >> sampling rate).
> >>
> >> The only portable platform I knew of was the PEP5416. Anyone know of
> >> another? Thanks.
>
> >Your calculations seem to be based on code that's processing on per-sample basis.
> >Normally that's an inefficient method with high overhead. Typically it's faster to
> >collect a buffer of samples and use loops, which can be optimized, to process the
> >buffers. Also buffer based processing allows serial-port + DMA interrupt processing.
>
> >I guess you could say I suspect your algorithm and software design is a source of
> >slowness, rather than the DSP chip.
>
> -Jeff
>
> Alright Jeff,
>
> I am actually not intentionally cutting the text. When I post a followup,
> it only includes the text from the first post, despite the fact that I'm
> posting a followup to your comment. Not sure what's going on there.
I don't know either, but you're the only one I see doing this (at least recently), so
it would be a good idea to figure it out.
> My last post read that I buy what you're saying about the overhead
> resulting from single sample processing. The program I am running was
> written to filter buffers, so that isn't a problem. I also found from
> the clock profiler that many more cycles were being consumed than what
> simple adds and multiplies should take up.
Ok, that sounds like the ISR is just filling ping-pong buffers and not doing much
else, so you're in good position to optimize.
> If it becomes necessary to optimize the speed of these operations
> further, I will have to resort to using McBSP and DMA.
Yes that is a good idea, it will make a significant improvement.
> In any case, I won't yet resort to buying a new processor. I'll
> spend more time working with my current equipment. Thanks.
Sure.
-Jeff
