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: Michael Dickens
Subject: Re: [Discuss-gnuradio] Problems running example audio_fft.py
Date: Sun, 22 Oct 2006 13:41:14 -0400

On Oct 22, 2006, at 12:34 PM, Brett I Balogh wrote:
It was installed from binary, version 2.7.1.1, unicode. I subsequently installed version 2.6.3.3 from binary and audio_fft came to life. The waterfall is wonky
though.

So what you're saying is that it's the version of wxPython that was working or not? I'm using 2.6.3 as installed by DarwinPorts (from source), and it does just fine (though slow; more below on that). Any other OSX users of GR using 2.7.X successfully?

When you say "wonky" what exactly do you mean?

I know that the GNU Radio GUI stuff is -slow- on OSX because it does wx(Python)->X11->Aqua/CoreGraphics, and the "X11->" part is a big bottleneck. Linux has faster graphics because it uses native X11 processing. In theory it would be possible to create a module for "gr-gui-osx" (and thence "gr-gui-wx", "gr-gui-window" and such via a means similar to gr-audio-*), and then all of the GUI's would be native to their host, which would certainly speed things up for OSX (and I would presume Windows too). That would also mean rewriting any GUI stuff for a common API which would be supported by all of the GUI modules ... which IMHO is certainly doable if anyone wants to do it. Has anyone thought of this aspect of GNU Radio? Certainly seems like there are other OS-specific modules and/or sections, so why not for the GUI as well? - MLD




reply via email to

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