Forum: GNU Radio Restoring signal after FFT-IFFT

Posted by Maicon Kist (Guest)
on 2012-10-08 14:34
Attachment: ifft2.png (108 KB)
Attachment: ifft2.grc (18,2 KB)
(Received via mailing list)
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
Posted by Tom Rondeau (Guest)
on 2012-10-09 16:19
(Received via mailing list)
On Mon, Oct 8, 2012 at 8:24 AM, Maicon Kist <maiconkist@gmail.com> 
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
Posted by Maicon Kist (Guest)
on 2012-10-09 17:15
(Received via mailing list)
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
Posted by Tom Rondeau (Guest)
on 2012-10-11 00:52
(Received via mailing list)
On Tue, Oct 9, 2012 at 11:14 AM, Maicon Kist <maiconkist@gmail.com> 
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
Please log in before posting. Registration is free and takes only a minute.
Existing account (Switch to SSL-encrypted connection)
NEW: Do you have a Google/GoogleMail or Yahoo account? No registration required!
Log in with Google account | Log in with Yahoo account
No account? Register here.