Open tullo-x86 opened 4 years ago
It doesn't indeed. It's hardcoded to 4 threads.
https://github.com/DeaDBeeF-Player/deadbeef/blob/master/plugins/rg_scanner/rg_scanner.c#L269
It was done intentionally, because loading the whole CPU can make UI unresponsive, sound stuttering, etc.
It looks like that code reads from a settings object. The plugin doesn't appear to expose a UI to configure this value. Is there a command-line argument / environment variable I can use to override the default 0
?
It looks like that code reads from a settings object.
No edit: I mean, it's not the same settings which are read from file.
The plugin doesn't appear to expose a UI to configure this value. Is there a command-line argument / environment variable I can use to override the default 0?
No.
What mechanism is available to configure that settings object?
There's no such mechanism.
It's an internal settings object, not exposed to users. It exists to make it possible to add more features, such as user-configurable behavior, without breaking code interface. However, the user facing part has not been made (yet).
Steps to reproduce the problem
Note: The playlist this was measured against includes 1,019 tracks, using a variety of MP3, AAC, and FLAC encodings.
What's going on? Describe the problem in as much detail as possible.
Expected: ReplayGain scanner uses as much CPU time as possible Actual: ReplayGain scanner only manages to consistently peg 4 cores of a 6-core, 12-thread CPU (AMD Ryzen 3600X) Note: The spike in the middle of this graph represents me creating load manually
Information about the software:
Deadbeef version: v1.8.2 OS: Arch Linux (
Linux serotonin 5.5.10-arch1-1 #1 SMP PREEMPT Wed, 18 Mar 2020 08:40:35 +0000 x86_64 GNU/Linux
)