Re: End-to-end delay question

GNU Radio
1

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.

Thanks!

Steve

2

On Tue, May 08, 2007 at 05:01:49PM -0700, Steve R Bunch wrote:

buffering in the interface to the USB to something like 32 kB.
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