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

[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.

My question is, why dmix works flawlessly on this system while PA skips? I
have this ALSA setup when using dmix:

> aplay -v /usr/share/sounds/alsa/Front_Center.wav
Playing WAVE '/usr/share/sounds/alsa/Front_Center.wav' : Signed 16 bit
Little Endian, Rate 48000 Hz, Mono
Plug PCM: Route conversion PCM (sformat=S32_LE)
  Transformation table:
    0 <- 0
    1 <- 0
Its setup is:
  stream       : PLAYBACK
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 1
  rate         : 48000
  exact rate   : 48000 (48000/1)
  msbits       : 16
  buffer_size  : 16384
  period_size  : 1024
  period_time  : 21333
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 1024
  period_event : 0
  start_threshold  : 16384
  stop_threshold   : 16384
  silence_threshold: 0
  silence_size : 0
  boundary     : 4611686018427387904
Slave: Soft volume PCM
Control: PCM Playback Volume
min_dB: -51
max_dB: 0
resolution: 256
Its setup is:
  stream       : PLAYBACK
  access       : MMAP_INTERLEAVED
  format       : S32_LE
  subformat    : STD
  channels     : 2
  rate         : 48000
  exact rate   : 48000 (48000/1)
  msbits       : 32
  buffer_size  : 16384
  period_size  : 1024
  period_time  : 21333
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 1024
  period_event : 0
  start_threshold  : 16384
  stop_threshold   : 16384
  silence_threshold: 0
  silence_size : 0
  boundary     : 4611686018427387904
Slave: Direct Stream Mixing PCM
Its setup is:
  stream       : PLAYBACK
  access       : MMAP_INTERLEAVED
  format       : S32_LE
  subformat    : STD
  channels     : 2
  rate         : 48000
  exact rate   : 48000 (48000/1)
  msbits       : 32
  buffer_size  : 16384
  period_size  : 1024
  period_time  : 21333
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 1024
  period_event : 0
  start_threshold  : 16384
  stop_threshold   : 16384
  silence_threshold: 0
  silence_size : 0
  boundary     : 4611686018427387904
Hardware PCM card 0 'HDA Intel PCH' device 0 subdevice 0
Its setup is:
  stream       : PLAYBACK
  access       : MMAP_INTERLEAVED
  format       : S32_LE
  subformat    : STD
  channels     : 2
  rate         : 48000
  exact rate   : 48000 (48000/1)
  msbits       : 32
  buffer_size  : 16384
  period_size  : 1024
  period_time  : 21333
  tstamp_mode  : ENABLE
  period_step  : 1
  avail_min    : 1024
  period_event : 0
  start_threshold  : 1
  stop_threshold   : 4611686018427387904
  silence_threshold: 0
  silence_size : 4611686018427387904
  boundary     : 4611686018427387904
  appl_ptr     : 0
  hw_ptr       : 0

16 periods, 21.3 ms each, it results in 341 ms. Yet there's no audible
latency which makes me think that dmix's latency is approximately equals
the period size, i.e. 21 ms. If I setup Pulseaudio so it uses the same
configuration (tsched=0, fragment size=21, fragments=16) the latency equals
the whole buffer size, 336 ms as reported by pacmd list-sinks and
noticeable well in LMMS. It is unacceptable of course.  So is there a way
to make PA work just like dmix, with the fixed latency of 21 ms or alike
and without skips at the same time? With PA's interrupt-driven model I can
get either bad latency with presumably no skips or good latency and
underruns from time to time. With the new timer-based scheduling I have
both skips and growing latency up to 168 ms or something like this in the
end of the working day.

Another question is about pavucontrol. I usually listen to music in Chrome
streaming from grooveshark, it uses HTML5 Audio. When I launch pavucontrol
the first time, the playback skips pretty badly and the latency increases.
The same sometimes happens when I launch pacmd list-sinks. No way these
tools occupy so much CPU that Chrome can't sink audio to the server. It's
like they block somewhere in the server and it can't accept audio from the
outside. This doesn't happen when launching any other app except LMMS which
also makes Chrome skip (if tsched=0) or produce garbled sound for a while
(if tsched is not defined, i.e. =1) after which PA recovers.

Many internal details are provided in the bug I mentioned before so you can
check I've tried pretty many things to make it work, including EFI update
and various snd-hda-intel module options. I also have to note that all of
this is not the issue on my home PC which is quite faster, i7-2600 with PCI
SB Live 7.1. I use preemptive kernels on both machines, compiled from the
patched pf source (pf-kernel). With the stock Debian kernel the matters are
even worse and I had underruns on the home PC as well.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20150417/36bbbb13/attachment.html>