Is it possible to upgrade Dwarf’s processor…?
If yes , any idea about the cost…?
I’m not sure if that is possible at this point.
You would need to get a compatible SOM with a more powerful CPU - that’s not an easy task I believe.
The cost would always depend.
I think it’s safe to say: no.
It’s not like a traditional CPU that you have a socket and you can simply swap out the processor.
ARM systems have the CPU, together with RAM and other small chips, in a tiny package that is soldered directly on the main pcb. Switching that out for another (compatible) chip is a nightmare.
This is why some manufacturers put their main SOC on a smaller pcb that they can replace separately. Still not trivial as it needs to be pin compatible to all peripherals etc.
That is really sad to hear!
Not so much the fact that it’s not possible the upgrade but the fact that someone feels that it’s already needed a CPU upgrade.
It’s ok now…
I had some audio glitches at 128 frames on pedalboards with a lot of FX…
I changed the buffer size to 256 and it works fine…
Please don’t be sad…
Can some oft briefly explain what happened here?
À bigger chunk size made it easier for the cpu to handle as there is less “meta” info and opening/closing and more “stream”; needing less handling? If so, what’s the downsize?
Before oversampling introduction on some amps and cabs, CPU power was enough. But honestly, oversampling is something I need. I can barely run 1 amp, 1 cab, 1 distortion, 1 delay and 1 reverb with 256 buffer size (which is a bit laggy to me). Adding RMPro to improve quality is not even possible.
I suspect that the installed processor, if not the complete hardware, is quite elementary according to:
- initial support for Duo X rev. 3 units (with firefly rk3399 SoM)
Source: Releases - MOD Wiki
The performance difference between duo, dwarf and duox alone should be quite high. This allows more complex patches to be created.
Source: Say hello to the MOD Dwarf - #178 by gianfranco
Most audio in digital world runs in sample blocks, e.g. processing a “block” or chunk of 128 samples at a time, then letting the soundcard do its thing and wait for the next time audio is needed.
With the current MOD setup at 128 samples in 48kHz rate, this makes each audio block be 2.3ms.
So host need to handle time and plugins and other complexities within that 2.3ms window, taking more than that and audio wont be ready on time and you get xruns (cracks and pops in the audio).
By increasing the buffer size from 128 to 256, we are doubling the amount of time host and plugins have to do their thing, now at 5.6ms.
The side effect is that the audio card now has to wait longer between each call, which increases latency.
If buffer size is low, it means we can receive and feed the audio card quickly, as the number of samples to process is small. When buffer size is big, we have to fill quite a lot of samples each time.
The image that you shared above has some info regarding the Dwarf audio outputs that differs from the info found on the Dwarf’s technical specifications wiki page.
This is a very important technical spec. Which one is correct? Hopefully the wiki is the correct one since I’ve never seen the above image before.
I would trust the wiki more than the picture.
Yes some things are not right (anymore) on the picture.
But the data regarding CPU/RAM/Memory should still be correct.
Every day I learn; thanks @falkTX !
@rogeriocouto, @khz is right. Trust always more on the wiki and current version of the website! And even that is outdated sometimes, but not on tech specs.
The image that @khz shared before comparing the devices is outdated especially in the case of the Dwarf.
As far as I know, that table was created even before I joined MOD, which means quite a bit before any Dwarf was shipped, so it was still in development.
If it does not make much of a time commitment could you bring the table (from the picture) to the current state and adjust it if necessary when there are new features?
The table on your website for direct comparison of the devices would be IMHO helpful for new people who are interested in the mod.
Indeed, altough that table was shared for a different purpose I believe.
I’m not sure where/who is/have the original file that can be moded, but I will ask around
Hi! A technical question for @falkTX… would core binding improve performance somehow? Thinking about binding AMP plugin to core1, CAB plugin to core2 and leave the other plugins to remaining cores.
not really, probably even makes things worse.
the kernel is typically smart enough to know which tasks to give to which cores.
if the dwarf had big/little architecture setup like the duox, then yes there could be some gains to restrict heavy plugins into the big/performant cpus, but on the dwarf it makes no difference.
Thanks! Would be interesting to see how much would the Duo X benefit with this cpu management.
I peered inside my Dwarf recently, there is indeed a removable board looking much like SBC. Is it at least remotely possible for MOD to procure a compatible one and release it as Dwarf Upgrade Board? I’m certainly ready to pay for such a thing (or even for a promise thereof:)
I’d really like to get more involved with the device itself and the ecosystem - already outilining my own plugin ideas etc. But if we’re stuck with this hardware, does it really make sense? CPU is already at 80% and I didn’t even try Cardinal yet
Not really, these socket-like boards do not share a standard and thus are not compatible with each other sadly. Making a converter board is possible, but a big engineering effort.
For the CPU, it is a matter of “work smarter, not harder”. There are a lot of plugin ideas possible that do not need a lot of CPU. Cardinal (and Rack) will always going to consume a lot of CPU because they do processing 1 sample at a time.