0.5 ms is just what PA reports as the minimal latency. I don't need it
to be this small, I just don't want it to grow up to 100 ms without the
possibility to automatically drop it back to normal. I suppose it's not
possible to make PA work with fragments as ALSA does. As I understand
from the Lennart's article, the latency in ALSA is the size of period
±something. For PA it's the size of fragment * number of fragments as it
reports this as the minimal latency in pacmd list-sinks. It's also very
noticeable when you use realtime apps like LMMS or games.
However, it's not true for dmix. I play a file with everything at
default on my home PC with SB Live 7.1 (at work the overall picture is
more or less the same), here's what I have:
> 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 : 8192
period_size : 1024
period_time : 21333
tstamp_mode : NONE
period_step : 1
avail_min : 1024
period_event : 0
start_threshold : 8192
stop_threshold : 8192
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 : 8192
period_size : 1024
period_time : 21333
tstamp_mode : NONE
period_step : 1
avail_min : 1024
period_event : 0
start_threshold : 8192
stop_threshold : 8192
silence_threshold: 0
silence_size : 0
boundary : 4611686018427387904
Hardware PCM card 0 'CA0106' 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 : 8192
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
The buffer size is 8192 frames which is8192 / 48000 == 0.17066 s == 170
ms but there's no noticeable latency at all. If I setup PA not to use
tsched and set 8 fragments of 21 ms each (almost exactly as in dmix), I
have this setup then:
Apr 16 19:16:17 homecomp pulseaudio[6121]: [pulseaudio] alsa-util.c: Hardware
PCM card 0 'CA0106' device 0 subdevice 0
Apr 16 19:16:17 homecomp pulseaudio[6121]: [pulseaudio] alsa-util.c: Its setup
is:
Apr 16 19:16:17 homecomp pulseaudio[6121]: [pulseaudio] alsa-util.c: stream
: PLAYBACK
Apr 16 19:16:17 homecomp pulseaudio[6121]: [pulseaudio] alsa-util.c: access
: MMAP_INTERLEAVED
Apr 16 19:16:17 homecomp pulseaudio[6121]: [pulseaudio] alsa-util.c: format
: S32_LE
Apr 16 19:16:17 homecomp pulseaudio[6121]: [pulseaudio] alsa-util.c:
subformat : STD
Apr 16 19:16:17 homecomp pulseaudio[6121]: [pulseaudio] alsa-util.c: channels
: 2
Apr 16 19:16:17 homecomp pulseaudio[6121]: [pulseaudio] alsa-util.c: rate
: 48000
Apr 16 19:16:17 homecomp pulseaudio[6121]: [pulseaudio] alsa-util.c: exact
rate : 48000 (48000/1)
Apr 16 19:16:17 homecomp pulseaudio[6121]: [pulseaudio] alsa-util.c: msbits
: 32
Apr 16 19:16:17 homecomp pulseaudio[6121]: [pulseaudio] alsa-util.c:
buffer_size : 8064
Apr 16 19:16:17 homecomp pulseaudio[6121]: [pulseaudio] alsa-util.c:
period_size : 1008
Apr 16 19:16:17 homecomp pulseaudio[6121]: [pulseaudio] alsa-util.c:
period_time : 21000
Apr 16 19:16:17 homecomp pulseaudio[6121]: [pulseaudio] alsa-util.c:
tstamp_mode : ENABLE
Apr 16 19:16:17 homecomp pulseaudio[6121]: [pulseaudio] alsa-util.c:
period_step : 1
Apr 16 19:16:17 homecomp pulseaudio[6121]: [pulseaudio] alsa-util.c:
avail_min : 1008
Apr 16 19:16:17 homecomp pulseaudio[6121]: [pulseaudio] alsa-util.c:
period_event : 1
Apr 16 19:16:17 homecomp pulseaudio[6121]: [pulseaudio] alsa-util.c:
start_threshold : -1
Apr 16 19:16:17 homecomp pulseaudio[6121]: [pulseaudio] alsa-util.c:
stop_threshold : 9079256848778919936
Apr 16 19:16:17 homecomp pulseaudio[6121]: [pulseaudio] alsa-util.c:
silence_threshold: 0
Apr 16 19:16:17 homecomp pulseaudio[6121]: [pulseaudio] alsa-util.c:
silence_size : 0
Apr 16 19:16:17 homecomp pulseaudio[6121]: [pulseaudio] alsa-util.c: boundary
: 9079256848778919936
Apr 16 19:16:17 homecomp pulseaudio[6121]: [pulseaudio] alsa-util.c: appl_ptr
: 0
Apr 16 19:16:17 homecomp pulseaudio[6121]: [pulseaudio] alsa-util.c: hw_ptr
: 0
The point is, while the configuration looks the same the latency is
huge, it's exactly 168 ms and is just unbearable. That's what happens
after some really bad PC slowdowns because of the workload and it
happens for every app and there's no way to make it behave properly
without restarting PA and everything else. So why PA doesn't work as
dmix does? Why dmix has 168ms buffer and responds instantly like there's
no perceptible latency? Why dmix never underruns (at least audibly)
while PA does it pretty often on a range of chipsets? I would be pretty
happy with 21 ms fixed latency that never underruns but I just can't
setup PA to work like this.
Please, Raymond, don't go into the details, like, this particular card
isn't Intel HDA the period size in PA is slightly less (1008 vs 1024)
and so on. I see it clearly, that's not important here. What's important
is the fact that dmix does its job much better than PA in any
configuration (negligible latency + no underruns) and I want to know why
and how to make PA work like dmix in this regard.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/996906
Title:
periodic audio skips with Intel HDA
To manage notifications about this bug go to:
https://bugs.launchpad.net/pulseaudio/+bug/996906/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
