[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Underrun and sampling rate problem

From: Josh Blum
Subject: Re: [Discuss-gnuradio] Underrun and sampling rate problem
Date: Mon, 08 Oct 2012 16:46:00 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0

> Are the above suppositions correct? Is there a better way to set sample
> rate which does not have to be hardcoded based on the bitrate of video?
> Maybe somehow set a high sample rate and be done with it?

Basically, you want to have a *lower* data rate of UDP frames vs the
sample rate on the USRP; otherwise packets are going to be *lost* in the
socket buffer. OK, so now, if that is the case, there has to be some
idle time. Are you going to let the USRP transmit chain go silent, or
will you fill in the missing gaps with something?

Suppose that you want to send finite bursts into the USRP sink (transmit
becomes silent). Its important to mark an EOB tag when you know that
there is a break in sample continuity. See this as an example:

Had you seen the pre-cog announcement today? Basically, its a pretty
neat example of doing a MAC layer in gnuradio, and it makes proper use
of end of burst tags and things like this. Also, you could just plug in
a VLC stream into the socket to blob blocks and just send it into the
mac block. We actually did this earlier as part of the demo :-)

On the other hand, suppose that you want to fill in the gaps with
samples generated in the host. You would say, well my UDP socket doesnt
have data, and my work function called me with outputs to fill, ok, here
is my idle data... Now there some delay issues when you do that. For
example, you might shrink the output buffers on the downstream blocks,
or use some concept of time to throttle your data source.

Hope that gives you a few ideas!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]