Increase RAM [technical]

[SkinTex]

G-stomper is a great instrument. Well, more than an instrument really, but it features similar characteristics to the old definition of an instrument such as a trombone, violin or a harp. It requires practice, perform some maintenance and a bit of setting up before starting. I have yet to meet the first musician which pulls a giant harp out of his/her pocket and starts playing.

For me, the same goes with G-Stomper. For a quick few notes, I can easily load up the app and write down my audio ideas. No problem. But when working them out, it isn't too long before I reach certain limitations which usually presents itself in the app as *cracking* sounds. Playback buffers and I can just tell it's trying to keep up with the tempo. Started to recognize it when it happens.

It's not G-Stompers fault. It's just the hardware which can't deliver to my ever increasing demands. To be honest I have been pushing the limits of my devices in ways that I actually feel abit sorry for the CPUs.

To minimize the noisecrack I perform the following steps when starting a good session:

- Power cable
- Remove cover
- Reboot
- Airplane mode
- Close programs
- Clear notifications
- Taskkill
- Check running services
- Developer Options -> max running background
- Change homescreen to a nihilistic one

It helps a bit, but i'm still reaching the limits within no-time. Tuning down ui elements helps as well, but I do feel like driving blind without VU meters and such.

Today, when browsing through the extensive manual (yes, it is being read ), I found an interesting line at point 4.3.1: "Since there’s no way to increase the given ‘Memory per app’ limit (at least not without rooting the device)..."

I happen to have a rooted device with 512mb on the info screen, but a bit of a loss on how to increase said Memory per App. Google hasn't exactly helped out on the subject. So I delved into the build.prop in the /system folder and found a couple of lines I *suspect* might be it:

dalvik.vm.heapgrowthlimit=192m
dalvik.vm.heapsize=512m

And a few similar. Could you confirm that changing these could give G-stomper more memory?

------- Disclaimer -------

I am aware this is outside of the scope of regular usage and it can possibly damage the device. All warranty and support is void performing these steps. I am solely responsible for the outcome.

Anyone else thinking about trying this and accepting the risks: I suggest tinkering with an old device you're willing to brick.

[drewinnit]

that's an interesting checklist, thanks for sharing your technique for maximising RAM

I'm struggling with CPU/RAM as well. even quite simple songs feature crackling and glitches. i've dropped audio output to 22kHz to try to help

i'm using a tablet from 2016 so I hope that a newer device with better specs will allow me smoother audio and room for more channels, higher audio rate etc

what device are you using, SkinTex?

[SkinTex]

Been using a Samsung S4 since launch until last year. Though old in comparison, it's specs at the time were so good, it still runs Android 7 (lineageOS/nethunter) like a charm. The true benefit is having an external SD slot (64gb, enough for building new soundbanks).

However, last year I got an S6. For G-stomper this became my main device although there is little to no difference in performance between the two.

As a third device, on rare occasions I grab an Asus TF300tg which runs an old unupdated version of G-Stomper due to Android 4.4.

I use more devices for supporting music making, such as the Google Home for a speaker (great for low tones) and the Xbox for screen mirroring when using multiple devices. My couch is my studio

The S4 is going to be my test subject for the attempt to increase RAM.

[planet-h]

Today, when browsing through the extensive manual (yes, it is being read ), I found an interesting line at point 4.3.1: "Since there’s no way to increase the given ‘Memory per app’ limit (at least not without rooting the device)..."

I happen to have a rooted device with 512mb on the info screen, but a bit of a loss on how to increase said Memory per App. Google hasn't exactly helped out on the subject. So I delved into the build.prop in the /system folder and found a couple of lines I *suspect* might be it:

dalvik.vm.heapgrowthlimit=192m
dalvik.vm.heapsize=512m

And a few similar. Could you confirm that changing these could give G-stomper more memory?

------- Disclaimer -------

I am aware this is outside of the scope of regular usage and it can possibly damage the device. All warranty and support is void performing these steps. I am solely responsible for the outcome.

Anyone else thinking about trying this and accepting the risks: I suggest tinkering with an old device you're willing to brick.

Generally, yes, as far as I know, dalvik.vm.heapsize reflects the memory per app limit. Actually it's the memory per VM (virtual machine) limit.
You can of course set that parameter to 1024m on a rooted device.
But keep in mind that this won't bring only benefits;). You can be sure that there is a serious reason why not a single Android device has a heapsize per app larger than 512m.
My guess is that the JVM garbage collector will simply eat too much performance if it has to clean up twice as much ram. However, that's just a guess. Since G-Stomper holds the garbage collector off from running with highest effort, it is indeed possible that you'll be quite happy with a heapsize of 1024m.

[SkinTex]

Thank you for thinking along and making an educated guess. Figured the reason it's set to 512m is to accommodate average usage with having several apps open, not for the people who want to use just one app. Here's what happened in case someone else wants to try:

After the reply, I started out setting it to 1024m and rebooted. After watching the boot animation for 20 minutes, I declared "Bootloop" and battery pulled it. Tried again, 20 minutes later still no homescreen.

Loaded into bootloader (twrp), opened terminal, remounted /system as rw, used vi to edit build.prop back to 512m and rebooted. Again it took longer than usual to boot, about 5 minutes after which it was rebuilding all apps.

Went to do different stuff and it just kept nagging that it didn't work. What if I just got too greedy with 1024m? So I tried again with 640m (512+128). And it came through the boot! Yay.

Checked in G-stomper, 640m confirmed. So I altered the build.prop again and went for 768m, reboot, confirmed. Time to put it to the real test, I loaded up a track which is quite demanding at a certain pattern. My excitement quickly turned into disappointment when that specific pattern was up; it was actually WORSE than before. Not only was there heavy crackling like before, now the tempo also wasn't keeping up, visually and audio. It looked like it was struggling more than usual.

I've changed it all back to what it was and at the next tinkering session I plan to also change the other values with the same factors (x1.25 and x1.5) & more research on how this heap works. Maybe copy the lines from a confirmed working build.prop. I have little hope it's going to give a different outcome though, so consider it a failed experiment. But worth the attempt

I'll update this thread if I got more.

[planet-h]

Thanks a lot for the insights, SkinTex.
Interesting results, indeed. I have a report from a user who did actually set the value to 1024m on a Nexus 7 2013. It worked (booted successfully), but I don't know about the performance. As far as I know, the Nexus 7 was running Android 4.4 or maybe 5.0.