[pulseaudio-discuss] Uber-early glitch-free Testing Results
lennart at poettering.net
Wed Apr 16 12:04:35 PDT 2008
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.
> 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
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
> Apr 16 12:02:02 vk6rms pulseaudio: 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 Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
More information about the pulseaudio-discuss