Re: [Discuss-gnuradio] UHD:SingleUSRP and buffer allocation policy

[Marcus D. Leech]

>
> On Mon, Oct 18, 2010 at 08:37:33PM -0400, Marcus D. Leech wrote:
>   
> Since you've got a usrp* source and an audio_sink, what you're seeing
> could be related to the two different clocks in the flow graph.  Do
> you see the problem if the audio_sink is NOT in the graph?
>
> Eric
>
>
>   
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.

I'm happy that I've gotten it down to ~1sec.  At that latency,
cross-site event correlation will be possible.  At 10s of seconds, it
  would be more of a challenge.

But this really does reinforce my notion that some kind of "latency
policy" machinery needs to be implemented, and I'm quite happy to
  toss ideas around.  I totally understand the need for big buffers to
amortize scheduling/function-call/whatever costs, but I'm thinking
  that things need to be tunable in a way that is exposed to the
(perhaps more sophisticated) applications developer.

Interestingly enough, I did some tests on my app to see how filter
parameters affected latency.  They didn't appear to noticably affect it,
  at least in "subjective" tests.  My pre-detector filter can have a
user-tunable bandwidth anywhere from 5KHz to 250KHz, with an input
  sample rate of 400Ksps.  That results in a fairly-large range of
filter lengths, which I assume would get factored into buffer calculations,
  but clearly, there's enough quantizing in buffer calculations going on
that it doesn't matter a hoot.  Filter lengths vary from 38 taps to
  1850 taps, depending on pre-detector bandwidth.




-- 
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org