# Steps to reproduce: 1. Run a soundtrack in VLC 2. Disable sound in VLC, or alternatively lower it to 0 3. Run `top`, and check CPU-load of pulseaudio # Expected results: You should see almost the same usage as if pulseaudio was idle # Actual results: Pulseaudio loads CPU around ≈4-5%. # Real-world significancy: Initially I found the problem for figuring out why pulseaudio loads CPU to 10% (not even 5% as with VLC!) when I ain't play anything. Pavucontrol shows that no apps are using sound. Long story short, I went as far as to disable pulseaudio, and then noted something funny in `top`: one Qutebrowser tab been loading my CPU to 2-3%. I immediately figured it out: it's a crappy "freelancer.com" site, no surprise. After it's closed, the again enabled pulseudio does not load my CPU anymore. I think they maybe play some static noise at 0 sound. Pulseaudio surely can detect it, because I do not see at pavucontrol's "audio usage" line any jumps. Other applications: speech-dispatcher streams might be doing something alike https://bbs.archlinux.org/viewtopic.php?id=222857 I also found this Ubuntu bug https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/207135 despite tagged "fix released", peoples keep complaining. My guess it might be related.
Oh, well, about the launchpad link — I just noticed the title is about other usecase. Nvm, I've found it because there're many people's complaints specifically about idle CPU usage.
Thanks for the improvement idea. PulseAudio can't stop the stream when it's playing silence, because that would make it impossible to provide accurate latency information, which many applications depend on. Skipping the heavy parts of resampling is something that could probably reasonably be done. It seems that currently full resampling is done even when the stream is muted at the pulseaudio end, so some optimization could be done even without monitoring the stream data in pulseaudio. Monitoring the stream data requires inspecting every sample, which causes some overhead, so I wouldn't enable that feature by default. Implementing this feature does not have high priority on my todo list, so patches will have to come from somebody else.
> PulseAudio can't stop the stream when it's playing silence, because that would > make it impossible to provide accurate latency information, which many > applications depend on I'm not familiar with internals, but, is it a kind of information that always the same for playing silence and hence can be faked without any loss in accuracy?
The latency information is partly provided by the hardware, and the hardware can only provide that information when it's running. The information can't be faked. The fake latency would have to include the time that it takes for the device to be opened if it's suspended, and that time is now knowable. Imagine playing a video with some silent parts. If PulseAudio stops streaming to the hardware, then the hardware needs to be opened when the silent part ends, and that will take some time. That very likely causes glitches in the video playback.
@Tanu Kaskinen thank you. I decided to take a quick look today. I profiled with callgrind (btw, attaching in case anybody else is interested) for running a game for a bit; turns out most of the time is spent at the bottom of this loop https://github.com/pulseaudio/pulseaudio/blob/d9624e0382aabc106252e3a39665293e72ed08bb/src/modules/alsa/alsa-sink.c#L654 functions pa_sink_render_into_full(29.47% including children) and snd_pcm_mmap_commit(10.15% including children). I am however completely unfamiliar with pulseaudio in particular and audio processing in general, can you tell what's going on there? And how would I go about getting sound level — both configured (i.e. "whether a user muted sound") and one of the stream (i.e. "whether stream is playing silence?").
Created attachment 136359 [details] callgrind record on pulseaudio. Note: by accident a few modules don't have debug symbols.
-- 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/472.
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.