On Wed, 16.04.08 13:35, Sean McNamara (smcnam at gmail.com) wrote: > 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. Uh, that's a pretty early test ;-) > (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.) module-alsa-sink learned a few new options. System instance is not a good idea since it disables SHM data transfer. I recommend against using it unless you really know what you do. > > (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. Uh, yeah. Almost none of the modules have been entirely ported yet and received the necessary testing, except those I do my testing with, which is module-alsa-sink and module-native-protocol-unix and not much else. Also, I haven't commited anything since a few days. Lots of fixes are still sitting in my checkout. > 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. I fixed that a while ago in my checkout, however, I didn't commit this yet. > 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 Uh, actaully there's a few things that cause remixing not to work as it should in the commited SVN. I fixed it in my checkout, will shortly commit. I assume this is HDA? Unfortunately HDA seems to be limited to 370ms. I wonder if that is a hw limitation or a driver limitation. For testing purposes I usually use USB hw, which allows 6s or so as buffers. It's good for testing, though it actually doesn't lower the IRQ-load since on USB the number of IRQs is not directly dependant on the fragment settings and mmap() audio is mostly emulated anyway. Thanks for your interest, Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4
