[pulseaudio-discuss] Skips and latency issues on VIA VT1708S

[Alexander E. Patrakov]

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