[pulseaudio-discuss] PulseAudio questions

[Nikita V. Youshchenko]

Hello.

We are implementing "floation desktops" here (there is an Xvnc server per 
user running on an application server, and users are connecting from 
different terminals).

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 
their sound.

Now questions.

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);
        else {
...

- 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 
everything works.
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 
mixers :).
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 
non-existent?
Or just use another mixer app which is more pulseaudio-friendly (but still 
runs in KDE panel!)

Thanks on any answers.

Nikita

P.S. the (1) and (2) issues are seen with debian etch pulseaudio package 
(version 0.9.5-5)