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.