<div dir="ltr"><div><div><div>Hi Dario,<br><br></div>There should be no need to change the num_send_frames as long as the application can supply samples at the desired sample rate.  If additional buffering is needed, it will only be compensating for the application's inability to provide data consistently at that rate.  The major effects on latency for the TX side will be the send_frame_size and the time taken by the application before calling send().<br><br></div>Regards,<br></div>Michael<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 9, 2015 at 10:47 AM, Dario Fertonani via USRP-users <span dir="ltr"><<a href="mailto:usrp-users@lists.ettus.com" target="_blank">usrp-users@lists.ettus.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Michael West clarified the effect of num_recv_frames on RX latency, which turns out to be an effect only on the peak RX latency allowed.<div><br></div><div>Is the same true for num_send_frames and TX latency?</div><div><br></div><div>Thanks,</div><div>Dario</div></div>
<br>_______________________________________________<br>
USRP-users mailing list<br>
<a href="mailto:USRP-users@lists.ettus.com">USRP-users@lists.ettus.com</a><br>
<a href="http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com" rel="noreferrer" target="_blank">http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com</a><br>
<br></blockquote></div><br></div>