[Top][All Lists]

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

Re: [Discuss-gnuradio] End-to-end delay question

From: Steve Bunch
Subject: Re: [Discuss-gnuradio] End-to-end delay question
Date: Sun, 20 May 2007 14:13:37 -0500

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.


reply via email to

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