[Top][All Lists]

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

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

From: Eric Blossom
Subject: Re: [Discuss-gnuradio] Problems running example audio_fft.py
Date: Tue, 24 Oct 2006 13:12:03 -0700
User-agent: Mutt/1.5.9i

On Tue, Oct 24, 2006 at 08:48:27AM -0700, Jonathan Jacky wrote:
> 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

I suspect that most of our wxPython performance problems could be
fixed if someone were to implement a native C++ plotting widget for
wxWidgets and then provide the appropriate wxPython binding for it.


reply via email to

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