Call for patches that push Core to its limits, expose issues

#1

As you know I'm working on some next generation hardware as described here: https://sebiik.github.io/community.axoloti.com.backup/t/next-gen-and-mini-axoloti-hardware-discussion/5908/216

I want to compile a nice collection of patches that really push the hardware for performance testing. I'm specifically interested in patches that expose issues with SD Card locking or stuttering. Patches that run into memory limitations either SRAM or SDRAM will also be useful.

These can be patches that you have from the past or new patches you can make quickly to illustrate unexpected behavior.

Think of anything that can break or crash the current system, any situation where you noticed issues or were confused by something. Even if you have a patch that is only unstable some of the time or under certain circumstances, submit it and describe what happened.

As we go forward I want us to get in the habit of creating minimal test patches that expose specific issues. Try to give me the smallest possible patch that exposes the issue even if it came from some larger project you were working on. That will make it easier for me to resolve. This might be the single biggest way to contribute if you're not comfortable working on the internals: find bugs or issues, create minimal test patches that illustrate them. This makes it a lot easier for other developers to come in and fix issues too.

By the way, this thread should be specific to particular patches and firmware behavior, we'll deal with overall patcher issues separately.

Anyone has a Axoloti Core for sale in the EU?
#2

Here is a simple patch to test SdRam usage.

It just loads 2 tables, one 4194304 samples tables, which is the limit of SDRam, and then there is another table that takes the old Axo board over the limit.

Try increase size of table 2 to see how far you can push it.

Sorry, don't remember but how much SdRam is the new one supposed to have?

Sdram Test 1 .axp (1.1 KB)

#3

Cool. Thanks, @jaffasplaffa. The new board has 32 megabytes of SDRAM.

Here's the break down of the different internal memory regions:

    flash0 (rx) : org = 0x08000000, len = 2M        /* Flash bank1+bank2 */
    flash1 (rx) : org = 0x08000000, len = 1M        /* Flash bank 1 */
    flash2 (rx) : org = 0x08100000, len = 1M        /* Flash bank 2 */
    ...
    ram0   (wx) : org = 0x24000000, len = 512k      /* AXI SRAM */
    ram1   (wx) : org = 0x30000000, len = 256k      /* AHB SRAM1+SRAM2 */
    ram2   (wx) : org = 0x30000000, len = 288k      /* AHB SRAM1+SRAM2+SRAM3 */
    ram3   (wx) : org = 0x30040000, len = 32k       /* AHB SRAM3 */
    ram4   (wx) : org = 0x38000000, len = 64k       /* AHB SRAM4 */
    ram5   (wx) : org = 0x20000000, len = 128k      /* DTCM-RAM */
    ram6   (wx) : org = 0x00000000, len = 64k       /* ITCM-RAM */
    ram7   (wx) : org = 0x38800000, len = 4k        /* BCKP SRAM */

Will go into more detail later about his but there is some complexity around how these different regions interact with each other and with peripherals that is unique to the H7, so how patches are positioned in memory will be slightly different compared to the original Core.

It also has 16Kbytes of L1 cache (different from the F4): https://www.st.com/content/ccc/resource/technical/document/application_note/group0/08/dd/25/9c/4d/83/43/12/DM00272913/files/DM00272913.pdf/jcr:content/translations/en.DM00272913.pdf

Ensuring that we're using the cache as much as possible is going to be critical.

#4

32 sounds GREAT. That is 4 times what we have now.

Already thinking about crazy things to do with all that memory, haha :slight_smile:

Really seriously excited to see what you come up with here.

Sorry I don't really know what to make of those numbers in the scheme you posted. I am not that tech savy.

The patch I posted, for testing Sdram, it is easy to make one for testing the Sram, just change the table types.

#5

We should be able to unlock the 64k SRAM table limitation as well. It's currently in a 128k region, but we can probably go up from there a bit. We've got about 1M to work with overall up from 256k on the original Core.

#6

Sounds great about SRAM too. So exited here :slight_smile:

Not really sure what more we can test here.

The SRAM + SDRAM problems are pretty much the only limits I encounter all the time. Besides that I don't find a lot of issues.

I just look forward to see what this upgrade will lead to.

Higher quality filters, oscillators etc.? It sure will be an option :slight_smile:

#7

Bring on the convolution reverbs :slight_smile:
If I could just get a reverb to sound as nice as my old Behringer Rev2496 V-Verb Id be a very happy man :slight_smile:

#8

Yeah I heard good things about that one too.

Also being able to actually have like , kick, bas, hihats, pad, lead... AND on top of that have a reverb and maybe a delay loaded, is going to be soooooo sweet. Already saving money for the new Axo, hehe :slight_smile:

#9

I'm a huge reverb guy too. This is something that I definitely want to explore, just getting a bunch of the known reverb implementations ported over and usable.

Tangent: I have one of the Zoom CDR pedals. It has some pretty neat clones of Eventide algorithms among other things. If you have links out to interesting reverb code or existing implementations, post and I'll look at getting them ported.

#10

@urklang

Should we do it here or maybe use this thread for reverb talk?

#11

hah, since my last post in that thread pops up: I don't know it this is relevant to you, but the patch you see there (8ap-loop-plus_myedit) maxes out Sram pretty much. When I was writing it I realized my DSP Load was around 60%, so I thought I can still add lots of Options, definitly wanted to implement some form of pre delay (now its implemented pretty crudely, just a single delay) I can't really add anything without getting the overflow error.

#12

Yeah that is the problem. I think I never had the DSP meter go to 100%, because the Sram is pretty much always overloaded before you get that far :slight_smile:

Sram is by far the biggest issue on Axoloti. But for the new one, we get a lot more of that too. I really look forward for this to be up for sale :slight_smile:

#13

This is really valuable feedback guys. Thanks. I'll keep as much SRAM headroom available as I possibly can in the new implementation. Memory-related bottlenecks are always going to be a barrier even with the significantly increased CPU clock. There will likely be other opportunities for savings though as I get more into optimizing other parts of the system for the H7.

#14

Yes that would be really great.

SRam and SDRam is the biggest issue. I never managed to max out the DSP in anyway, but the SRam is reached in pretty much in every patch and also often the SDRam.

I like to use Axoloti as a full production suite, not only as an instrument, like a bass or a karplus strong algo. I like to use it as full suite where everything is playing form the device, like kick, bass, hihat, snare, a pad and a lead and then maybe a reverb and a delay effect. You pretty quickly max out one of the old axo SRam and SDRam by wanting that. With this new one I am very hopeful that this will be a lot more fu, with more headroom for the ram types.

So yeah, the more headroom for these two guys, the better :slight_smile:

#15

Just on the off chance no-one's thought of this: An easy way to get to the DSP as well as S(D)RAM limits for me has always been to take a polyphonic patch and up the number of voices.

From me, too, more power to you for taking this on!

#16

one small update to this: I tried using the axoloti with this patch (8ap-loop-etc.) as a midi thru (on top of the reverb) and found, that it won't deliver a steady clock with this patch (Sram nearly maxed out). When I add the thru objects into an empty patch it works just fine. It has to be an issue with the sram, because as I said, my DSP load is at about 60%, so there should be some headroom.

Still don't really get how the SRAM works, are there any threads explaining it? I mean, I get that for delays, allpasses, etc. you need some ram to store the audio, but it seems almost all objects, regardless if they use a buffer eat some sram away.
e.g. My patch was overflowing and I deleted a normal map b object, and then it worked fine!

#17

For delays and tabes and so on, it is recommended to use the SDRAM version. Those object should have "SdRam" in the end of the name. That saves SRam. But yes I think you are right, pretty much any object uses some Sram, some more than others. And the really memory consuming ones, again, like delays etc. has their own SdRam versions.

#18

all objects use sram simply because you usually save variables etc. there.

so if you use an arpeggiator or a lowest note priority keys object those will eat 128 byte each just for storing all the possibly held down keys...

#19

Actual machine instructions for each patch object are also saved in SRAM, not just their data storage.

One approach I want to try eventually is to just put all of the factory objects in Flash. I'm of the opinion that this is probably how it should have worked from the beginning. The vast majority of objects never change, yet we're forcing ourselves to recompile them all the time.

With this approach the "patch" becomes lighter weight; most of the time we're referring to the factory objects that are already available in Flash. Objects that are being dynamically edited can still be loaded into SRAM as edits are taking place.

In other words, I think there are bottlenecks in the current system coming from the software architecture, not from the hardware itself.

#20

Urklang, I agree that it might be nice for unchanging objects to be in flash, but I don’t think the fact that they get recompiled every time merits much concern. On even an old core2duo MacBook Pro, patches compile and load quickly, in my opinion. On my newer i7, it’s even better.

And I’m certain that treating all objects the same is simpler to implement.

Is there any performance difference between code running from flash vs. from SRAM?