[pulseaudio-discuss] PulseAudio questions
Nikita V. Youshchenko
yoush at debian.org
Fri Aug 24 03:07:51 PDT 2007
We are implementing "floation desktops" here (there is an Xvnc server per
user running on an application server, and users are connecting from
To provide audio, we are trying to use pulseaudio:
- for each user session, a pulseaudio server is started on the application
server, that listens on a unix domain socket; PULSE_SERVER inside session
point to this socket
- on each terminal, a pulseaudio server is started that communicates with
local audio hardware
- when a user connects to his session from a terminal, session's pulseaudio
server is configured to forward audio to terminal's pulseaudio server
(using a script that communicates with session's pulseaudio server through
a command-line socket).
In this way, we get audio automatically forwarded to the terminal where
user connected, and users can go from one terminal to other and still have
1. I was experiencing assertion failures in both 'terminal'-side
and 'application-server'-side pulseaudio servers. In particular:
- when pulseaudio server is starteed for SunRay terminal, and module-oss is
loaded with device=/tmp/SUNWut/dev/utaudio/utdsp-N (this is where SunRay
software puts it's audio device files), it gets assertion failure at
module-oss.c:177, which is:
if (memchunk == &u->silence)
assert(r % u->sample_size == 0);
- when user starts mplayer within session, 'session-side' pulseaudio server
crashes at top of pa_memblockq_drop() on
assert(length % bq->base == 0);
I tried to comment out both asserts, and without those looks like
However, I guess that asserts are there for a reason? What is a better fix?
2. When applications within session are playing short sounds, it sounds
like last very short fragment (0.1 sec or so) of eash sound is played at
the beginning of the next sound. Looks like somewhere a buffer is not
flushed at sound end, so data collected there is passed to audio hardware
when new sound if being played.
Any comments on this?
3. It will be very useful to implement completely transparent audio
migration, such that apps playing 'long' sounds will not notice that user
disconnected and then reconnected from other terminal, but will
transparantly continue playing.
From pulseaudio point of view, audio sink on 'session' pulseaudio server
may disappear, and then - probably after some minutes - a new 'sink' may
appear. And same with source.
Is it possible to script pulseaudio server somehow such that applications
running in the session won't notice anything?
4. Is there any audio mixer application that may run within KDE's panel,
and control audio volume in this configuration.
KDE's kmix talks to ALSA directly. I was able to fool it by writing in alsa
configuration file that ctl 'hw' is 'type pulse', and it even worked. But
real 'hw' device has parameters, so my hack resulted in kmix recognized 32
Maybe it is possible to set up things such that 'hw' only with particular
parameters is 'type pulse', and with all other parameters it is
Or just use another mixer app which is more pulseaudio-friendly (but still
runs in KDE panel!)
Thanks on any answers.
P.S. the (1) and (2) issues are seen with debian etch pulseaudio package
More information about the pulseaudio-discuss