Lennart Poettering wrote: > On Mon, 07.01.08 17:59, Erik Slagter (erik at slagter.name) wrote: > While this is generally true, it's not really applicable to PA. In PA > every device has an RT thread. And then there is a global additional > "main" thread that does control and stuff like this, which is not RT, > but reniced. So, even if you enabled RT, you still need nice levels > for the main thread. Noted ;-) I assume the main thread tries to get a higher priority itself? How about assigning the main thread or all threads SCHED_RR? >> I have a similar problem in that a pulse stream plays for a few moments, >> starts to hiccup and then stops altogether. It doesn't matter which program >> I use. Using alsa directly there is no problem. On my other computer it >> works like expected, though. I have no need to use pulse anymore (it >> doesn't solve my problem) so my problem is gone ;-) > > Please paste the output of pulseaudio -vv when this happens for cases > like this. I'd like too, but I purged the setup :-( Anyway, talking about scheduling: I noticed that pulseaudio laughs in my face because it thinks I don't have high resolution timers enabled in kernel. Sadly it appears that in recent kernels this is no longer a configuration option, it seems to be enabled automatically though. This is a vanilla 2.6.23 kernel (tested .6,.12 and .13). -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3315 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20080113/8be6dff7/attachment.bin>
