Hard to get objective numbers, but it seems like there's no difference whether I have the audio sub-graph enabled or disabled. The absolute minimum latency I can observe is about 1 second or so, with an input recv_buff_size=2500. I know that there's buffering in the USRP2, but not that much--32K? Less? More? Even so, at my sample rate, 32K is only about 20ms of latency.
The host cannot back-pressure the USRP2, and the buffering in the USRP2 itself if negligible. So, all of the backing-up that is going to happen occurs in the host when you dont read data out fast enough.
The UHD-USRP2 receive path has two buffers that fill when calls to recv() dont keep up. One is the socket buffer in the kernel, and the other is a UHD allocated buffer that hangs onto frames from the socket->receive() call. Both of those drop when filled, so any further buffering/latency you are seeing is happening in gnuradio.
You can manipulate the socket buffer size and the number of frames: http://www.ettus.com/uhd_docs/manual/html/transport.html#transport-parameters
-Josh _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
