discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Problems running example audio_fft.py


From: Jonathan Jacky
Subject: Re: [Discuss-gnuradio] Problems running example audio_fft.py
Date: Tue, 24 Oct 2006 08:48:27 -0700 (PDT)


On Mon, 23 Oct 2006, Dave hartzell wrote:

OK, that is interesting....are these things (G4s) really that slow?

Yes.  It seems that wxPython is the rate-limiting step.  A GNU Radio
flowgraph can process samples much much faster than wxPython can display them, at least on a G4. I've used Linux also and it seems that wxPython is appreciably slower, relative to the flow graph, on OS X compared to Linux.

I know how to limit FFT CPU utilization via the window sizes, but is
there a way to limit the WxPython window updates to something lower?

Yes.  In scope_sink_f and _c there is a parameter frame_decim, when
frame_decim = 2 scope_sink only tries to display every other buffer of data that comes from the flow graph, etc. Start with frame_decim at 20 or 30, then reduce it until you get a reasonable refresh rate. When you run scopesink from the command line, the first command line argument (with no option flag in front of it) is frame_decim. This makes it easy to experiment to find a reasonable value for your system. For more details see

 http://staff.washington.edu/~jon/gr-osx/scopesink.html

In fft_sink there is a parameter fft_rate that has a similar effect.

Jon Jacky





reply via email to

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