terminator356
commented
1 year ago Hi. Question: Is latency correction enabled in the Settings? One drawback of this feature at the moment: I blindly calculate the latency of "everything" upon every audio cycle, which is a heavy task to be doing each cycle, especially with many tracks. I noted in my code that an improvement would be to only re-calculate the latency when something changes, ie when some controller changes which might affect latency.
Beyond that, some other things that might slow down the audio cycle processing: 1) We don't take advantage of SSE and so on. Our 'block move' and 'block multiply' functions etc. might benefit from that. Yes we have some code in there which can do SSE but we don't use it because the code is very old and in need of a modern update. 2) Some of the LV2 code is a bit heavy, could be improved, but LV2 is a beast... 3) All our processing takes place in one core. We should try to use thread affinity functions and so on. Modern techniques.
drautzburg
onefang
The problem
Recently I started a project, using jackd and firewire. I started with with 64 frames/period (4ms latency), then as the project grew, I upped it to 128 and finally 256. In the end the project had apx.
In an attempt to reproduce #1105 I tortured the system with 64 again. I got tons of xruns and bad audio as expected.
But my CPU% remained well below 20% at all times i.e. 4/5 of my CPU power remained unused. This was on an i7-8700K with 6/12 cores running at 4400 MHz.
Why this matters
This is not an entirely academic issue. 256 frames/period means 17 ms latency (at 44100Hz). This is perfectly acceptable. It is only 1/8 of a sixteenth note at 120 BPM.
But projects can be bigger, with more tracks, more plugins and more softsynths. I may eventually run into problems during recording, to the extent that I have to disable plugins and tracks, to keep the latency within acceptable bounds. If I was able to use 100% of CPU, the limits would be pushed by a factor of 5.
During playback/mixing, latency isn't much of an issue.
What I tried
I went through the trouble of rearranging interrupt handler priorities, realtime priorities and CPU governor settings. This felt like a small improvement , but not by much. Particularly CPU usage remained below 20%.
Conclusion
I pointed this out to @spamatica an he commented:
I understand that this will require some deep thinking and some thorough analyses before even thinking about changing the code. After all, concurrency is one of those problems that always turn out more difficult than expected.