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

[Lennart Poettering]

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