Android builds - seeing variables in the debugger, setting -O0


#1

Hi Folks,

I’ve had a long-standing problem with not being able to see variables in Android Studio.

The basic reason is that all builds were getting build with -O2

My solution was to change this in the build.gradle files:

  • from: arguments “-DJUCE_BUILD_CONFIGURATION=DEBUG”, …
  • to: arguments “-DCMAKE_BUILD_TYPE:STRING=Debug”, “-DJUCE_BUILD_CONFIGURATION=DEBUG”, …

I found the solution using info here: https://stackoverflow.com/questions/45536672/adding-o0-to-cppflags-fails-to-disable-clang-compile-optimization-in-android

Hoping that helps somebody!

Pete


#2

I also ran into this issue recently. I’ve added an answer to that stackoverflow post. I also wrote about it here: https://medium.com/@donturner/debugging-audio-glitches-on-android-ed10782f9c64


#3

Hi Don,

Good article. FWIW, I have always got much better audio behaviour in terms of latency and audio break-up when using Juce, by using my own audio adaptor (OpenSL) rather than the Juce Audio I/O code. I also use my own audio adaptor code for iOS, for integration with AudioBus etc. (I also use my own MIDI adaptor code for iOS/macOS).

I use the Juce audio adaptor code solely for desktop (for MIDI - I use the Juce interfaces only for Android and Windows).

Pete


#4

I found this old blog post I made on the subject of Android audio (and latency), in case of any interest - http://sseyod.blogspot.com/2011/12/android-high-performance-audio-how-to.html

Pete


#5

Hi Pete - any insights as to what the reason behind that could be?

I’m asking because it surprises me! For a couple of years we’ve worked closely with Don and the Android audio team at Google to make sure that JUCE does all the right things to squeeze optimal performance out of Android openSL… So if you’ve found a trick that the guys who actually wrote the OS have missed, I’m sure they’d also be keen to hear about it!


#6

Hi Jules,

It isn’t something I’ve every sat-down to think about, TBH.

The audio device driver model implemented in the Intermorphic Sounds System (something I originally designed / wrote for ultra-low latency back when it was the Intent Sound System, which was the audio stack for Tao Group’s Intent mobile OS) is pretty simple.

It is a strict pull-based model, where the system works with a pre-rendered number of audio blocks (minimum required for no audio break-up). The device callbacks are made to the iSS mixer engine, which in turns makes callbacks to the various app components (I’m sure this is basically how the Juce system must work!).

The current configuration for Wotja looks to be:

  • block size 1024 sample frames
  • 44100 Hz
  • 10 audio blocks pre-rendered

Just checked, and I’ve stuck with those settings since at least 2012; hasn’t been any need to change them. There is might not be any need to pre-render so many blocks these days.

We changed from 22 kHz to 44 kHz audio rendering for Android back in 2015, which is roughly also when we changed the synth units in the iSS to all render in stereo for all platforms.

Latency is therefore fairly high, but as you know there are a huge range of devices we all have to cater for on Android :slight_smile:

Happy to give more info if I can be of assistance, as always.

Best,

Pete


#7

Ah right… the difference is probably just because our code is geared towards better low-latency performance rather than trying to keep the load down when latency is high. I got the impression from your earlier post that you’d found a trick to reduce the latency beyond what we could do, but if that’s not the case then it’s less of a mystery :slight_smile:


#8

I’ve found that that is more important to prevent audio break-up than setting latency to a minimum :slight_smile: Of course, back when the iSS was at the core of a gaming platform, the device configuration set that pre-render block size, and it “just worked”. Things are different now we’re all running on host operating systems!