Hello list, I need some help.
When running GRC 3.6.1 I am getting a problem with occasional choppiness
my audio output. Details:
- The choppiness sounds like only part of the buffer is filling, similar
the sound you get when a filmstrip’s playback gets unstable and you get
- The issue usually does not immediately occur however occurs a few
- Sometimes computer activity such as un-minimizing a window will
the problem. Sometimes the same will fix it.
- Input is Funcube Dongle Pro+ 192khz on alsa hw:3
- Occurs regardless of using FCDPP+ Block or the Audio Input block.
- Output is pulse, originally set to 192khz (pulse resamples it),
it down to native 48khz and used Rational Resampler block to bring the
to 48. Did not resolve, however the issue occurred less often. (still
- Turned on Realtime Scheduling and then adapted the JACK instructions
enabling system realtime scheduling permissions (
http://jackaudio.org/linux_rt_config). Afterward confirmed the python
process to have a nice of -30 which is realtime. Issue did not resolve
again, it happened less often. (still intolerable)
- Occurs regardless of graph complexity. Simple in->out arrangement will
- Sometimes you can hear it get worse as time goes by, and sometimes it
will just as randomly fix itself, only to occur again later.
- I am using pulse as my audio output.
- When the issue occurs, the console output in GRC fills rapidly with
- When the issue occurs, looking into pavucontrol playback tab shows
plug-in [python 2.7]” entry flickering rapidly, as if it is resetting
connection over and over in an unreasonable manner.
- When the issue occurs, the realtime python process on core 2 shows no
change in core usage, however the non-realtime gnuradio-companion
also on core 2, spikes from its usual 0.9% usage to 93%. The only way I
see a high-priority process being pushed out by a low-priority process
if the high-priority process is waiting on the low-priority process for
some operation to complete (this is a DSP no-no).
- When the issue occurs, pulseaudio’s verbose log fills rapidly.
is a snippet of what repeatedly fills the log.
- There is chatter about similar underrun issues with mozilla and pulse.
However the fixes appear to be occurring in mozilla only so there wasn’t
much help from that.
- When attempting to specify ‘pulse’ as signal input in GRC and then
specify FCDPP as its input in pavucontrol, GRC gives silence and a
- pulseaudio 4.0
- Xubuntu 13.10 AMD64.
There was a similar issue posted earlier however it was different in
in the sense that the underruns occurred immediately instead of on
occasion, implying a consistent sample rate mismatch.
It is reasonable to rule out sample-rate mismatch in my case as the
occurs only on occasion and sometimes fixes on its own, a mismatch would
expected to immediately fail. It would be mathematically impossible for
mismatched sample rate to cause such cascading underruns after minutes
proper functioning except for clock drift, which would be expected to be
solved with a single buffer reset (a slight “blip”). This is not what is
happening. It is thousands of consecutive blips after a while of proper
Thanks for reading. Log dump attached.