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

[Steve Bunch]

> 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