Re: [Discuss-gnuradio] Testing an GRC project runs nearly 200% CPU

[Marcus Müller]

Hi Andreas,
> Yes i remember a lot of such characters on the console. Is the sample
> rate of the audio device to small ?
in some way or another, yes.
Explanation: A sound card consumes a fixed about of samples per second
(e.g. 48,000), that we shall call f_sample,soundcard
You need to supply these in time, and if you don't, your sound will be
choppy and you'll see aU.

The fact that you're not doing that in time can have two reasons
(actually three reasons[1]):

1) systematically: You take your RF samples from your SDR peripheral,
and you process it, decimating it to a fixed rate of f_sample,RF <
f_sample,soundcard.
2) computationally: although your theoretical flow graph does the right
thing, ie. f_sample,RF / decimation == f_sample,soundcard, your computer
can't process these samples in time, and your sound card has to wait for
these samples. Since the real world time keeps running on, it can't
produce sound.
3) real physics don't like anybody: both the sound card and your RF
hardware have oscillators from which they generate their sampling rates;
these oscillators will neither be perfect nor will they be coherent, so
inevitably there will be some mismatch between the expected and actual
sampling rates. However, these offsets tend to be small and would
usually not lead to massive accumulations of audio underruns.

So, since the same application works on a faster machine, I'd say it's
2). What you could check, though, is that the sampling rate you set in
your audio sink is actually supported by the hardware, and try with
different values (e.g. 44,100 Hz instead of 48,000, but that's about it
when it comes to usual sampling rates), but you'd of course have to
adjust your decimation between RF hardware and sound card accordingly.

Greetings,
Marcus

[1] http://youtu.be/7WJXHY2OXGE?t=40