[pulseaudio-discuss] PulseAudio questions

[Lennart Poettering]

On Fri, 24.08.07 15:12, Nikita V. Youshchenko (yoush at cs.msu.su) wrote:

> 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 {
> ...

If I understand correctly you are running PA on top of some SunRay
specific OSS emulation? This looks like an issue in that emulation to
me. According to the OSS docs reads/writes to the OSS devices are
always guaranteed to be multiples of the frame sizes in size. And
apparently that guarantee is not valid for these machines?

> - when user starts mplayer within session, 'session-side' pulseaudio server 
> crashes at top of pa_memblockq_drop() on
>   assert(length % bq->base == 0);

Seems to be the same issue here. Both asserts make sure that the data
is properly aligned to fram sizes. And apparently this is not
guaranteed to be true when read/written from the OSS devices.

> 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?

It is very difficult to debug this from here. I think the workaround
in PA would be far from trivial.

> 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?

Sounds like a classic esd bug. Someone mentioned that SunRay would be
using esd for audio, is that right? If so, you're currently having the
ESD experience. It's probably the best idea to replace ESD entirely by PA.

> 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?

I am working on som more transparent network support in PA. Something
like a beefed up tunnel sink with zeroconf support. There's already
module-rescue-streams which moves streams to a different sink if a sink
dies. 

Stay tuned.

> 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 :).

32 mixers? How come? Please explain?

> 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!)

I am sorry. I have no experience with KDE. Presumably you can use the
combination of padevchooser and pavucontrol. 

Lennart
-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4