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
