> 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: http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/examples/c++/ 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 :-) https://github.com/buoyboy/pre-cog/wiki 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! -josh _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
