help-octave
[Top][All Lists]

## Re: Problem using the hanning function in embedded mode

 From: Sergei Steshenko Subject: Re: Problem using the hanning function in embedded mode Date: Mon, 24 Dec 2012 07:31:55 -0800 (PST)

```

----- Original Message -----
> Cc:
> Sent: Monday, December 24, 2012 4:32 PM
> Subject: Re: Problem using the hanning function in embedded mode
>
> You probably noticed these already but just in case...
>
> If you wish to 'presrve' the true rms of any signal, be sure to multiply
> the hanning function by 2, else you will apparently attenuate the signal and
> lower the energy in your packet. For hamming, multiply by 2/1.08
>
> For any real signal, like an audio signal, the FFT yields a 'duplicated'
> spectrum. Usually the lower half the spectrum is of any real interest. To
> then
> preserve true rms, multiply the FFT with sqrt(2)/N, where N is the number of
> terms in your FFT. Then, the values that you retrieve from the lower half
> spectrum are true rms values.
>
> You can leave out all these coefficients and obtain answers in
> 'relative' terms. But getting results in true rms has the advantage of
> enabling you to compare spectrums derived from different packet sizes
> [equivalent to changing the BW in a spectrum analyzer]; compare calculations
> to
> actual measurements; and relate to noise in the system, etc.
>
> Also, hamming is awful for 'out of sync' signals and hanning is a bit
> better. Yet there is another function used by the ADC/DAC industry which is a
> bit more complicated. Find TI's App Notes relating to their 24 bit audio
> ADC's especially the ADS1282. They use a different window function that
> provides better separation between signals [to make their products look
> better]
> when the signals are not sync'ed to the ADC process for use in audio
> systems.
>
> If you're making some type of presentation of results you may wish to use
> the same type window function to 'lower' the energy in the spectrum
> between signals. Make the display 'cleaner'.
>

Even though I myself use FFT to process audio in real time, I do not understand
how your post is related to the OP's problem.

It's common knowledge that for real time signals _overlapping_ windows (to be
more exact, overlapping buffers multiplied by the chosen window) are used, and
for such applications Hanning window is the most widely and correctly used
no-brainer.

But, again, I think the OP's problem is (in)validity of the values he obtains
from an Octave function, and, as I wrote before, my first guess is that it
might be related to thread safety and/or problems in IPC implementation, the
processes/threads being the OP's GUI and Octave.

Regards,
Sergei.

```