> 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?
SunRay software creates audio device files for each connected terminal:
root at sunraysrv:/tmp/SUNWut/dev/utaudio> ls -l | grep -- -5
crw------- 1 nikita users 14, 3 2007-08-22 17:53 utdsp-5
prw------- 1 nikita users 0 2007-08-22 17:53 utdsp-5stat
crw------- 1 nikita users 14, 0 2007-08-22 17:53 utmix-5
These devices are serviced by a kernel module, utadem.ko, which is included
with SunRay server software. Module comes with sources, so I may try to
check what happens with data written to the device.
Most OSS software does not have issues with these devices. PA is the first
one. Although I did not try many :)
> > - 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.
I'm willing to help debugging. What should I do/check/etc ?
> > 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.
This happens also with a PC/linux terminal. Just reproduces with the
following setup:
Termimal runs a pulseaudio daemon what talks to local audio hardware (via
alsa) and listens with module-native-protocol-tcp
Application server runs a pulseaudio daemon that listens through
module-native-protocol-unix and forwards data to terminal with
module-tunnel-sink.
Applications play audio with 'paplay'.
So only pulseaudio (and terminal-side alsa hardware) is involved. No esd.
>
> > 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.
Great, will look into module-rescue-streams.
> > 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?
nikita at desktopvm:~> cat /tmp/xxx
ctl.hw {
type pulse;
}
pcm.default {
type pulse
}
ctl.default {
type pulse
}
nikita at desktopvm:~> ALSA_CONFIG_PATH=/tmp/xxx kmix --nofork
And see how many mixer it finds. Oh, there are not 32, only 20 :)
Looks like kmix tries to open different ALSA mixers, and with such a config
all those are opened successfully and forwarded to pulseaudio.
> > 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.
The question was more about ALSA than about KDE.
Probably I may write something in the alsa configuration file that ctl hw
only with particular parameters will be forwarded to pulse, and all others
will be reported as non-existent.
Nikita
