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

[Steve R Bunch]

>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.

Thanks!

Steve