Re: [Discuss-gnuradio] Occasional choppiness/underruns (aUaU) with FCDPP->GRC->Pulse

[Chuck Ritola]

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 <address@hidden>
To: <address@hidden>
Subject: [Discuss-gnuradio] Occasional choppiness/underruns (aUaU)
        with    FCDPP->GRC->Pulse
Message-ID: <DUB129-

address@hidden>
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 <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Occasional choppiness/underruns (aUaU)
        with FCDPP->GRC->Pulse
Message-ID: <address@hidden>
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 Ritola wrote:
> 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). 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.
> (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
>
>  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.
>
>
>
> ______________________________

_________________ Discuss-gnuradio
> mailing list address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - 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-----

aplay-l.log
Description: Text Data