[pulseaudio-discuss] Uber-early glitch-free Testing Results

[Sean McNamara]

Hello all,

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 
except LIRC.
*: 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.)

(3)
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 
glitch-free functionality.

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

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 
size:
Apr 16 12:02:02 vk6rms pulseaudio[5246]: 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 
slices.

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

Best Regards,

Sean