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

[Marcus Müller]

-----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 Ritola 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.

> 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.
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-----