| Summary: | Feature request: do not resample nor output sound with 0 usage | ||
|---|---|---|---|
| Product: | PulseAudio | Reporter: | Hi-Angel <Hi-Angel> |
| Component: | daemon | Assignee: | pulseaudio-bugs |
| Status: | RESOLVED MOVED | 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: | callgrind record on pulseaudio. Note: by accident a few modules don't have debug symbols. | ||
|
Description
Hi-Angel
2017-11-04 07:46:07 UTC
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.