[pulseaudio-discuss] cracks and pops with intelHDA
lennart at poettering.net
Sun Jan 13 06:27:48 PST 2008
On Sun, 13.01.08 11:43, 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
> How about assigning the main thread or all threads SCHED_RR?
When PA starts up it will try to acquire a negative nice level (-11),
and then drop the capability to decrease the nice level any
further. The RT threads then each acquire SCHED_FIFO.
>>> 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).
In all released version of PA hrtimers are not really that
important. This will change with 0.9.9, however.
hrtimers are only available on x86 for (not even amd64) in very recent
kernels. The .config option is CONFIG_HIGH_RES_TIMERS=y.
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
More information about the pulseaudio-discuss