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