Restoring signal after FFT-IFFT

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 correctly? I think
that maybe is something with the sample frequency.

Thanks.

abc

On Mon, Oct 8, 2012 at 8:24 AM, Maicon K. [email protected]
wrote:

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

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:14 AM, Maicon K. remov[email protected]
wrote:

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

Ok, great. We don’t do the FFT scaling inside the block on purpose,
though. It’s not always the right thing to do, and so we’d be adding
on more multiplies (or divides, if you like) regardless of what you
want out. So yes, we leave it to the users to scale according to their
needs.

My speakers were able to still play the signal, even with the scaling
and therefore the clipping. Scaling it, though, made it sound nicer.

You still want to remove that throttle though. It’s only hurting the
flow of data in your system.

Tom

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs