muse-sequencer / muse

MusE is a digital audio workstation with support for both Audio and MIDI
https://muse-sequencer.github.io/
Other
657 stars 70 forks source link

Make MusE better in utilizing multiple cores #1108

Open drautzburg opened 1 year ago

drautzburg commented 1 year ago

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:

MusE could be better in utilizing multiple cores

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.

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 commented 1 year ago

No "enable latency correction" is not set.

In the "minimum control period" (=256) of any interest?

terminator356 commented 1 year ago

No, 256 is fine.

onefang commented 1 year ago

I have a 64 core CPU on my workstation. Always nice when software can use more of them.