Android: System crashes from fiddling with a busy project

[Saltbearer]

I wanted to play around with having a kick jack up vibrato amplitude, so I opened Cloudburst Migrant's project file https://drive.google.com/file/d/1Ba8fX5 ... p=drivesdk , soloed/disconnected some stuff while listening to a couple parts of the song, then put everything back, started looping a pattern from line 1632, slipped a Vibrato module into the chain between Compressors 01 and 1F, turned the frequency up high, turned on exponential amplitude, maxed amplitude, aaaaand caused my phone to crash and restart.

Tried to replicate it by putting the vibrato back in the chain, couldn't at first, then noticed a little lag when I moved Compressor 01. Tried moving that module around wildly, aaaaand caused my phone to crash and restart.

It seems like I've been hearing a lot more popping noises while playing projects as busy as this one since the 1.9.5 update, which, as they have before, become worse as buffer size is increased. Possibly relevant?

It also seemed like just having the project open in the background while typing this caused lag that interfered with the keyboard.

Samsung Galaxy S8, screenshot of system info: https://i.imgur.com/uXgbmNP.jpg

(more than one phone had to be replaced due to carriers pushing faulty updates, so I've postponed endlessly...)

SunVox init via log:

Code: Select all

SunDog Engine / Jan 22 2020 23:29:06
WM: initializing...
Android version: 8.0.0
OpenGL version: OpenGL ES 3.2 V@269.0 (GIT@4bd8562, I53d7d6a370) (Date:05/02/18). Renderer: Adreno (TM) 540.
WM: 1080 x 2220; PPI 369; lang en_US
WM: screen_angle = 90
WM: screen_scale = 246 / 256
WM: screen_font_scale = 257 / 256
WM: font_zoom = 2
WM: flags SCALABLE FULLSCREEN TOUCHCONTROL OPTIMIZE_MOVE_EVENTS 
WM: color theme loading (other colors)
WM: ready
device_sound_init() begin
SLES: 48000Hz 192; optimal: 48000Hz 192
SLES: exclusive cores:
SLES: slCreateEngine
SLES: Create Output Mix object
SLES: Create the music player
SLES: Setup to receive buffer queue event callbacks
SLES: Play
device_sound_init() end
Stack ptr: 0
SunVox v1.9.5 Jan 22 2020 23:29:06; driver: OpenSL ES; 32bit floating-point; sample rate: 48000; ARCH: arm64; OS: android linux

[NightRadio]

Hi!

so I opened Cloudburst Migrant's project file

Seems that the problem is in long module names (32 bytes).
I cut them to 31. Please try it now (sent project to your email).
This bug will be fixed in upcoming 1.9.5c.

It seems like I've been hearing a lot more popping noises while playing projects as busy as this one since the 1.9.5 update

Now it uses the optimal audio settings for your device: 48000Hz ; buffer = 192 frames.
SunVox 1.9.4 used the following settings by default: 44100Hz ; buffer = 1024 frames.
This is the main difference. I think this can cause an increased CPU load in some big projects. You can try to change it back to 44100+1024

It also seemed like just having the project open in the background while typing this caused lag that interfered with the keyboard.

Perhaps because the app is running with "Low Latency" audio priority.
By the way, the app will be closed after 4 minutes of silence in background (for example, if project is stopped)

[Saltbearer]

Seems that the problem is in long module names (32 bytes).
I cut them to 31. Please try it now (sent project to your email).
This bug will be fixed in upcoming 1.9.5c.

Uh, if there was a bug there, that's unrelated, but good to have fixed!

I loaded scsux2.sunvox and immediately caused a system crash and restart by retracing my steps with the vibrato and wildly wiggling Compressor 01 - but wait!

It seems like I've been hearing a lot more popping noises while playing projects as busy as this one since the 1.9.5 update

Now it uses the optimal audio settings for your device: 48000Hz ; buffer = 192 frames.
SunVox 1.9.4 used the following settings by default: 44100Hz ; buffer = 1024 frames.
This is the main difference. I think this can cause an increased CPU load in some big projects. You can try to change it back to 44100+1024

I tried changing my audio settings to the default... and there was no popping, and if it was possible to cause a crash the same way, I didn't have the patience to find out! There was a little bit of crackle with the 2 ms buffer size, which sounded a lot worse when I wiggled the compressor, but I was still unable to force a crash!

Oddly, in the previous version, I'm fairly sure anything above a 2 ms buffer size was unusably crackly and stuttery, whereas 2 ms was reasonably smooth, and I don't think the sample rate affected that. Now, at 44100, the default buffer seems perfectly fine, and larger buffers are only slightly skippy, but it all seems worse at 48000.

I feel like it might be related to on-screen visuals in some way - IIRC, in the previous version, the popping lessened a bit with would-be moving elements such as module visualizers out of sight, plus a bit more if I kept my finger on the screen to... force the system to focus on the app, based on what you or another user thought might be the case, when the other user brought it up. I have the app running at 60 FPS, and with 20 connections to that compressor to redraw on top of playback... maybe that's a lot of strain?

By the way, the app will be closed after 4 minutes of silence in background (for example, if project is stopped)

Good to know! (And for anyone wondering, I just confirmed that signal-generating LFOs which aren't routed so as to produce audio will not impede this functionality.)

[NightRadio]

I loaded scsux2.sunvox and immediately caused a system crash and restart by retracing my steps with the vibrato and wildly wiggling Compressor 01 - but wait!

But scsux.sunvox was loaded first as previous session?

Oddly, in the previous version, I'm fairly sure anything above a 2 ms buffer size was unusably crackly and stuttery, whereas 2 ms was reasonably smooth, and I don't think the sample rate affected that. Now, at 44100, the default buffer seems perfectly fine, and larger buffers are only slightly skippy, but it all seems worse at 48000.

The sound output code has been slightly modified in 1.9.5. But still it is very device specific. There is no perfect combination of settings for all Android-based devices.