Steve Bunch wrote:
I was listening to an FM station using
usrp_wfm_rcv.py -f 93.1 -O pcm32k
After this had been going on for a couple of hours, the output on the
screen showed a large number of over/underruns (complete output
pasted at the bottom to make it easy to discard), which were coming
out through the entire session. This amount of over/underrun is a
fairly new thing, haven't seen this much before, don't know what
changed, but that's a side-issue to my question.
At the end of that run, I turned on an analog radio tuned to the same
station, and there was a 2-3 second time difference between the two
audio outputs. Assuming this was buffered in the audio system, that's
100K samples or so. If you were using the USRP audio output to listen
to a ham band for a while, heard something you wanted to reply to,
and hit the PTT button, you'd be 2-3 seconds behind real time.
On May 7, 2007, at 8:33 AM, Bob McGwier wrote:
I want to make sure you have a very late wxgtk installed. Versions
earlier than very recent indeed have a really ugly memory leak.
Eventually this memory leak really puts the hurt on the entire system.
I am pretty sure this is your problem.
I made sure the wxgtk was up to date, and it was. Watching system RAM
usage, it remains flat for hours at around 266MB (of a 1GB machine,
with swap disabled).
I did determine why the excessive overrun of the audio channel started
happening suddenly. Normally, when working with GNURadio/USRP, I am
working at the display/keyboard of the Linux box that hosts the USRP.
However, during this particular long USRP run, I was sitting at a
different computer, connected in to this Linux box via X windows, doing
other (unrelated) things on it. I was initially suspicious of X and
the network drivers, since I was hitting them very hard, but couldn't
force any problems in brief testing.
What I noticed eventually by accident was that the beagled background
process, which is enabled by default in Fedora Core 6, kicks in when
the console of the Linux box goes idle for a while (screen saver kicks
in), and wants to consume 100% of CPU time to index my files. The CPU
scheduling interference with GNURadio, due to the default time-sharing
scheduling regime both were running under, was causing the audio
sinking to get behind. Turning off the beagled default startup has
made the overrun problem disappear. (As would running GNUradio with RT
scheduling priority, which I'd be doing in production use.)
I haven't had time to look at fixing the gr.*alsa sink code (it's on
the to-do list), but the python code is indeed requesting non-blocking
output.
Steve
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
