[GH-ISSUE #567] Uses unexpected level of CPU while idle

kerem commented

2026-02-27 19:30:13 +03:00

Owner

Originally created by @mdekstrand on GitHub (Jan 18, 2021).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/567

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.

Originally created by @mdekstrand on GitHub (Jan 18, 2021). Original GitHub issue: https://github.com/librespot-org/librespot/issues/567 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](https://pkgs.alpinelinux.org/packages?name=librespot&branch=edge)). 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.

kerem

2026-02-27 19:30:13 +03:00

closed this issue
added the
bug
label

kerem commented

2026-02-27 19:30:14 +03:00

Author

Owner

@ashthespy commented on GitHub (Jan 18, 2021):

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.

@ashthespy commented on GitHub (Jan 18, 2021): 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.

kerem commented

2026-02-27 19:30:14 +03:00

Author

Owner

@mdekstrand commented on GitHub (Jan 18, 2021):

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.

@mdekstrand commented on GitHub (Jan 18, 2021): 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.

kerem commented

2026-02-27 19:30:14 +03:00

Author

Owner

@ashthespy commented on GitHub (Jan 20, 2021):

Some more context https://github.com/librespot-org/librespot/pull/277#issuecomment-473614497
The ALSA back-end is quite a bare bones, but if it serves your purpose, then go for it ;-)

@ashthespy commented on GitHub (Jan 20, 2021): Some more context https://github.com/librespot-org/librespot/pull/277#issuecomment-473614497 The ALSA back-end is quite a bare bones, but if it serves your purpose, then go for it ;-)

kerem commented

2026-02-27 19:30:14 +03:00

Author

Owner

@mdekstrand commented on GitHub (Jan 21, 2021):

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:

Continue to build with default, low-power machine users have extra CPU consumption.
Build with ALSA backend on all architectures.
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.
Build librespot with multiple backends as subpackages (librespot-alsa, librespot-pulseaudio, etc.).

@mdekstrand commented on GitHub (Jan 21, 2021): 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.).

kerem commented

2026-02-27 19:30:14 +03:00

Author

Owner

@ashthespy commented on GitHub (Jan 21, 2021):

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

@ashthespy commented on GitHub (Jan 21, 2021): You could always build in both back-ends, and let users choose?

kerem commented

2026-02-27 19:30:14 +03:00

Author

Owner

@mdekstrand commented on GitHub (Jan 21, 2021):

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

@mdekstrand commented on GitHub (Jan 21, 2021): Thanks! Didn't realize that was possible. Will give it a try.

kerem commented

2026-02-27 19:30:14 +03:00

Author

Owner

@mdekstrand commented on GitHub (Jan 26, 2021):

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).

@mdekstrand commented on GitHub (Jan 26, 2021): 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).

kerem commented

2026-02-27 19:30:14 +03:00

Author

Owner

@sashahilton00 commented on GitHub (Jan 26, 2021):

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.

@sashahilton00 commented on GitHub (Jan 26, 2021): 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.

kerem commented

2026-02-27 19:30:14 +03:00

Author

Owner

@ashthespy commented on GitHub (Jan 26, 2021):

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

EDIT: bingo! https://github.com/librespot-org/librespot/issues/317#issuecomment-529198164

@ashthespy commented on GitHub (Jan 26, 2021): If my foggy memory serves me right, @willstott101 was also exploring ditching Rodio, and using `cpal` directly.. EDIT: bingo! https://github.com/librespot-org/librespot/issues/317#issuecomment-529198164

kerem commented

2026-02-27 19:30:14 +03:00

Author

Owner

@roderickvd commented on GitHub (May 24, 2021):

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.

@roderickvd commented on GitHub (May 24, 2021): 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.

Rows
Columns

[GH-ISSUE #567] Uses unexpected level of CPU while idle #362