I noticed that the GNU radio’s GUI for a simple FM receiver can
become un-responsive. For example, when trying to run the WFM receiver
example, the Frequency Slider moves, but the frequency of the station
doesn’t change. There is a Failed message at the bottom left corner of
At times, when it launches, it works fine and doesn’t show the audio
buffer under-run messages, but if I stop and relaunch the same
application, I suddenly get a whole bunch of audio buffer under-runs.
Is GNU Radio stable enough? Or are these type of issues common in the
current release, and needs to be fixed?
For example, I notice that if some internal blocks or computations don’t
correctly align, like if I have a audio input rate of 32051, the system
doesn’t launch, but if I set the audio input rate to 32050, the WFM
receiver launches (refer to my earlier thread, where I still haven’t got
the rational resampler way of getting the FM receiver to work). See the
following thread for the example patch to reproduce this behavior
I’m assuming that the FM receiver example is simple enough. But if the
system gets bogged down like this with a simple application, what about
more complex applications like a WiFi transceiver, or HDTV
Is this a general behavior that everyone else sees, i.e. GNU Radio being
unstable and un-responsive at times?
I have 8 virtual CPU cores allocated to my Linux VMware image, and a
dedicated ethernet port connected to the USRP2. CPU utilization is still
restricted to 2 CPUs and the load is between 20 to 30 percent for when
running the FM receiver application. The host computer is a iMac
quad-core i7 processor at 2.8 GHz. I’ve allocated 2.5GB RAM to the linux
I would like to know if the system instability and un-responsiveness is
something specific to my system configuration or if it is related to GNU
Radio or the USRP2 or the particular firmware that I’m using (txrx_wbx).