> 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: [EMAIL PROTECTED]:/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? [EMAIL PROTECTED]:~> cat /tmp/xxx ctl.hw { type pulse; } pcm.default { type pulse } ctl.default { type pulse } [EMAIL PROTECTED]:~> 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 _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss