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>
