Technical discussions about the TI C6000 DSPs (including the c62x, c64x and c67x DSPs).
Hello, I=B4m doing a timedomain convolution using the DSP_fir_r8 function from DSP_LIB. I=B4m using different blocklegth NR and filterlength NH. For errorchecking I use coefficients where h0 =3D 32767 and the rest zeros, so I=B4m expectiing to see the delayed input signal on the output. Now I noticed a strange behavior of the function: if I increase the filterlength to NH =3D 4096 and the blocksize to NR >=3D 32, I see a short distortion every block, watching the output signal with a scope. It seems that always the last sample in a block is wrong. With NR =3D 24 there are no problems. There are also other configuration with the same result, like NR>=3D8 with NH =3D 16384, and NR>=3D92 with NH =3D 1024. Has anybody noticed these things before and is there a solution for this? Im using the DSK6416 with CCS 3.1. Bye, jonas Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Tr= anscoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm64= 67 =20
Jonas- > I´m doing a timedomain convolution using the DSP_fir_r8 function from > DSP_LIB. I´m using different blocklegth NR and filterlength NH. > For errorchecking I use coefficients where h0 = 32767 and the rest > zeros, so I´m expectiing to see the delayed input signal on the output. > > Now I noticed a strange behavior of the function: if I increase the > filterlength to NH = 4096 and the blocksize to NR >= 32, I see a short > distortion every block, watching the output signal with a scope. > It seems that always the last sample in a block is wrong. > With NR = 24 there are no problems. > There are also other configuration with the same result, like NR>=8 > with NH = 16384, and NR>=92 with NH = 1024. > > Has anybody noticed these things before and is there a solution for this? > > Im using the DSK6416 with CCS 3.1. First I would ask how you can have block length less than filter length? Does DSP_fir_r8() documentation explicitly say it supports this? If that's really true, then the DSP_fir_r8() function would be fairly complex in order to keep track of where it is in the filter tap sequence in between calls to it. The typical FIR filter function is not this complex and assumes the entire filter is applied during each call. This requires only keeping track of enough of NR length data to account for coefficient overlap between blocks -- which implies that NR > NH. Second assuming you are doing everything correctly and still see a "distortion" every block, a couple of guesses might be: -you are somehow not feeding the next NR block with data exactly one sample after the previous block -static array space used by DSP_fir_r8() to maintain "memory" of the previous block is somehow not static or being overwritten or corrupted in between calls to DSP_fir_r8() -Jeff Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467
Jonas- >> > I´m doing a timedomain convolution using the DSP_fir_r8 function from >> > DSP_LIB. I´m using different blocklegth NR and filterlength NH. >> > For errorchecking I use coefficients where h0 = 32767 and the rest >> > zeros, so I´m expectiing to see the delayed input signal on the > output. >> > >> > Now I noticed a strange behavior of the function: if I increase the >> > filterlength to NH = 4096 and the blocksize to NR >= 32, I see a short >> > distortion every block, watching the output signal with a scope. >> > It seems that always the last sample in a block is wrong. >> > With NR = 24 there are no problems. >> > There are also other configuration with the same result, like NR>=8 >> > with NH = 16384, and NR>=92 with NH = 1024. >> > >> > Has anybody noticed these things before and is there a solution > for this? >> > >> > Im using the DSK6416 with CCS 3.1. >> >> First I would ask how you can have block length less than filter > length? Does DSP_fir_r8() documentation explicitly >> say it supports this? If that's really true, then the DSP_fir_r8() > function would be fairly complex in order to keep >> track of where it is in the filter tap sequence in between calls to > it. The typical FIR filter function is not this >> complex and assumes the entire filter is applied during each call. > This requires only keeping track of enough of NR >> length data to account for coefficient overlap between blocks -- > which implies that NR > NH. >> >> Second assuming you are doing everything correctly and still see a > "distortion" every block, a couple of guesses might >> be: >> >> -you are somehow not feeding the next NR >> block with data exactly one sample after >> the previous block >> >> -static array space used by DSP_fir_r8() to >> maintain "memory" of the previous block is >> somehow not static or being overwritten or >> corrupted in between calls to DSP_fir_r8() >> >> -Jeff >> Ok, thank you. > Yes, it was my fault, I used the wrong buffers, sorry. I'm glad to hear you got it working. It would be good if you give the specific problem and fix that you found for other group members implementing FIR filters. -Jeff Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467