Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Uses unexpected level of CPU while idle #567

Closed
mdekstrand opened this issue Jan 18, 2021 · 10 comments
Closed

Uses unexpected level of CPU while idle #567

mdekstrand opened this issue Jan 18, 2021 · 10 comments
Labels

Comments

@mdekstrand
Copy link

I am noticing an unexpectedly high level of CPU usage in librespot while it is idle. This is with Librespot 0.1.3 built in release mode with the Rodio backend (from the Alpine package).

On my Raspberry Pi Zero W, with a single-core 1GHz ARM processor (Broadcom 2835, ARMv6 ISA) and a HiFiBerry DAC Zero hat, the librespot process is constantly using 12-14% CPU. An strace indicates that it's receiving messages from various machines on the local LAN, but not a large number of them (one ever 5 seconds or so). During playback CPU usage is about 30%.

I don't know what is going on with this, but it doesn't seem like an idle music player should use so much CPU.

@ashthespy
Copy link
Member

Could you confirm if you see a reduction when using the ALSA back end directly? IIRC, Rodio has some overhead, that becomes noticeable on less powerful devices.

@mdekstrand
Copy link
Author

I'll try that. If it does reduce overhead, would you recommend building the Alpine package with the ALSA backend across the board? That's the package build script did before I took it over, but it was building a git snapshot from 2018.

@ashthespy
Copy link
Member

Some more context #277 (comment)
The ALSA back-end is quite a bare bones, but if it serves your purpose, then go for it ;-)

@mdekstrand
Copy link
Author

I have rebuilt with the Alsa backend and confirmed that it idles without CPU. It looks like RustAudio/rodio#299 may be the relevant Rodio issue tracking this.

On the package build: I've taken over maintaining the package in the Alpine testing repos, and would like to provide a generally-useful build for Alpine users generally. It seems that at least on the armhf architecture, LibreSpot will usually be running on low-power machines, and so the alsa build might be useful default. I'm going to also ping on an Alpine support channel for suggestions, but as upstream if you've got recommendations for downstream packaging I'm open to the input.

I see a few options:

  1. Continue to build with default, low-power machine users have extra CPU consumption.
  2. Build with ALSA backend on all architectures.
  3. Build with ALSA backend on architectures with a high prevalence of low-power machines (armhf, possibly armv7 and x86). I don't know if the Alpine devs like this kind of variation or not - this is my first Alpine package.
  4. Build librespot with multiple backends as subpackages (librespot-alsa, librespot-pulseaudio, etc.).

@ashthespy
Copy link
Member

You could always build in both back-ends, and let users choose?

@mdekstrand
Copy link
Author

Thanks! Didn't realize that was possible. Will give it a try.

@mdekstrand
Copy link
Author

Since the root cause of this seems to be a Rodio issue, I am fine with this issue being closed if that's what project maintainers want to do. Not closing it myself in case you want to leave it open to check librespot's cpu usage after rodio addresses the problem (if they do).

@sashahilton00
Copy link
Member

Looking over that issue, rodeo appears to return a Sink in most instances, so it might be possible for librespot to drop the sink after playback concludes. I may be wrong, but I thought someone implemented this feature a while back where the sink was deliberately kept open to prevent clicking when the sink was opened/closed. If so, it might be possible to add a runtime flag to close the sink after playback or keep it open depending on what the user wants.

@ashthespy
Copy link
Member

ashthespy commented Jan 26, 2021

If my foggy memory serves me right, @willstott101 was also exploring ditching Rodio, and using cpal directly..

EDIT: bingo! #317 (comment)

@roderickvd
Copy link
Member

We're seriously considering switching from Rodio to cpal, with some initial code already proposed. For now I'll be closing this issue. The buffering on Rodio-on-Alsa is indeed not so great, so better to use the direct alsa backend.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants