I've just tried to use the PulseAudio ALSA plugin for the first time (I thought it might be a better way to do remote audio than relying on everything supporting bloody esound, and alas some things just don't do anything else). Unfortunately the results are not pretty. With no other clients connected, I get at best very choppy sound, often culminating in an outright hang after a few seconds. Sample backtrace with random program (mpg123): (gdb) bt #0 0x00007f36d834c533 in poll () from /lib/libc.so.6 #1 0x00007f36d79793de in snd1_pcm_wait_nocheck (pcm=0x1a87350, timeout=-1) at pcm.c:2367 #2 0x00007f36d79796a5 in snd1_pcm_write_areas (pcm=0x1a87350, areas=0x7fff5a2f2120, offset=0, size=576, func=0x7f36d79b5de0 <ioplug_priv_transfer_areas>) at pcm.c:6646 #3 0x00007f36d79b60fb in snd_pcm_ioplug_writei (pcm=0x1a87350, buffer=<value optimized out>, size=576) at pcm_ioplug.c:561 #4 0x00007f36d7c07336 in write_alsa (ao=<value optimized out>, buf=0x7f36cc9ad010 "!\354\272\352\177\344\342\353\267\350\226\352\277\367v\360i\374f\367\335\363\022\365\307\362\340\363\233\376Y\374?\004\v\002\235\374\067\376\021\372\316\374\347\003\376\002R\t\352\005\276\005\345\002I\006b\005\200\t\266\f\351\005\267\v\027", bytes=<value optimized out>) at alsa.c:207 #5 0x00000000004036d6 in flush_output (ao=0x1a44fd0, bytes=0x7f36cc9ad010 "!\354\272\352\177\344\342\353\267\350\226\352\277\367v\360i\374f\367\335\363\022\365\307\362\340\363\233\376Y\374?\004\v\002\235\374\067\376\021\372\316\374\347\003\376\002R\t\352\005\276\005\345\002I\006b\005\200\t\266\f\351\005\267\v\027", count=<value optimized out>) at audio.c:594 #6 0x000000000040c721 in play_frame () at mpg123.c:598 #7 0x000000000040dd2b in main (sys_argc=<value optimized out>, sys_argv=<value optimized out>) at mpg123.c:1074 (symptoms also observed with qemu, world of goo and scorched3d, yes I tried to run *that* over the network, I'm a glutton for punishment). This only happens with a remote connection: a local connection, even using the ALSA plugin, works fine. (This is a mostly-idle gigabit network, so I doubt network saturation is to blame). More oddly yet, if I start pavucontrol, whether locally or remotely, before the remote application, the entire session is flawless: if I start it while the choppy playback is going on, the choppiness vanishes. (I suspect this has been reported before as Debian bug 533039.) (PulseAudio on both ends is 0.9.21. Both source and target are x86_64s running Linux 2.6.31.6.) I can do a packet capture of a choppy session if anyone thinks that would help.