More computing power - release an “DWARF ultra PRO SOC DIM260 Module exchange tunig kit”. e.g. from Core-PX30-JD4 Quad-core 64-bit Core Board to Core-3568J AI Core Board with Rockchip 64-bit processor RK3568 processor. optionally with npu extension to accelerate nam or aida-x models
1.1 Transfer the plugin licenses you bought in the store to the new hardware so that the expensive plugins can run again or even run efficiently. such as aida-x amps like the Vibro with the best model
restore handicraft friendliness. updating the cc-arduino-lib to modern MC alongside uno and due. and if uno, also create suitable udevrules on the dwarf so that it is possible to use the controlchaind as a usb serial without irq. If the great RS-485 attachment boards for the control chain things were still available, it would be easier to try something out. So it’s just annoying. Some people just want to build one controller and can then do without the entire chain via RS.485 with USB.
If 2. doesn’t work, please provide midi feedback for midi devices, such as foot switches. so that at least it is sent back whether you have a plugin active or in bypass. Then a MIDI footswitch would at least be able to get the correct states when, for example, another snapshot is loaded. Midi feedback has already been discussed several times. I think there’s already a pull request for it on github.
edit.
realtime kernel process priority. the dwarf cannot maintain the audio priority when writing a pedalboard. then it hails xruns. Something is set up wrong. please ensure audio is always prioritized. The same problem also occurs when a USB network is connected for the mod-UI. then xruns always happen in the audio thread. imo, that is wrong. USB shouldn’t have such a high priority over the i2s audio card. Or is my DWARF broken?
we need someone that understands both control chain and arduino well enough to take the lead on this.
this is something we want to have a look at some point, specially with the focus on the desktop side where control chain is not really a thing.
This is already the case, the audio priorities are setup as good as it can be, the same setup is done on Duo and Duo X where it works nicely, but does not on the Dwarf.
It is more of a hardware issue I think, we were able to put some mitigations in place but nothing that truly escapes the problem.
My investigation led me to create a test case in GitHub - mod-audio/mod-memset with a bit more explanation.
The libc on Dwarf is patched to avoid optimized memset call, which runs a little bit slower but allows for example to drag&drop plugins with better RT behaviour (the TTAP used to cause xrun when loaded, which stopped after we patched libc).
Speaking with other developers, even those maintaining glibc packaging, didn’t provide an answer at all.
From time to time I come across something that seems relevant, but no more improvements in a while.
a way, if feasable, to “expand” the processing power of the Dwarf would be very welcome.
I would even consider hiring somebody to build me a portal device that works like a Dwarf with more processing power
Some tests on point number 4 realtime scheduling on SMP system, while jack2 with smp is running.
Example images with a top -H -p and the currently running pedalboard. Once with a simple amplifier model, once with a good amplifier model.
and a cyclictest --mlockall --smp --priority=80 is running in the second console to measure the latencies with rt-prio 80. Jackd is also started at 80. Min: ,Act:, Avg: and Max: show latency time (in us). And there are two more pictures with the same attempt without the cyclictest running. just to have another look at load average. Here I notice that although jackd shows 100% in its own measurement in the mod-ui, the load avg is only ~2.5 - ~2.1. and that even though jack2 supports smp. It looks to me that jackd or whatever is behind it isn’t properly distributing threads. Actually, with 4 processors a load of 4 is possible, so that rt prioritized commands should actually be handled by the scheduler. I don’t understand much about it but it seems strange to me. especially when mod-host starts each plugin individually with at least one thread of its own. In this example, the Vibro amp probably has the PID 4075. The CPU value goes to 45% with the good model and drops to 14% with the bad model. From what I understand, there should still be room for improvement. Finally, a measurement with a small amplifier model but cyclic test and disk I/O through save pedalboard. Here the Max: shot straight up to 900 us. Since, as I said, I don’t understand much about it, I can’t pinpoint the error. I would still like to take the trouble to write something about the problem. And of course I would like to mention that I bought the Vibro model so that I could operate it with high resolution. it sounds really great. but unfortunately the dwarf can’t do it. 256 samples is not an option for me. With the high buffer setting it just works.
that is normal and expected, you cant parallelize a single chain as next plugin always needs the audio from the previous plugin, see the portal plugin for a discussion around it where the “solution” involves intentionally adding latency.
cpu usage and dsp usage are not the same thing. dsp has has fixed amount of time to do processing, a simple sleep(1) would take 0% cpu while taking > 100% dsp load
Possibly some optimization could be done at plugin level, especially the non “time based” one
E.g consider a plugin applying a function to the signal that is not depending on the history. The simplest would be a gain or a gate, while an echo or a delay would not fit in this category.
Such plugin could split the input buffer in two sections and have two threads to separately take care of them.
While this would be actually useless for a really simple function like a gain, it could speed up some amp or cabinet simulation
