Topic: Linux: Audio Cracks but CPU not at 100% load
Hey,
because of User Groove On and his fabulous idea of using the TASKSET command in Linux (check https://forum.modartt.com/viewtopic.php...3#p974513) I came in contact with optimizing PTQs performance index and the audio load.
As mentioned in two of my posts, https://forum.modartt.com/viewtopic.php...26#p988126 and https://forum.modartt.com/viewtopic.php...60#p988860 I do suffer audio cracks with my desired settings of 32bit/48kHz(Stage Version)/128 Buffer Size/256 Polyphony.
Ive tried all kinds of optimization, like using a lowlatency Kernel, 1000Hz Clock Rate, PipeWire + WirePlumber as Audio Driver/Server,
the mentioned taskset limit to different CPU Cores - trying 4-6 physical and HT core combinations,
fixing the upper/lower clock speed with Intels P-State Governors of the Intel i5-82650U CPU,
and setting PTQ to Multicore Rendering MAX and disabling the CPU overload detection.
Still, I suffered audio cracks when causing a high Polyphone load,
which is why I worked around and set my Polyphony in PTQ pretty low (48) to lower the CPU usage and not suffer any audio cracks.
This workaround does the trick, but I wasnt satisfied with the solution for obvious reasons!
Because of that my best guess was that the CPU is maybe switching clock speeds to a lower value while PTQ runs and does not react quick enough when the workload goes up again, which is why I even changed from Intel P-State and its governor to the P-State passive mode which enables the use of ACPI and its governors, like userspace, to really fix the CPU clock frequency on point.
But even than, running at the max. CPU clock speed, and using 6 of 8 Kernels, PTQ always plotted me that the audio load is higher than my performance index whenever I tested setting Polyphony higher than 48. Obviously I only had a few issues with lower Polyphonys count but a lot of overload "red lines" when causing actual 256 Polyphones.
Contradictory to that, the read out values of the workload of the CPU with other tools like SysMonitor showed, that the CPU load was actually quite low: 60% usage at max. clock speed when playing a file that causes 256 Polyphony. Yet, the audio load still exceeded the performance index - which I have troubles to understand why.
A suggestion by ChatGPT was to check IRQ handles: But the workload is shared equally between the cores, so that aint the issue.
I havent tried disabling the ondemand service, or disabling other power management features yet to enforce even harder that the CPU is not changing its clock speed, but it seems unlikely to me that my idea of the CPU freq. changing is the actual cause why my performance index is max'ed out while the workload of the CPU is not.
That was the moment when I have just noticed that changing the Buffer size got alot of impact: Which makes sense, as we lower the workload again.
Previously all my tests have been performed with PTQ set to 32bit/48kHz/128 samples, because I favored the lower latency of 2.7ms.
Now I started to see, that setting a sample size of 256 allows for only occasional overloads when running actual tests with 256 Polyphones, further, setting a sample size of 512 seems to never cause an overload any longer when causing and actual load of 256 Polyphones.
Somehow thats already a nice step forward, because at least the system is capable of performing the desired Polyphones.
Yet, I am not satisfied:
I struggle to see why the performance index is "quite low" while tools to read the CPU load claim the CPU cores are not anywhere close to 90% load, most of the time its more like 60% load!
That is why I share my experience and like to ask if you had similar encounters, and have an explanation and maybe a solution for it?
Fact is, I do have audible cracks with a lower buffer size and 256 Polyphony. Fact is PTQ states the audio load (yellow graph) is higher than the performance index (blue dots).
So PTQ actually is right - but my system is telling me somehow otherwise: There should be power reserves of the CPU available for PTQ to use, but it just doesnt use it!
I know alot of factors and underlying features, on the software level, the kernel software level, the chipset level and the CPU internal level, can cause the CPU to actually throttle down, but it does not seem that is the case:
The CPU is running cool (Ive stress tested the CPU with stress-ng and reach way higher temps that come close to the max temp of 80°C than the temps that PTQ cause when running the 256 Polyphone MIDI files with a low buffer size) and the desired max. clock speed runs continuously without an issue even at 100% CPU load. I even considered that the actual possible max. clock speed for all cores is lower than advertised: While a single core can go up to 3.9GHz for this CPU, all 8 cores can not exceed 2.4GHz due to thermal/TDP/firmware management. So I base my load on the 2.4GHz, and not even the "misleading" 3.9Ghz that are displayed when using f.e. the performance governor but not causing actual workload.
My conclusion is, that the CPU is not limited (thermal limitations, clock speed limitations, ...).
Obviously, my RAM load and Disk I/O when running PTQ are far below their maximum capabilities and dont cause any bottleneck.
Further: I expect this to become worse! As soon as I could raise the sample rate to 192kHz with a different version of PTQ, the workload would increase again. But I do feel like I need to get another PTQ version to allow me for a higher sample rate, because the buffer size of 512 is equal to ~10.7ms latency which I assume is too much to have a responsive keyboard with factoring in all the other delays (MIDI Input delay, Sound output).
Which again brings me to the beginning:
Why do I suffer audio cracks when enhancing the workload, like by lowering the buffer size - it is a fact that I overload the system, but why can I not confirm this anywhere else than in PTQ as everything else states the CPU could perform more?
I dont expect PTQ to spare some potential available resources. But to the same it seems like there are more resources available by the system that are not used.
That is why I appreciate all kinds of input of you that I might should consider, check, or test.
Additionally, I like to know your Buffer Size, Sample Rate, Bit Depth, Polyphony, used CPU, CPU workload and Performance Index with info if you ever encounter overloads?
Thank you
