starred/librespot

Fork 0

mirror of https://github.com/librespot-org/librespot.git synced 2026-04-27 08:15:50 +03:00

[GH-ISSUE #554] recent version of librespot 70% CPU during playback to named pipe where old version used 3% #352

New issue

Closed

opened 2026-02-27 19:30:10 +03:00 by kerem · 2 comments

kerem commented

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

Owner

Originally created by @mikeszila on GitHub (Dec 21, 2020).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/554

This is the first issue report I've ever written on git. Please let me know if I'm missing anything.

A version of librespot I compiled last year uses under 3% CPU during playback. I recompiled the current version and it now uses 70% CPU during playback. I put the old version back and it's back down to 3%. Both on the same Raspberry Pi 4B running Raspbian Buster and kernel 4.19.75-v7l+. In my application librespot writes to a named pipe which is read at approximately playback speed by an application I've written in nodejs. Even with high CPU everything sounds OK except for some skips and stutters probably caused by the high CPU.

The old commit with low CPU from last year was: github.com/librespot-org/librespot@cbba63f60b

The new commit with high CPU from a few days ago is: github.com/librespot-org/librespot@0adb8516a6.

My reason for re-compiling is a slight modification to get the current volume setting and prevent softvolume adjustments from being applied to the audio. Both last years and the current version had this change. I doubt this has anything to do with the high CPU but it's included for completeness. The change can be seen here: https://github.com/mikeszila/librespot

I followed the instructions here and ran "cargo build --no-default-features".

I run librespot with this command: ./librespot -v -n hello -b 320 -c /home/pi/audio/local/librespot --enable-volume-normalisation --backend pipe --device /home/pi/audio/local/librespot/audiofifo

I read data from the pipe in chunks at approximately playback speed. I tried reading a bunch of different chunk sizes including 441, 882, 512, 1024, 2048 samples at a time. No real change.

Thanks for any help you can give.

Originally created by @mikeszila on GitHub (Dec 21, 2020). Original GitHub issue: https://github.com/librespot-org/librespot/issues/554 This is the first issue report I've ever written on git. Please let me know if I'm missing anything. A version of librespot I compiled last year uses under 3% CPU during playback. I recompiled the current version and it now uses 70% CPU during playback. I put the old version back and it's back down to 3%. Both on the same Raspberry Pi 4B running Raspbian Buster and kernel 4.19.75-v7l+. In my application librespot writes to a named pipe which is read at approximately playback speed by an application I've written in nodejs. Even with high CPU everything sounds OK except for some skips and stutters probably caused by the high CPU. The old commit with low CPU from last year was: https://github.com/librespot-org/librespot/commit/cbba63f60baef6c812a82903a0e0735688056d3c The new commit with high CPU from a few days ago is: https://github.com/librespot-org/librespot/commit/0adb8516a65f551211a9ce78c2d822b85454546c. My reason for re-compiling is a slight modification to get the current volume setting and prevent softvolume adjustments from being applied to the audio. Both last years and the current version had this change. I doubt this has anything to do with the high CPU but it's included for completeness. The change can be seen here: https://github.com/mikeszila/librespot I followed the instructions here and ran "cargo build --no-default-features". I run librespot with this command: ./librespot -v -n hello -b 320 -c /home/pi/audio/local/librespot --enable-volume-normalisation --backend pipe --device /home/pi/audio/local/librespot/audiofifo I read data from the pipe in chunks at approximately playback speed. I tried reading a bunch of different chunk sizes including 441, 882, 512, 1024, 2048 samples at a time. No real change. Thanks for any help you can give.

kerem closed this issue

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

kerem commented

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

Author

Owner

@michaelherger commented on GitHub (Dec 21, 2020):

In my experience using --release or not can make a huge difference. By default the binary is built in dev mode, which compiles fast, but runs slow.

@michaelherger commented on GitHub (Dec 21, 2020): In my experience using `--release` or not can make a huge difference. By default the binary is built in `dev` mode, which compiles fast, but runs slow.

kerem commented

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

Author

Owner

@mikeszila commented on GitHub (Dec 23, 2020):

In my experience using --release or not can make a huge difference. By default the binary is built in dev mode, which compiles fast, but runs slow.

not using --release was my issue. Thank you!!!

@mikeszila commented on GitHub (Dec 23, 2020): > In my experience using `--release` or not can make a huge difference. By default the binary is built in `dev` mode, which compiles fast, but runs slow. not using --release was my issue. Thank you!!!

kerem referenced this issue

2026-02-27 20:00:19 +03:00

[PR #352] [CLOSED] Rustfmt #885

kerem referenced this issue

2026-02-27 20:00:23 +03:00

[PR #388] [MERGED] Update Readme and Contributing to be more consistent #903

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/librespot#352

No description provided.

Rows
Columns