[pulseaudio-discuss] Uber-early glitch-free Testing Results
smcnam at gmail.com
Wed Apr 16 10:35:37 PDT 2008
I know glitch-free is still under heavy development, but I took a stab
at it today after reading some of the latest commits. I've had very good
results already and wanted to thank Lennart and co. for the progress on
glitch-free. I'll summarize my efforts in (1) building, (2) configuring
and (3) using, and the results of these efforts.
Ah, and my system is Ubuntu 8.04, x86_64, ALSA 1.0.16* with integrated
HDA Intel sound. It's an 82801H (ICH8 Family).
(1) Everything built fine out of SVN with all dependencies enabled
*: Unfortunately, Ubuntu 8.04 is going to ship with only ALSA 1.0.15,
due to their freeze dates policy. I downloaded and installed
alsa-drivers, alsa-lib and alsa-plugins 1.0.16 from alsa-project.org,
which took about 10 minutes. It's an easy build...
(2) Configuration was pretty easy. I looked through default.pa,
daemon.conf and client.conf, but there were no new options since 0.9.10,
so I simply wiped out the default configurations with my customized
configuration files from PA 0.9.10. I use the system instance as 'pulse'
user, launching it as root (it quickly drops the privs, of course.)
a. One minor issue is that module-suspend-on-idle causes the PA daemon
to abort after a second or two of operation. I'm working on debugging
this to perhaps submit a patch, or at least isolate what's happening.
For now, I've disabled this module so I can forge ahead and test the
b. A moderate issue: On the server side, module-native-protocol-unix
aborts the server with an assertion failed if the name of a new stream
is NULL. So, whenever I went to play a stream, it would abort the
server. I tried giving it a forced name with paplay --stream-name, but
apparently the stream name isn't being passed to the
playback_stream_new() function in pulsecore/protocol-native.c.
Rather than remove the assertion (dangerous if other parts of the
program assume a valid stream name), I did a "quick hack" using GLib and
the uuidgen program: I fork off a uuidgen, trap its stdout, and wait for
it to terminate. Its stdout writes a uuid string, then the program
terminates. All of this was very easy because of the GLib function
g_spawn_command_line_sync. Definitely not production-quality hackage,
but it fixed the assertion so that the code path can continue! I just
wanted to get to the guts of the glitch-free core and put it through its
After re-building, it seems that the core really is working well. I
tested paplay, aplay (through the libasound2-pulse plugin), gstreamer
(pulsesink), and mpd, and all of them work as expected. Furthermore,
mixing of many sounds together works with very low dropout rates, even
with programs that infamously crackle/dropout, like Pidgin playing
during music playback. And my hardware only has a 371ms hardware buffer
Apr 16 12:02:02 vk6rms pulseaudio: module-alsa-sink.c: Using 2
fragments of size 32768 bytes, buffer time is 371.52ms
In Lennart's blog, he said the ideal hardware could have a much larger
buffer size (1 or 2 seconds). So considering my buffer size is pretty
limited in hardware, it's nice that I've only heard a very rare
click/pop noise (about one out of 100 IM beeps during music playback).
By comparison, PA 0.9.10 and earlier clicked or popped almost every time.
Also, CPU load with normal-priority processes has zero impact on dropout
rates. I've pegged my CPU for 10 minutes with the 'apcalc' program
calculating a huge exponent, and it takes 99% CPU in top, but pulseaudio
continues to do what it needs to do during its realtime-scheduled time
Overall, I'm very impressed with the progress on glitch-free, and there
is a very noticeable reduction in glitches with programs that frequently
create and terminate PA streams (such as IM programs). I'll be happy to
help work out the bugs in the peripheral modules and protocols to help
make this branch ready for user testing.
Of course, it's not ready until the actual authors of PA say it is. I'm
just an outside developer taking a peek in, anticipating the changes
coming down the pipe, and hoping to lend a hand if possible. :)
More information about the pulseaudio-discuss