Re: Occasional choppiness/underruns (aUaU) with FCDPP->GRC->Pulse

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

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 [email protected]
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-----

-----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 :slight_smile: 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/

iQEcBAEBAgAGBQJTQ7Z4AAoJEBQ6EdjyzlHtZJQH/i01+5DWvLQoWBs42N8VfB+l
a0c5coGNXQMdCdb7ElCrGHxknW3wRKEHR7+kEbYHcVl1pYY7FgS75+YT2PNkUDAQ
FmVOjkeCRHFWOrgIjaKApPHGvIBtmCDf9SVACXNSi0npU2UOu9oTFNRF/o2xSF7k
Ra9PmZCFzZ+Y+6O5SIgjYH6iCC67RffyPmPyvMiGIv7r9WFXguP0e6xTjb3Bipw5
aDPAGT7H+YDOaZ3WJmo09KBtDAlrxl1LHx0wLpigC/5sZlPnJKNypAY575LnG5Aq
ENMKAaZTG5x7Zoa8Uuuh7T0pxVw8RYf8JHYVYqP01L4OJ6vSgWruc88FTJjGgeY=
=9lap
-----END PGP SIGNATURE-----

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

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs