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

[Eric Blossom]

On Mon, May 07, 2007 at 06:24:47AM -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. 
> 
> So what is the best way to flush the entire audio stream, end-to-end, 
> from time to time?  Or force the buffering to be minimized to reduce 
> the total in the pipeline?  I would have thought stopping the graph 
> would drain it,  but the recent email trail on stop() has made me 
> wonder what the semantics of stop() really are. 
> 
> System is a dual-processor Pentium, CPUs running at about 30% 
> utilization, running Fedora Core 6.  Audio is default Alsa, on-board 
> (ASUS motherboard) hardware.  GNURadio version is 3.0, SVN'ed from the 
> production tree a month or so ago. 
> 
> Steve 
> 
> Using RX d'board B: TV Rx 
> >>> gr_fir_ccf: using SSE 
> >>> gr_fir_fff: using SSE 
> 

There is (was) a pretty substantial memory leak in wxWidgets/wxPython
that has been fixed in some relatively new release.  This would
eventually cause problems (30 minutes or so).  You can see if this is
happening or not by watching the process size with ps.

You can specify less buffering in the USB interface than the default
(Actually, I'll change the default later today.  This was causing a
different problem for another application.)  This will reduce the
buffering in the interface to the USB to something like 32 kB.

There is a general issue related to the fact that when using
usrp_wfm_rcv and similar applications that there are in fact two clock
domains, and that they are guaranteed not to match.  There's an osc on
the USRP and an osc associated with the sound card.  We made an API
change in the audio interfaces that can specify that it's NOT OK to
block when accessing the audio interface.  When used in a flow graph that
contained both an audio sink or source and a USRP sink or source, this
would result in the USRP being the master clock, and would dodge the
"two clocks" problem.  Although the parameter was added to all (most)
audio interfaces, I believe that it currently only works on the
portaudio interface.  Please feel free to fix this for gr-audio-alsa,
gr-audio-oss and gr-audio-osx.

Eric