discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Restoring signal after FFT-IFFT


From: Maicon Kist
Subject: Re: [Discuss-gnuradio] Restoring signal after FFT-IFFT
Date: Tue, 9 Oct 2012 12:14:03 -0300

Hi Tom, 

thanks for you feedback.

I didn't try your suggestion yet. But my professor help me to solve this in a different way: we put a divisor after the FFT (the divisor value is the same as the FFT size). Its related to the equations associated with the FFT and IFFT: in a real system the FFT (or the IFFT) divides the outputs by N (the FFT size), this division is required in order to the other transformation, in this case the IFFT, recover the signal with the same dB values.

I think that the GNu Radios developers  have not placed this division inside the FFT block because if you two of them, you will have the signal divided 2 times, and not one.


abc


On Tue, Oct 9, 2012 at 11:17 AM, Tom Rondeau <address@hidden> wrote:
On Mon, Oct 8, 2012 at 8:24 AM, Maicon Kist <address@hidden> wrote:
> Hi list,
>
> I'm trying to recover a sound after passing it by a FFT and a IFFT. The
> problem is that after the IFFT (to recover the original sound) and sending
> it to the audio sink, I hear only wheezings.
>
> Attached to this email is the system that I created using the GNU Radio
> Companion tool.
>
> Do your guys have any suggestion to recover the sound ciorrectly? I think
> that maybe is something with the sample frequency.
>
> Thanks.
>
> abc

There are two things to watch out for here.

First, you made the classic mistake of using a throttle and a hardware
block in the same flowgraph. The audio sink you have is the block that
will do your sample rate control. You do NOT need a throttle block.
It's not even that the throttle is unnecessary, but it will screw up
your program. You have two clocks now competing for flow control. The
throttle block is just a very poor approximation of a flow control
based on the CPU and timers.

Second, you might want to specify the device in the audio sink. By
default, it's likely that you are using the ASLA sink, which provides
no sample rate conversion. At 48 kHz, you might be ok. If you use
pulseaudio (in Ubuntu, this is available by default now), for the
'Device name' parameter in the audio sink's options, you can use
'pulse.'

Recreating your graph on my machine with these two changes worked fine.

Tom


reply via email to

[Prev in Thread] Current Thread [Next in Thread]