On Fri, 31.10.08 19:53, Rafa? Mu?y?o (galtgendo at o2.pl) wrote: > You're right, I've mixed up those two. > The annoying part is it doesn't seems to work even for root. --system is not the same as running as root. --system runs PA as pulse:pulse. > What about the options ? > I was trying to set tsched_buffer_watermark=48 in system.pa, > but load-module for the sink didn't work even when I tried it > without any options. "Didn't work"? How so? 48 is a pretty small wtermark. > > BTW, I'm often getting: > [pulseaudio] alsa-util.c: snd_pcm_avail_update() returned a valu > e that is exceptionally large: 229216 bytes (1193 ms) Most likely this > is an ALSA driver bug. Please report this issue to the PulseAudio > developers. That means that there is probably some issue with your ALSA driver or your scheduler. The function snd_pcm_avail_update() tells us how many samples are ready for reading resp. writing. In your case at one time this value is exceptionally large, i.e. > 3 times the size of the hardware buffer. Which means that PA slept for much longer than it should or there is something seriously wrong with the timing information your driver returns. PA uses the timing information the ALSA driver exports to estimate when it needs to wake up. In your case this calculation went wrong, presumably because the ALSA data was bogus -- or the wakeup time was calculated correctly but but due to some other reasons PA didn't get woken up in that time, possibly because some other app put some high load on the CPU or the scheduler went nuts. Or things got calculated correctly but then the data when we check the results is invalid. There should be discontinuities in sound when this happens. Are there? Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4
