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

[Eric Blossom]

On Tue, May 08, 2007 at 05:01:49PM -0700, Steve R Bunch wrote:
> >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.
> 
> Thanks.  Will check on this.
> 
> >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.
> 
> It takes a lot of buffering to get USB up into the multiple-second range, so 
> it seems like your change to the default should prevent that side from 
> getting too deep...
> 
> >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.
> 

> I understand the clock domain issue, hence was not too concerned
> about the over/underruns related to the audio not running at exactly
> the same clock rate as the USRP - though I didn't expect there to be
> enough buffering in the pipeline to cause this much delay.  However,
> non-blocking the audio interface wouldn't prevent the (apparently
> large) amount of stuff I see buffering up anywhere it can in the
> pipeline in one direction (or, if not in that direction, then the
> other...) unless you're lucky on which clock is faster.  I'll go
> look at the alsa code.

Having the audio be non-blocking will stop the buffering/delay problem.
The symptom that you see without it depends on which clock is faster.

For example, we run data transceiver applications where there's no
audio involved, where the total lateny in the system is on the order of
a couple of milliseconds.

Eric