# Re: Occasional choppiness/underruns (aUaU) with FCDPP-\>GRC-\>Pulse **URL:** \ **Category:** GNU Radio\ **Created:** [April 8, 2014, 6:23am UTC](https://www.ruby-forum.com/t/re-occasional-choppiness-underruns-auau-with-fcdpp-grc-pulse/240314 "2014-04-08T06:23:00Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![musicdenotation](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ea666f/32.png) [@musicdenotation](https://www.ruby-forum.com/u/musicdenotation)\ **Post date:** [April 8, 2014, 6:23am UTC](https://www.ruby-forum.com/t/re-occasional-choppiness-underruns-auau-with-fcdpp-grc-pulse/240314/1 "2014-04-08T06:23:00Z")
There doesn’t seem to be a system in place in gmail/mailman for replying to a list digest entry. Hope this works… Switching from ‘pulse’ to ‘sysdefault’ or leaving it blank appears to fix the issue but breaks pulseaudio and everything running on it by kicking it off of sysdefault. ALSA cannot allow multiple applications to use the same output, which is what gave rise to pulseaudio. My understanding is that ALSA is deprecated to just being a driver interface or for very intensive streams (like USRP) and that direct ALSA access is discouraged since it disables all other applications from sharing the audio I/O. This affects me because I use a lot of tools to analyze and record the monitored signals demodulated by GRC, such as gMFSK through padsp, parec, I need notification sounds, and Audacity. Furthermore, firefox is open when using GRC with sysdefault as its output, flash is broken since it uses pulse and remains broken until the browser is restarted without GRC running. Replacements and rearrangements to work around this problem are nontrivial. Pulse gives good facility to route things around. Giving any application direct access to the ALSA output monitoring device (sysdefault) instead of pulseaudio’s virtual outputs breaks everything but GRC. I am using a Phenom II X3 running at ~2.8GHz. 4GB ram. Under normal circumstances the overhead of pulseaudio is very low. Using a graph to reproduce the issue consumes about 10% of one core using sysdefault (direct to ALSA) in the output block, and when using ‘pulse’ in the output block, the same 10% of one core. In all cases, the FCDPP is accessed directly as hw:3 because using pulse and routing it doesn’t work - it just gives silence and “aUaUaU”. The flutters are apparently coming from the connection between pulse and GRC being reset rapidly over and over again. It should not be resetting this much. This is causing the big CPU spike and continued fluttering. I do not know if this is a GRC issue or pulse issue, but all of my applications but one (noted below) have never had any issues of this nature. I can even play MP3s from exaile which sound fine while GRC continues to flutter in the background. The exception was gMFSK through padsp, the waterfall plot shows occasional signs of the same fluttering when pulseaudio routes GRC to gMFSK’s input, it would scroll 2-3x faster with gaps, even when GRC-\>pulse was sounding fine at the moment. When that occurs, pulseaudio’s CPU usage spikes to the 90% range of a core. I am using the GRC version supplied by Ubuntu’s repositories. Is there a rationale for Ubuntu MOTU holding back to such an old version? Some updates on what has been tried: - ‘OK to block’ on inputs and output blocks - did not resolve - Switching pulseaudio to realtime thread. - did not resolve - aplay -L output attached. Message: 2 Date: Mon, 7 Apr 2014 14:30:06 +0300 From: Murat Tolo?lu [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) To: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: [Discuss-gnuradio] Occasional choppiness/underruns (aUaU) with FCDPP-\>GRC-\>Pulse Message-ID: \ Content-Type: text/plain; charset=“iso-8859-9” Chuck, In most cases the problem comes from ALSA. If you’re able to change ALSA to something else, try to change it. If you can’t change your default sound driver then you may try using “-Dplug:default” option for aplay. If you need to use this option with a Python script you may use it like " -c plug:default". This was my only solution when I tried running rtl\_fm on Raspberry because default audio driver of Raspberry is ALSA and not possible to change (everything else like Jack, Pulseaudio etc. can’t be a solution because all of them run over ALSA, ALSA always remains at the bottom, so the problem always remain). I hope this helps. Regards, Murat, TA1DB Message: 3 Date: Mon, 07 Apr 2014 13:56:34 +0200 From: Marcus M?ller [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) To: removed\_email\_address@domain.invalid Subject: Re: [Discuss-gnuradio] Occasional choppiness/underruns (aUaU) with FCDPP-\>GRC-\>Pulse Message-ID: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Content-Type: text/plain; charset=ISO-8859-1 -----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 > [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----- ---
**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 8, 2014, 10:44am UTC](https://www.ruby-forum.com/t/re-occasional-choppiness-underruns-auau-with-fcdpp-grc-pulse/240314/2 "2014-04-08T10:44:02Z")
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Chuck, really in a hurry now, but I can’t let you down, sooo: On 08.04.2014 06:22, Chuck R. wrote: > There doesn’t seem to be a system in place in gmail/mailman for > replying to a list digest entry. Hope this works… > > Switching from ‘pulse’ to ‘sysdefault’ or leaving it blank appears > to fix the issue > This kind of says don’t use pulseaudio 🙂 at least for this application > but breaks pulseaudio and everything running on it by kicking it > off of sysdefault. ALSA cannot allow multiple applications to use > the same output, which is what gave rise to pulseaudio. > Not really. dmix has been around for a long time now, which is ALSA’s > method of mixing multiple streams. Basically, you should be able to > dmix GNU Radio’s output and pulse’s output. > The question here is whether mixing using DMIX is really more > efficient than using pulse. My wild guess here is that, yes, it is. Pulseaudio is the default soundserver for gnome-ish desktop environments – it was meant to relieve application designers of the task of coping with different audio hardware, mixing, remote audio etc and giving programs a unified control interface. It is very much designed to be easy to use and good for applications that want to output a “chime” once in a while or “just want to play that MP3, and not worry”; I don’t think it was designed for high-rate continuous streams… > My understanding is that ALSA is deprecated to just being a driver > interface or for very intensive streams (like USRP) and that direct > ALSA access is discouraged since it disables all other applications > from sharing the audio I/O. > s.a. > This affects me because I use a lot of tools to analyze and record > the monitored signals demodulated by GRC, such as gMFSK through > padsp, parec, I need notification sounds, and Audacity. > I think at least for parec there should be a workaround using alsa > loopback and any recording program, or even just monitoring the output > stream. > Then again, you can just write your GNU Radio output to a wav file > whilst simultaneously outputting it to alsa/pulse; maybe that is what > you need? > Furthermore, firefox is open when using GRC with sysdefault as its > output, > sounds like dmix can fix that > flash is broken > I just leave this here. Flash has always been broken – do you > _really_ need flash on the PC you’re doing signal processing on? > since it uses pulse and remains broken until the browser is > restarted without GRC running. Replacements and rearrangements to > work around this problem are nontrivial. Pulse gives good facility > to route things around. Giving any application direct access to the > ALSA output monitoring device (sysdefault) instead of pulseaudio’s > virtual outputs breaks everything but GRC. > Ok, to be completely frank here: > It looks like your computer is not up to the task of mixing pulse > streams while simultaneously doing signal processing and watching > Flash movies. Or maybe this is an irregularity in pulse, or pulse > starts to internally resample other streams from 44.1kHz to 48 or very > many other things… > I’d say: try using dmix, if you really need to mix your GNU Radio > output and your system sounds. > I am using a Phenom II X3 running at ~2.8GHz. 4GB ram. > > Under normal circumstances the overhead of pulseaudio is very low. > Using a graph to reproduce the issue consumes about 10% of one core > using sysdefault (direct to ALSA) in the output block, and when > using ‘pulse’ in the output block, the same 10% of one core. In all > cases, the FCDPP is accessed directly as hw:3 because using pulse > and routing it doesn’t work - it just gives silence and “aUaUaU”. Seems like pulse is simply just not up to the task on your PC. > to gMFSK’s input, it would scroll 2-3x faster with gaps, even when > GRC-\>pulse was sounding fine at the moment. When that occurs, > pulseaudio’s CPU usage spikes to the 90% range of a core. > This really looks like a pulse issue to me. Greetings, Marcus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - [http://www.enigmail.net/](http://www.enigmail.net/) iQEcBAEBAgAGBQJTQ7Z4AAoJEBQ6EdjyzlHtZJQH/i01+5DWvLQoWBs42N8VfB+l a0c5coGNXQMdCdb7ElCrGHxknW3wRKEHR7+kEbYHcVl1pYY7FgS75+YT2PNkUDAQ FmVOjkeCRHFWOrgIjaKApPHGvIBtmCDf9SVACXNSi0npU2UOu9oTFNRF/o2xSF7k Ra9PmZCFzZ+Y+6O5SIgjYH6iCC67RffyPmPyvMiGIv7r9WFXguP0e6xTjb3Bipw5 aDPAGT7H+YDOaZ3WJmo09KBtDAlrxl1LHx0wLpigC/5sZlPnJKNypAY575LnG5Aq ENMKAaZTG5x7Zoa8Uuuh7T0pxVw8RYf8JHYVYqP01L4OJ6vSgWruc88FTJjGgeY= =9lap -----END PGP SIGNATURE----- ---
**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 8, 2014, 12:35pm UTC](https://www.ruby-forum.com/t/re-occasional-choppiness-underruns-auau-with-fcdpp-grc-pulse/240314/3 "2014-04-08T12:35:01Z")
On 04/08/2014 10:42 AM, Marcus M. wrote: > […] > > > I am using a Phenom II X3 running at ~2.8GHz. 4GB ram. > > > Under normal circumstances the overhead of pulseaudio is very low. > > Using a graph to reproduce the issue consumes about 10% of one core > > using sysdefault (direct to ALSA) in the output block, and when > > using ‘pulse’ in the output block, the same 10% of one core. In all > > cases, the FCDPP is accessed directly as hw:3 because using pulse > > and routing it doesn’t work - it just gives silence and “aUaUaU”. > > Seems like pulse is simply just not up to the task on your PC. Hm, I don’t really think Pulse is the issue. “High rate audio streams” don’t really exist (what is 48 kHz compared to our radio stuff)? Chuck, I know you say it’s not a two-clock problem, but I’m not convinced, despite your great problem description. It takes little difference to cause lots of underruns. One way you can figure that out is by resampling a bit above the audio rate (say, 48100 or 48200 Hz) and piping that into a Pulse that expects 48000 Hz. If you get less Us (maybe some Os), that’s the problem. Martin