[pulseaudio-discuss] Skips and latency issues on VIA VT1708S
Alexander E. Patrakov
patrakov at gmail.com
Fri Apr 17 01:50:18 PDT 2015
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
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
More information about the pulseaudio-discuss