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 
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]
Discuss-gnuradio Info Page
-----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-----