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

[Tom Rondeau]

On Tue, Oct 9, 2012 at 11:14 AM, Maicon Kist <address@hidden> wrote:
> 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

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


> 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
>
>