Compared to my old Galaxy S10 from 2019, my new Galaxy S23 Ultra with 12GB of RAM has hugely better performance in other apps and gaming. However in Cubasis 3.5.2, it performs significantly worse, according to the DSP usage metre. When I play the exact same 16-track VST stress test on both phones, the DSP usage is about twice as high on the S23 Ultra (avg. 60%), with both phones set to single-core mode. Multi-core usage is closer, but still worse on the S23 Ultra.
If it helps, the latency in single core mode is about 15ms for the S10, and about 6ms for the S23 Ultra. The maximum latency in multi-core mode is about 48ms for the S10, and about 32ms for the S23 Ultra. Could this be causing the problem in any way?
This performance anomaly is shocking and shouldn’t be possible, because the new Snapdragon 8 Gen 2 chip is far more powerful than the much older Snapdragon 855, as other apps have clearly shown. In fact, this is the exact opposite of what I was expecting. I thought the S23 Ultra would perform at least twice as good, not half as good. Is there any way to fix this? Can this be fixed in a new update?
Samsung’s overheating protection is very strict, and only the Game launcher allows some regulation, but it is not enough. It’s causing me problems too. With certain settings, the system causes stutters, sound disturbances, and Cubasis shutdown in the event of speed changes. I can use the daw in priority mode, in this case I don’t know what happens, but there is enough power, on average 60% 20-30 frozen track. Using another mode frees up a significant surplus of performance, but only until I press the display. If I release the display, the DSP jumps 30%-70%. If there is somehow a solution for Cubasis to work more optimally with the overheating protection, I would also appreciate it, because I think Samsung handles it poorly. ( S20 )
Here comes the feedback from our engineering:
As you guessed correctly, the difference in latency is causing this. With multi-core off, the displayed latency value is the system’s buffer length. Apparently, on the S23 it is 2.5 times shorter than on the S10, which is a good thing for latency. However, this means that for each buffer, Cubasis has less time to do the rendering. The DSP meter shows the time it takes Cubasis to render a buffer, compared to the buffer length. It is not surprising that the faster CPU takes 60% of 6ms = 3.6ms to render a 6ms buffer, whereas the slower CPU takes 30% of 15ms = 5ms to render a buffer. Both CPUs have 8 cores but the S23’s CPU has more faster ones, which is why it excels when multi-core is on. Unfortunately the system’s buffer length cannot be configured on Android, because if you could set the S23 to 15ms latency, you would clearly see the x2 performance difference.
So there is truly nothing that can be done about this? The difference between 6ms and 15ms latency is imperceptible to my ears, and probably everyone else’s too. This seems like a pointless and silly waste of processing power. A top fuel dragster needs a 1/4 mile to reach top speed. 1/12 of a mile isn’t enough space. Who is making these engineering decisions?
It’s been a while since I raised this issue, but I just updated to Cubasis 3.6 and discovered that the Android version now has the same latency controls as the iOS version, thereby solving the problem. Indeed, using a higher latency dramatically improves performance. I don’t know if I played a part in the company’s decision to add this feature, but regardless, thank you very much for adding it!
If you’ll hear me out a bit further, I have another inquiry and possible request:
On my S23 Ultra, I dug into Cubasis 3’s files with a 3rd party file management app (Solid Explorer), and it appears that the Android version of Cubasis is written entirely in the Kotlin programming language. Like Java, Kotlin is a high-level programming language and therefore does not allow the hardware to run at native performance. Does Cubasis use any C++ code via the Android Native Development Kit, or is it entirely written in Kotlin? The reason I care about this is because the iOS version is written entirely in Objective C, which means it does fully utilize the hardware in Apple devices. The Snapdragon 8 Gen 2 chip in my S23 Ultra is substantially more powerful than the A13 Bionic chip in my dad’s 9th gen iPad, and yet his iPad still runs Cubasis 3 substantially better than my S23 Ultra, even at the same latency settings. Therefore, I’m inclined to think that the Android version only uses Kotlin. If the Android version of Cubasis already uses C++ for all the heavy lifting, then there must be an optimization issue. All of this leads me to make two requests:
If Cubasis on Android is written entirely in Kotlin, then it would be really great if a future version could take full advantage of the Android Native Development Kit by using C++ code for all the heavy lifting, and only using Kotlin for the lighter peripheral tasks. Is there any possibililty of this happening?
If Cubasis on Android already uses C++ for the heavy lifting, then it would be great if it was cleaned up and better optimized in a future update. The 9th gen iPad should not be outperforming the S23 Ultra, all things being equal.
Anyway, I don’t mean to ask for the Sun, Moon and stars. I just hope it will be considered. Thanks again for adding latency controls to the Android version! I hope to hear from you!
From what i gather… if the audio engine is built on C++ , you can build the rest of the app in kotlin or java but shouldnt make much difference in functionality.
I recall being said that cubasis is using the standard android audio engine so i recogn it’s in c++
The disparity between apple and android is that apple build their igadgets upon their initial ipod series and has been very focussed on their audio delivery (hardwarewise) since it’s inception. Many features android simply doesnt offer.
Okay. Are you saying there’s no other choice? Why can’t Cubasis just use its own custom optimized audio engine? Does the Android OS intrinsically prevent this?
LG used to deliver audiophile-grade Android smartphones with their Quad DAC technology, and Sony still delivers phones with high quality audio hardware, so any notion that Android phones can’t/don’t focus on audio delivery is incorrect.
Are those really features that Android itself doesn’t offer, or are they features that Android software developers don’t offer?
No, there are 3rd party audio engines… it’s just what they chose for whatever reason i guess.
I just recall what they once said when questions about the audio engine for android were asked.
Im hot saying android does nothing for their audio department but apple’s first focus has been audio…
From ipod to ipod touch to iphone…
I guess android just doesnt have the features… i havent seen 1 app on android that does what “Audiobus” already does for years on ios.
I see. Well then, I’ll have to modify my request. I’d like Steinberg to give the Android version of Cubasis its own audio engine written in C++ which supports the same features as iOS, like having at least 24/24 physical inputs/outputs (I see that it’s up to 64/64 now), 96kHz sampling, etc.
Fair enough. Sorry for misunderstanding you.
So it’s really the software developers who are either not making the apps for Android at all, or not giving Android apps the same features as iOS, even though they could. Technically, Android could be made to do everything iOS does. I’d really like that because I use my phone as my computer via desktop mode/DeX.
Well i believe that “audiobus” cant work on android because android has a different mechanic in their “multitask” feature… as android snapshots and freezes an app when put in multitask, ios lets the app run fully when put in multitask (background). Something along those lines.
If I understand you correctly, you’re suggesting that Android doesn’t permit true multitasking. However, I can unequivocally confirm that it does. Not to start a flame war, but it’s actually the iPhone which lacks true multitasking as an OS function (more than merely background tasking). The following picture shows my S23 Ultra multitasking in DeX mode on a 32" 1440p monitor:
• The phone does not overheat due to a combination of its excellent internal vapour chamber, and a thermoelectric phone cooler.
• Everything with a play button was running simultaneously without lagging or crashing.
• Everything stayed snappy and responsive, and everything stayed in RAM (12GB) without swapping to main storage, which I verified (for example, none of the 14 desktop websites had to reload, and they all stayed lightning fast, no joke).
• The only small exception came when moving the model in Nomad Sculpt (bottom left, containing 700,000 vertices, about 30 layers and painting), which caused a bit of visual playback stuttering in other apps. I’d hardly call that a dealbreaker, and it could simply be an optimization issue (Android is infamous for poorly optimized apps compared to iOS, after all).
• Also, Cubasis 3 is playing 16 complex VST instruments concurrently in single-core mode with extra-low latency (6ms total). Those are the most taxing settings possible, and it still only consumed about 30% of the DSP on average (no CPU usage metre), and that’s with Android’s lackluster audio engine.
Perhaps the devs could give Cubasis on Android a closer look? Maybe also Android desktop modes, for that matter? (DeX, ReadyFor, etc.)
You just pointed out one of the main differences, and limitations, of Android — different versions between different hardware manufacturers. The lack of a single standard hardware platform and Android software design and deployment has created a support nightmare for app developers. While this conversation has been focused on Samsung mobile phone products, not even including Samsung tablets, imagine updating your app for Samsung hardware only to have that update be a problem on another vendor’s hardware.
Steinberg has been one of the very few companies “to try” and maintain both iOS and Android versions of some of its mobile apps. if you consider how few Android users even purchase Cubasis, then the financial risk taken by Steinberg can only be appreciated, IMO.
Before buying an iPad in 2020, I was using an Android tablet. What annoyed me the most was being limited to only having phone apps available for Android tablets, none of which took advantage of the tablet’s bigger screen. Android, especially Android tablets, have a lot of catching up to do to iOS devices.
Once again, my opinion, from my hands-on experience with both Android and iOS devices.
