Forum: GNU Radio Underruns using the simplest gnuradio-companion flow graph

Hi.
I have tried the simplest possible flow-graph. A
sine-source->Throttle->Audio-sink. But I get about 1 Hz drop outs and 
the
message pane keeps writing aU.
Using top the  process seems to laod the system less than 2 % and the 
total
load on both processor kernels is well below 20 %. The samling rate is 
48k.
It does not seem to
be possible to lover the sampling rate due to limitations of my sound 
card
(which probably sucks anyway). I am using Fedora 16 on an AMD 64-bit
machine.

So is this really a processor capacity issue. I have sort of hard to
believe that the the processor wont be able to compute 48000 sines per
second and feed it to the sound card but there are of course a lot of
layers in between. Any way rtl_fm seem to be able to feed data to aplay
from a RTL2832U DVB-T recieiver without any problems so my machine is 
not
totally slow.

Isn't there anything I can do to improve the real-time performance of
gnuradio-companion?

Some kind of buffer to add to the flow-graph or something that is 
possible
to tune in the operating system?

Regards

Olof

On Tue, Nov 20, 2012 at 3:42 PM, Olof Tangrot <olof.tangrot@gmail.com> 
wrote:
>
> Some kind of buffer to add to the flow-graph or something that is possible
> to tune in the operating system?
>
> Regards
>
> Olof

Olof,

Don't use the throttle block when you have another rate-limiting
system in your graph. You're audio sink will provide the rate control
in this case. With throttle and the audio sink, you've just created a
two-clock problem where one clock (throttle) is pretty bad.

Tom

On Tue, Nov 20, 2012 at 12:42 PM, Olof Tangrot 
<olof.tangrot@gmail.com>wrote:


> Isn't there anything I can do to improve the real-time performance of
> gnuradio-companion?
>

It may seem unintuitive, but remove the throttle block.  GNU Radio
flowgraphs operate in a demand driven fashion.  The audio sink is 
consuming
data at a fixed rate from the output buffer of the preceding block, 
which
is the re-filled as needed by the preceding block.  The GNU Radio 
scheduler
will only call the work function of the upstream block as needed to keep
it's output buffer full.

Throttle blocks are intended for use when there is no other block that 
is
rate limiting.  In this case, the audio sink is the rate limiter.  When 
you
add the throttle, you have the "two clock" problem.  In your case, the 
PC
clock is operating more slowly (relatively) than the audio card clock, 
so
the throttle block is pacing samples too slowly to keep up with the
consumption rate of the audio block.

Johnathan