robert bristow-johnson <rbj@audioimagination.com> wrote:

(snip, someone wrote)
>>>> if you use a regular old complex-to-complex FFT, and your
>>>> fast-convolution is convolving a real signal with a real impulse
>>>> response, then you can save half of the computation by processing two
>>>> frames of real data as one frame of complex data.  all you have to do is
>>>> put one real frame in the real part and the following real frame into
>>>> the imaginary part, FFT, multiply in frequency domain, iFFT, separate
>>>> the real and imag parts back into two real frames and do whatever you do
>>>> with overlap-add or overlap-save.  it's getting two for the price of one.

(snip, then I wrote)
>> Seems to me that it should work,

> i posted 9 days ago the simple explanation why it works.  all you need 
> is linearity and the knowledge that you cannot get imaginary values from 
> a real convolution.
 
>> but you should be a little careful, especially in floating point.
 
> i think you can get trouble with fixed point also.  after the FFT the 
> two signals as well the samples within, get all scrambled up anyway. 
> it's hard to understand how the numerical issues regarding finite word 
> width and quantization will affect this scrambling and descrambling of 
> the data.

I suppose, but then you should always be careful with fixed point FFT.
Best to do it with wider intermediates, in which case there could be
some rounding errors in the low bits, but not so much.

If instead (or in addition) you shift out low bits between some stages,
then you have pretty much the same problems as floating point.

-- glen

On 11/30/12 5:06 PM, glen herrmannsfeldt wrote:
> dszabo<62466@dsprelated>  wrote:
>>> if you use a regular old complex-to-complex FFT, and your
>>> fast-convolution is convolving a real signal with a real impulse
>>> response, then you can save half of the computation by processing two
>>> frames of real data as one frame of complex data.  all you have to do is
>>> put one real frame in the real part and the following real frame into
>>> the imaginary part, FFT, multiply in frequency domain, iFFT, separate
>>> the real and imag parts back into two real frames and do whatever you do
>>> with overlap-add or overlap-save.  it's getting two for the price of one.
>
>> Whhhaaat.  Thats genius.  I'll definitely have to keep that in mind
>> in the future.
>
> Seems to me that it should work,

i posted 9 days ago the simple explanation why it works.  all you need 
is linearity and the knowledge that you cannot get imaginary values from 
a real convolution.

> but you should be a little careful, especially in floating point.

i think you can get trouble with fixed point also.  after the FFT the 
two signals as well the samples within, get all scrambled up anyway. 
it's hard to understand how the numerical issues regarding finite word 
width and quantization will affect this scrambling and descrambling of 
the data.


-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."

dszabo <62466@dsprelated> wrote:
>>if you use a regular old complex-to-complex FFT, and your 
>>fast-convolution is convolving a real signal with a real impulse 
>>response, then you can save half of the computation by processing two 
>>frames of real data as one frame of complex data.  all you have to do is 
>>put one real frame in the real part and the following real frame into 
>>the complex part, FFT, multiply in frequency domain, iFFT, separate the 
>>real and imag parts back into two real frames and do whatever you do 
>>with overlap-add or overlap-save.  it's getting two for the price of one.
 
> Whhhaaat.  Thats genius.  I'll definately have to keep that in mind 
> in the future.

Seems to me that it should work, but you should be a litle careful,
especially in floating point. 

As some of the intermediate values will be sums or differences of
input values, many bits could be lost and never recovered if the
magnitudes are very different.

-- glen

>if you use a regular old complex-to-complex FFT, and your 
>fast-convolution is convolving a real signal with a real impulse 
>response, then you can save half of the computation by processing two 
>frames of real data as one frame of complex data.  all you have to do is 
>put one real frame in the real part and the following real frame into 
>the complex part, FFT, multiply in frequency domain, iFFT, separate the 
>real and imag parts back into two real frames and do whatever you do 
>with overlap-add or overlap-save.  it's getting two for the price of one.


Whhhaaat.  Thats genius.  I'll definately have to keep that in mind in the
future.

Cheers,
-Dan

On Sunday, November 25, 2012 4:44:28 AM UTC-8, mnentwig wrote:
> ...
> 
> It's interesting that my 70%-savings prediction gets so much attention. You
> are of course welcome to present a "better" number.

Such a blatant error deserves a response. A better starting point for the multistage FRM approach I suggested would be Saramaki's (your ref[4]) 7% loading example which is a 93% savings. Interested readers can find the multistage example starting on page 9 of that paper.

Dale B. Dalrymple

Hello,

>> It is not a special case. It is identical in function. 
I'd think of a single moving average response as a special case of a series
of convolved moving average responses.

The "add-n-samples" variant seems rather straightforward, which is often a
good thing.

>> the 70% number is not so much 'simple and stupid' as it is irrelevant
for comparison.

I'm sorry. but you appear to be arguing with statements that you have
constructed yourself. 

It's interesting that my 70%-savings prediction gets so much attention. You
are of course welcome to present a "better" number. 

On Saturday, November 24, 2012 10:50:19 AM UTC-8, mnentwig wrote:
> >> It's nice to find a place to hawk the results of your work, but I think
> the comparison of two narrowband implementations would be less of a grapes
> to grapefruit comparison.
> 
> Hello,
>
> please allow me to summarize my earlier posts in a few, simple words
> - From a frequency masking filter I'd expect 70 % savings over plain ol'
> FIR
> 

Since you haven't gone to any further architectural detail than the 0.3*Fs lowpass filter duplicating Lim (your ref 1), and since Mann (your ref 3) shows higher efficiencies at higher stretching ratios and Saramaki (your ref 4) describes improving efficiencies in multistage implementations (both of which may be appropriate for your example of tracking a 50Hz line at 192kHz Fs) it seems that, with regard to the narrowband application, the 70% number is not so much 'simple and stupid' as it is irrelevant for comparison.

Dale B. Dalrymple

robert bristow-johnson <rbj@audioimagination.com> writes:

> On 11/24/12 4:34 PM, Randy Yates wrote:
>> "mnentwig"<24789@dsprelated>  writes:
>>
>>>> They are the same thing, apart from possibly a scale factor. That is, a
>>>> CIC filter is identical to a moving average filter.
>>> it's a special case, yes, but an intuitive one.
>>
>> It is not a special case. It is identical in function. The two
>> differ only in realization.
>
> i thought they differed only in name.
>
> or are we talking about the non-recursive vs. recursive realizations?

Yes. At least that's what I was talking about. 
-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com

On 11/24/12 4:34 PM, Randy Yates wrote:
> "mnentwig"<24789@dsprelated>  writes:
>
>>> They are the same thing, apart from possibly a scale factor. That is, a
>>> CIC filter is identical to a moving average filter.
>> it's a special case, yes, but an intuitive one.
>
> It is not a special case. It is identical in function. The two
> differ only in realization.

i thought they differed only in name.

or are we talking about the non-recursive vs. recursive realizations?

-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."

"mnentwig" <24789@dsprelated> writes:

>>They are the same thing, apart from possibly a scale factor. That is, a
>>CIC filter is identical to a moving average filter.
> it's a special case, yes, but an intuitive one.

It is not a special case. It is identical in function. The two
differ only in realization. 
-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com