| Summary: | Sound intermittently repeats (due to underrun?) | ||
|---|---|---|---|
| Product: | PulseAudio | Reporter: | Zebediah Figura <z.figura12> |
| Component: | core | Assignee: | pulseaudio-bugs |
| Status: | RESOLVED NOTOURBUG | QA Contact: | pulseaudio-bugs |
| Severity: | normal | ||
| Priority: | medium | CC: | lennart |
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | output of "LANG=C pulseaudio -vvvv --log-time=1" | ||
There are scheduling delays of more than 300 ms. Probably some kernel driver is causing the glitches. My impression is that wireless drivers are especially prone to cause delays every few minutes, so you could try if the problem persists if you unload the wireless network driver. In any case, I believe this is a kernel bug. Disabling my wireless driver seems to have solved the problem. Many thanks. This doesn't seem like the kind of solution that would be universally applicable, though. Is it possible to amend PulseAudio to work around this bug? You can pass "tsched=no" to module-udev-detect in /etc/pulse/default.pa and set the "default-fragments" and/or "default-fragment-size-msec" options in /etc/pulse/daemon.conf high enough so that the high scheduling delays don't affect audio. The fragment options don't have any effect if tsched is enabled. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 131407 [details] output of "LANG=C pulseaudio -vvvv --log-time=1" Every so often (every few minutes or so?) a fraction of a second of sound will repeat itself from a few seconds before. This seems to happen in every application; I can't point out any single steps that cause or prevent it. I am running PulseAudio 10.0 (from repository), on Manjaro 4.9.27-1. I've attached a verbose log below. I first noticed a repeat at the 758 second mark. The output there suggests that this bug is caused by an underrun, and perhaps the rewind that subsequently occurs is too far?