Hi there, I'm trying to get Pulseaudio working on a thin client setup. My setup is Ubuntu Hardy with LTSP 5, with default configuration of the Pulseaudio server running as a system-wide daemon on the thin client. The main problem is Adobe Flash support. I know there is libflashsupport (as pointed out in http://www.pulseaudio.org/wiki/FlashPlayer9Solution), but with this, the whole firefox + flash + libflashsupport -combination is not stable. About three percent of all flash-applications that have sound crash randomly, taking down the whole firefox process with it. Some partial solutions to this problem are flashblock extension and nspluginwrapper that protects the firefox from crashing, but these do not fix the real problem. I suspect the real problem with this setup is that Adobe does not care much to fix bugs in the audio API that libflashsupport uses. Yet the internal ALSA support in Flash appears quite solid, it does not really crash. So, in theory, it should be possible to simply use the pulse-plugin for ALSA, to transport the audio stream to a pulse server. However, when libflashsupport is not used, alsa emulation layer for pulse will step in place, yet audio does not work in this case. What seems to happen is a pulse client attempts to connect a pulse server repeatedly, starting a new thread for each attempt, and closing the connection by itself. Server logs (when ran with --log-level=debug) tell me this for each attempted connect: ----- I: socket-server.c: TCP connection accepted by tcpwrap. I: client.c: Created 18 "Native client (TCP/IP client from 10.249.0.240:44653)" I: client.c: Client 18 changed name from "Native client (TCP/IP client from 10.249.0.240:44653)" to "ALSA plug-in [firefox]" I: module-volume-restore.c: Restoring sink for <pulsecore/protocol-native.c$ALSA plug-in [firefox]> I: module-volume-restore.c: Restoring volume for <pulsecore/protocol-native.c$ALSA plug-in [firefox]> I: sink-input.c: Created input 17 "ALSA Playback" on alsa_output.hw_0 with sample spec s16le 2ch 44100Hz and channel map front-left,front-right D: memblockq.c: memblockq requested: maxlength=88200, tlength=88200, base=4, prebuf=3528, minreq=3528 D: memblockq.c: memblockq sanitized: maxlength=88200, tlength=88200, base=4, prebuf=3528, minreq=3528 I: sink-input.c: Freeing output 17 "ALSA Playback" I: client.c: Freed 18 "ALSA plug-in [firefox]" I: protocol-native.c: connection died. ----- I would be interested to know why this happens. I'm not expecting the alsa emulation for pulse to be 100% complete, but would like to know what is it in this particular case that alsa emulation object for pulse should do to make this setup work, and if fixing this issue might be a five-minute-fix once it is properly understood, or would it take weeks to reach a partial solution. What I suspect is the real problem here, is that Adobe Flash insists on opening the audio device with mmap(), so that it can write to the audio device buffer directly. At least in the case where the audio device is on the same machine where it is running, it prefers to do an mmap system call to the device file descriptor with parameter MAP_SHARED. And then, alsa emulation cannot handle this situation. I wonder is there anyone on this list who has seen this, looked into this issue, and can confirm or deny this? Juha