Forum: GNU Radio Re: End-to-end delay question

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
1487c5d385789abda073794d640a29dd?d=identicon&s=25 Steve R Bunch (Guest)
on 2007-05-09 02:03
(Received via mailing list)
>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
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2007-05-09 05:41
(Received via mailing list)
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
This topic is locked and can not be replied to.