iam testing an UKW Radio Receiver GRC project (gr-rds) on bananapi. The
application starts. The tuned radio station sounds clicking. Changing
any parameter in the GUI is very difficult/slow.
top tells me a memory usage about 20 %. CPU usage is nearly 200 %
(bananapi has 2 CPUs). At any webside i read that working with no
throttle blocks could run a CPU to maximum. In my project which iam
testing i see no throttle blocks. I am not sure if that could be the
reason because iam working on the bananapis real hardware ?
you never need a throttle block when you have hardware that
limits/defines your real-world sampling rate; in your case, it’s your RF
hardware and your sound card.
Aside from things like implicit resampling in the audio card driver
infrastructure, it’s absolutely possible that your bananapi is simply
not performant enough to do GUI, signal processing and audio playback at
once.
The question is: Does the same application work sufficiently well on a
fast PC? Do you see any over- or underrun warnings on your console?
you never need a throttle block when you have hardware that
limits/defines your real-world sampling rate; in your case, it’s your RF
hardware and your sound card.
Aside from things like implicit resampling in the audio card driver
infrastructure, it’s absolutely possible that your bananapi is simply
not performant enough to do GUI, signal processing and audio playback at
once.
that’s kind of interesting, because if it works on a PC, I’d say it’s a
performance issue; if you don’t see aU (audio underruns) or some osmosdr
warnings, then I’d say it’s not.
What one does in this situation is both running a process-based cpu
usage tool; I recommend “htop” (which is like top, but actually a lot
nicer). Do you have another process suddenly consume CPU? Does it look
like it’s pulseaudio (that would be the implicit audio resampling
issue)?
If, what I presume, you only see two python processes consuming 100%
each, you will need to dig deeper. There’s a tool called “perf” [1],
which, when run as “perf top” as root will let you introspect CPU usage
per method, including kernel routines.
Both perf and htop are available as packets for many Linux
distributions.
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]):
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.
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.
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.