Csound API crash on Unity Android

Hi all,
I’m glad Csound finally has a forum!
Hope I’ll find some answers for this issue.
I am working on the new version of CsoundUnity, GitHub - rorywalsh/CsoundUnity, a great project started by @rory with the help of Richard Henninger.
The goal of the new version is to pack Csound in the form of a Unity Custom package, to be used via the Unity’s Package Manager, basically to be able to import it directly from the git repository above (from the develop branch).
Everything works great on Windows (and in editor), but we are facing a crash in Android.
This is the crash log:

signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
Cause: null pointer dereference
...
at libc.memset(memset:48)
at libcsoundandroid.kperf_nodebug(kperf_nodebug:210)
at libcsoundandroid.csoundPerformKsmps(csoundPerformKsmps:70)
...

I’m using the android .so libraries found in:
csound-android-6.15.0\CsoundForAndroid\CsoundAndroid\src\main\jniLibs

I tried compiling with IL2CPP or without, using ARM7 or ARM64.
I tried on different devices with Android 6, 7 and 8.

This is the relevant code we use to start Csound, where csdFile is the string representing the content of the csd:

Csound6.NativeMethods.csoundInitialize(1);
csound = Csound6.NativeMethods.csoundCreate(System.IntPtr.Zero);
Csound6.NativeMethods.csoundSetHostImplementedAudioIO(csound, 1, 0);
Csound6.NativeMethods.csoundCreateMessageBuffer(csound, 0);
int ret = Csound6.NativeMethods.csoundCompileCsdText(csound, csdFile);
Csound6.NativeMethods.csoundStart(csound);

This works perfectly on Windows.
Asking for the version and API version works on Android too:

started Csound version 6150, API Version: 400

So the libs are found, and some of the methods work (for example calling GetOpcodeList returns correctly), but the crash occurs as soon as Csound tries to write/allocate memory, for example calling PerformKsmps.
I tried to debug the size of MYFLT and these are the results:

size of MYFLT: 4
type of MYFLT: System.Single
Marshal.sizeof: 4
Csound size of MYFLT: 4

so we should be handling its size correctly on Android.
But we have the crash. Could it be related with the Android manifest and the permissions?
EDIT: tried adding permissions to the AndroidManifest, same crash.

Any idea?
Hope to find some answers here on the forum!
And of course, any help with the package is more than welcome, we need samples, docs, and above all new users! Please contribute!

Thanks for reading!

Looks like kperf_nodebug has memset calls related to spout:

I’m not sure what would cause that to be a null pointer. Did you check the return value of csoundCompileCsdText()? And what is the latest branch/code to check for CsoundUnity?

It returns 0, so the compilation should be fine.

We’re using develop, the default branch https://github.com/rorywalsh/CsoundUnity.git#develop
We’re developing on Unity 2019.3.9f1, but you can open it with the latest Unity, I tried it with the same results.

EDIT:
Git setup
1 - inside a Unity Project folder, create a folder Packages (should be already there), at the same level as Assets
2 - create there a folder CsoundUnity
3 - clone there the code
4 - from Unity, open the Package Manager and check if the package has been imported
5 - import the Basic Test from the package samples. It will be inside Assets/Samples/CsoundUnity/1.0.0/Basic Test.

For completeness, this is how to install the package from Unity Package Manager
1 - open the Package Manager
2 - press the + in the top left
3 - Click on Add package from git URL
4 - insert https://github.com/rorywalsh/CsoundUnity.git#develop and press Add
But in this way the package code is not fully accessible from the C# project solution generated by Unity.
The code can be found at: ProjectFolder/Library/PackageCache/com.csound.csoundunity@version/Runtime, but there is no C# solution. Changing code there “should” reflect changes, but Unity could reimport the package in some situations, so the changes can be lost.

I got it to run here, but I had change player settings to use the IL2CPP with ARM64 and ARMv7 on, like so:

After that, rebuilding and deploying to my Pixel3, I got sound playback. (It was crashing with Mono backend, same error as was originally reported with null pointer crash). I am, however, on Android 11. I don’t know if that is a factor, and I do not have any other device here to test on unfortunately, but considering I had the same crash and then didn’t hints it might not be a factor.

Well that is good news!
I’m running it on a Samsung J7, ARM7, with Android 9 (API 28).
The CsoundAndroid project using the same libraries works fine on every device/os/architecture I tried, so the issue resides in the Unity building process.
I’ll open a ticket there to see if they have some clues.
EDIT: I found something strange: running on a device with cpu architecture ARMv7-A, when asking Unity for the architecture of the device it returns ARM64, so it is probably using the wrong architecture. :thinking: I’m very confused
EDIT: this is the output I’m getting on Samsung J7: Running on a device with processor ARM64 FP ASIMD AES, 64Bit process: False, 64Bit OS: False, OS version: Android OS 9 / API-28
This is the output on Oculus Quest: Running on a device with processor ARM64, 64Bit process: True 64Bit OS: True, OS version: Android OS 7.1.1 / API-25 and it works!
So it works on 64 bit devices :partying_face:!

Great stuff guys. Thanks for the help on this one @stevenyi, we were struggling to make any headway with it!

Great to hear this is moving forward! Just to confirm:

  1. Android Csound is working on all platforms on its own
  2. Unity + Csound works only on 64bit architecture but fails on 32bit architecture

Yes? It seems that when I had just ARMv7 it failed on my ARM64 device, and now it seems that with your ARMv7 devices, it’s trying to load the incorrect ABI (i.e., ARM64).

At this point, it seems then that this is a Unity issue that’s outside of Csound itself?

Confirmed!

Yes I agree, I’ll open a ticket on Unity Issue tracker.
So we’re finally up and running, ready to create wonderful examples!

2 Likes

Awesome, glad to hear it! I’ll look forward to exploring this further and I think having this working with the Unity package manager will make things really simple to get going. Congratulations on the work!