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.
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.
Hi @khz
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.
@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.
That’s sad… Of course “smarter, not harder” should always be the motto:)
But, when one is getting ready to dive into some serious hacking, seeing hardware ceiling this close is rather discouraging… Some generic SBC (rPi4?) with generic OSS stack (zynthian?) looks like better option then. Will probably take much more to setup initially, but then you’ve platform, which won’t die just because hardware gets outdated.
But back to MOD: if not overclocking and not upgrade board, new device then? When can we realistically expect one?
From what you’ve written, I’m guessing you’re not aware of what’s been happening in the semi-conductor the last few years. Now that’s sad. Case in point, this morning I was looking for a Morningstar device and they’re all sold out on the site. In the forums they recently posted that they’re very optimistically not expecting a new shipment of chips until later this year - from an order placed a year or two ago.
I’m not speaking on behalf of the company, just as someone who’s been hanging out here for several years. I’d say the time frame is several years for a new device.
Good luck with that! Some of us here will be curious to see how it turns out.
Maybe try to hunt down a Duo X? Anyway, even when the next gen Red Dwarf is released, someone will show up to describe how they’re hitting limits with 43 plugins and 157 audio pathways, and really, how can anyone be creative like that? The good news for the rest of us is that for all of human history music been created with and defined by the limitations of the tools we were using. Even entire genres of music are predicated around what was possible to create with the tools at hand.
For what it’s worth, many of us have experienced the “Possibility Paradox” of the MOD devices. When you’ve been flying around in airplanes all your life, and someone puts you in a rocket, your perspective of where you can travel broadens exponentially. But that doesn’t mean it’s easy or even possible to fly it to every horizon, and sometimes that’s hard to accept. I hope you find some enjoyment with the device and seek help from the community with solving audio design puzzles in a satisfactory way.
What is the latency in miliseconds for 128 vs. 256 sample blocks?
You can easily calculate this:
At 48000Hz and 128 samples per block → 128/48 = 2.67ms latency per block.
You have to add some ms for the analog → digital and digital → analog conversion, don’t know how much though
Hi everyone,
I can see two different SOMs referenced in the dwarf docs under the GitHub hw-mod-dwarf repo:
I guess the Firefly Core-PX30-JD4 is the one actually used in the dwarf since the board schematic has a SODIMM connector. Can anyone confirm this? I don’t have the device (yet?) but I’d like to see if there is any available SOM out there that might be pin compatible or close enough to require only small adjustments.
P.S.
I wanted to include useful links to the SOMs above but the form didn’t allow it.
I’ve upgraded your trust levels, so now you should be able to add the links (go ahead and edit the post if you’d like)
I guess the same.
Without being super sure about which one exactly is. As you are probably aware, the MOD Dwarf saw “the light of day” in a really disturbed time for the supply chain (2020 / 2021 - COVID pandemic followed by a huge supply chain crisis). I don’t remember well, but I think this was a result of that crisis in the semiconductor industry and in order to move on, some adjustments were required. Really likely this was simply one of them
