Bug 474743
Summary: | Pavucontrol uses excessive amounts of CPU when open. | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Nate <drag> |
Component: | pavucontrol | Assignee: | Lennart Poettering <lpoetter> |
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 10 | CC: | lpoetter, pierre-bugzilla |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-12-08 19:27:56 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Nate
2008-12-05 04:33:37 UTC
This only seems to happen when I am running two audio devices. On a single audio device pavucontrol seems very well behaved. When pavucontrol is running we try to show a volume meter for each stream and device. This volume meter should closely reflected what is is currently played/recorded, hence we activate low-latency settings for the specific device. Now, low-latency means high-CPU load. It's like the Heisenberg uncertainty principle. You cannot have both no CPU load and low latency. That doesn't make any sense at all. Why on earth does it make sense to have a volume control that requires so much low-latency for the purpose of providing visual feedback that causes such a high load on PulseAudio that causes Pulseaudio to kill itself!? It may not be a coding bug and may be done on purpose, but it seems to end up being a pretty bad design bug. Because this is what the end user would see: 1. End user plugs in USB audio card. They have read some of the (correct) propaganda about Pulse-Audio being able to effectively manage multiple devices and combined output, which is a attractive feature. 2. So the USB audio device is automatically detected and it's output is added as a option to PA. 3. The end user then installs pavucontrol since that is the only interface that allows for that sort of controls. 4. They fire up a few apps and the volume control and create a simultaneous output device and begins to enjoy the experience of easy high-quality sound output in Linux. 5. After a few moments all the sound stops. Some of the audio apps tend to hang. The volume control says it's lost it's connection. And that's about it. bingo. Dead sound. Why? Because the high-load caused PA to kill itself for eating to much cpu time. But this is entirely non-obvious and is confusing. The only want to figure out that the volume control caused PA to kill itself was to re-run the entire thing, but with PA running from a xterm so you can see the error codes. This is exactly what happened to me. Is this my fault for trying to run multiple outputs or something? Or maybe because I added myself to Pulse-RT or whatever? I mean, sure, if you have some sound visualization app or your trying to monitor levels for studio work or something like that then having low-latency visual feedback with high sample rates would be something that you'd want to have.. but the purpose of the volume control stuff is just a way to see the relative volumes and doesn't really need a very high sample rate or very low latency. That's what I figure anyways. I am not going to fight you on this or anything like that. I could be missing something entirely and is being entirely retarded about it. But what you said just sounds wrong. |