Underruns using the simplest gnuradio-companion flow graph

GNU Radio
1

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

2

On Tue, Nov 20, 2012 at 3:42 PM, Olof T. [email protected]
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

3

On Tue, Nov 20, 2012 at 12:42 PM, Olof T.
[email protected]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