# Occasional choppiness/underruns (aUaU) with FCDPP-\>GRC-\>Pulse **URL:** \ **Category:** GNU Radio\ **Created:** [April 6, 2014, 3:10am UTC](https://www.ruby-forum.com/t/occasional-choppiness-underruns-auau-with-fcdpp-grc-pulse/240284 "2014-04-06T03:10:48Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![Detlef\_R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/58f4c7/32.png) [@Detlef\_R](https://www.ruby-forum.com/u/Detlef_R)\ **Post date:** [April 6, 2014, 3:10am UTC](https://www.ruby-forum.com/t/occasional-choppiness-underruns-auau-with-fcdpp-grc-pulse/240284/1 "2014-04-06T03:10:48Z")
Hello list, I need some help. When running GRC 3.6.1 I am getting a problem with occasional choppiness in my audio output. Details: - The choppiness sounds like only part of the buffer is filling, similar to the sound you get when a filmstrip’s playback gets unstable and you get that ‘jitter’ - The issue usually does not immediately occur however occurs a few minutes into use. - Sometimes computer activity such as un-minimizing a window will trigger 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), brought it down to native 48khz and used Rational Resampler block to bring the 192 to 48. Did not resolve, however the issue occurred less often. (still intolerable) - Turned on Realtime Scheduling and then adapted the JACK instructions for enabling system realtime scheduling permissions ( [http://jackaudio.org/linux\_rt\_config](http://jackaudio.org/linux_rt_config)). Afterward confirmed the python process to have a nice of -30 which is realtime. Issue did not resolve but again, it happened less often. (still intolerable) - Occurs regardless of graph complexity. Simple in-\>out arrangement will reproduce issue. - 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 “aUaU” - When the issue occurs, looking into pavucontrol playback tab shows “ALSA plug-in [python 2.7]” entry flickering rapidly, as if it is resetting its 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 process, also on core 2, spikes from its usual 0.9% usage to 93%. The only way I can see a high-priority process being pushed out by a low-priority process is 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. attached 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. ([779392 - Improve the ALSA PulseAudio bug workaround used to fix bug 761274](https://bugzilla.mozilla.org/show_bug.cgi?id=779392)) - When attempting to specify ‘pulse’ as signal input in GRC and then specify FCDPP as its input in pavucontrol, GRC gives silence and a stream of “aU” - pulseaudio 4.0 - Xubuntu 13.10 AMD64. There was a similar issue posted earlier however it was different in nature in the sense that the underruns occurred immediately instead of on occasion, implying a consistent sample rate mismatch. [https://lists.gnu.org/archive/html/discuss-gnuradio/2013-08/msg00516.html](https://lists.gnu.org/archive/html/discuss-gnuradio/2013-08/msg00516.html) It is reasonable to rule out sample-rate mismatch in my case as the issue occurs only on occasion and sometimes fixes on its own, a mismatch would be expected to immediately fail. It would be mathematically impossible for a mismatched sample rate to cause such cascading underruns after minutes of 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 functioning. Thanks for reading. Log dump attached. ---
**Author:** ![cremes](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e19b73/32.png) [@cremes](https://www.ruby-forum.com/u/cremes)\ **Post date:** [April 7, 2014, 1:57pm UTC](https://www.ruby-forum.com/t/occasional-choppiness-underruns-auau-with-fcdpp-grc-pulse/240284/2 "2014-04-07T13:57:37Z")
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Chuck, thanks for the detailed problem description! The fact that resizing windows etc leads to the issue appearing might be indicative of insufficient processing power; can you tell us something about your PC? Why do you need pulse? Can you eliminate that additional computational load by specifying the hardware alsa device in the alsa sink ("aplay - -L" should list candidates)? I don’t actually know if much changed in alsa\_sink, but you might want to update your GNU Radio installation to 3.6.5 or even take the API change and switch to 3.7 for sustainable development 🙂 Greetings, Marcus On 06.04.2014 03:09, Chuck R. wrote: > trigger the problem. Sometimes the same will fix it. \* Input is > (still intolerable) \* Occurs regardless of graph complexity. Simple > 2, spikes from its usual 0.9% usage to 93%. The only way I can see > specify FCDPP as its input in pavucontrol, GRC gives silence and a > mismatch would be expected to immediately fail. It would be > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Discuss-gnuradio > mailing list [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - [http://www.enigmail.net/](http://www.enigmail.net/) iQEcBAEBAgAGBQJTQpJyAAoJEBQ6EdjyzlHtoKQIAJhEjcYqmuXzk9zogdrXIEgL Fzs/J8woaI1XMTlsudF2T77n4q7W+/AU8XSUqan4QEDPttM049wz+3zXrkae2HpL KzSb3+Q1w57dfO/P3P84DEAmLKR4FwCr/rd3mW0aieSsaLkp/Weua8OMdJBlP5Og 4Ah0r4Fr/OPXxCVqukq4O4j+ZC1eWcLHX1HdYX57OanU4G+OS6tsa7FN94nSLE/U zuLBbKd6JAgJNve9gfQWVbqjdWoGrPu0OswHVHnKLnY/wlj2OULe9bv45ioOLw3K Y1Xk/Rv7OqfEBA+va6MJMueefDr2TGe7IlrVnk/uzpo66YRhMZakMjCXiYvTD3Y= =hwS+ -----END PGP SIGNATURE-----