Summary: | combine-sink: Very high buffer latency (sometimes) | ||
---|---|---|---|
Product: | PulseAudio | Reporter: | Kristian Klausen <kristian> |
Component: | modules | Assignee: | pulseaudio-bugs |
Status: | RESOLVED MOVED | QA Contact: | pulseaudio-bugs |
Severity: | normal | ||
Priority: | medium | CC: | kristian, lennart |
Version: | unspecified | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
custom /usr/share/pulseaudio/alsa-mixer/profile-sets/default.conf
pactl list sink-input pacmd list-sinks Pulseaudio Debug log patch for alsa-sink.c, which give more information.. Pulseaudio Debug log with alsa-sink.patch and log-time true |
Description
Kristian Klausen
2016-12-11 21:54:37 UTC
Created attachment 128419 [details]
pactl list sink-input
Created attachment 128420 [details]
pacmd list-sinks
Created attachment 128421 [details]
Pulseaudio Debug log
Pulseaudio log (-vv) until issue happens and some time after..
As one of the log messages says, "most likely the audio timing in one of your drivers is broken", so this might not be a pulseaudio bug. The first HDMI sink is having underruns all the time, and when the first "total latency of output is very high" message is printed, the latency corresponds roughly to the time since the first underrun. My guess would be that the first HDMI sink is failing to consume almost any audio. The thread is not completely stuck, but I would guess that writing each chunk of audio takes way too long. Maybe it's the underrun recovery that's stalling? To get any kind of certainty about what is happening, you could add more logging to the alsa sink to see what is taking time. To avoid more spam in the log than necessary, the extra logging could be enabled only once an underrun has happened for at least a couple of times. I may have analysed the behaviour wrong. The situation is that the first HDMI sink, which is constantly underrunning, has a shorter buffer in module-combine-sink than the three other sinks. This would suggest that the first sink is actually consuming audio much faster than the three other sinks. Since the accumulated buffer size seems to grow roughly at the same rate as the system clock progresses (at least in the beginning), this can mean that either the first sink is running about twice the speed it should, or the three other sinks are more or less stopped. The first sink running too fast seems more likely. Created attachment 128442 [details] [review] patch for alsa-sink.c, which give more information.. before/after pa_sink_render_into_full and mmap_write Created attachment 128443 [details]
Pulseaudio Debug log with alsa-sink.patch and log-time true
Tanu Kaskinen: Can you get anything from this?
This time it's HDMI 2 that is having problems. mmap_write() is getting called much more often for that sink. Most of the time nothing is written, though (pa_sink_render_full() isn't being called). You could log u->write_count whenever something is written. Extra points for logging how much is expected to be written, based on the system clock. That should make it obvious if the write rate is too high or low. -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/70. |
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.