I've noticed latency issues with one of the applications I'm working on. Latencies of up to tens of seconds have been observed, which I tried to combat by specifying recv_buff_size in the parameter list.
Right now, I'm running with 4096 bytes, which at 400Ksps, gives me a roughly 1 second latency between input and output (where output is both an audio sink, and a couple of different file sinks as well as a scopesink2, and an FFT sink). But increasing it beyond 4096 bytes causes the latency to go up very quickly, and if I drop it to 1024 bytes, I start seeing over-runs. If you do the math, however, 4096 bytes is nowhere near 1 second worth of buffer. One second is 1.6Mbytes (400Ksps x 4bytes per sample). How is downstream buffer allocation policy affected by settings of recv_buff_size in UHD::SingleUsrp? This is probably the same can of worms I was talking about a few weeks ago, with trying to understand latency issues, and where they'd "bite" you for various classes of applications. For purposes of data recording, my current application can't really tolerate several seconds of latency--since events recorded will potentially need to be cross-correlated with other receivers (although not phase-synchronous, just event correlation down to one or two seconds of accuracy). -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
