17.04.2015 11:17, Sergey Shpikin пиÑ?еÑ?: > On my not-so-mighty system (Intel G620) I have underruns from time to > time. As a direct result of that the latency increases. If some > program has chosen a small latency and had underruns because of CPU > load the Pulseaudio server may increase the latency to 100+ ms which > is applied to every program and worst of all, it's never decreased. > The only way is to restart PA and all its clients. Our bug discussion > ( https://bugs.freedesktop.org/show_bug.cgi?id=49608 ) has come to > nowhere as it seems that no PA developers are interested in this. So I > decided to post here. I have looked at the bugzilla entry. So far, in the comment #28, I see underruns even on hw devices. Still, I think that even on your system, on hw devices, latencies as low as 1 ms should be possible without any underruns. When triaging such bugs, I would normally ask to run latencytop and get the report. Unfortunately, on some distributions, it requires a custom kernel due to CONFIG_LATENCYTOP. It can't hurt to run latencytop in your case, too, but you have already done an even better debugging job - see below. > My question is, why dmix works flawlessly on this system while PA skips? The dmix setup relies on two things: 1. A fixed period size (1024 frames) that seems to me mostly OK with your board. 2. More than two periods, so that even an occasional lost interrupt does not lead to an underrun. The second opint is what you have an issue with - see "Lost interrupts" in comment #28. PulseAudio, by default, does not use periods at all, and instead relies on 100% reliable system timer interrupts. Since your system loses audio interrupts, I guess that it can lose timer interrupts, too. To work around unreliable interrupts, please do the following: 1. In /etc/pulse/daemon.conf, set: default-fragment-size-msec = 12 default-fragments = 4 This should be enough to work around two consecutive lost interrupts, and gives a fixed 48 ms latency (same as dmix in its default configuration). 2. In /etc/pulse/default.pa, find the line about module-udev-detect, and modify it as follows: load-module module-udev-detect tsched=no This is necessary so that actual audio interrupts are used instead of the timer interrupts, and for the abovementioned settings from daemon.conf to actually have any effect. But, well, according to the bugzilla entry, you have already done something like this. As for the formula for dmix latency, the trick is that it does not use all the periods that you want it to use. It uses only two periods if that's needed to satisfy the application's latency request. PulseAudio always uses all periods that you tell it to use. The real problem with your bugzilla entry and the mailing list post is that they are not the correct place for your bug. It is not a PulseAudio bug, that's why you had no useful feedback from PulseAudio developers. It is a kernel bug that should be reported to the kernel bugzilla, where there are much more people familiar with interrupt setup details of your board. The key words to use when filing it are "lost interrupts", and, of course, feel free to add a link to your freedesktop bug. -- Alexander E. Patrakov
