Cabbage Logo
Back to Cabbage Site

[CsoundUnity] Android app crashes on startup

Hi there,

I’m attempting to use CsoundUnity in an Oculus Quest project, but my app is crashing on startup. In an attempt to remove variables, I’ve also made a bare bones project to run on my Pixel 7 phone - it’s just a blank scene with a trigger button that triggers the Csound patch describe in the Cabbage / CsoundUnity video on YouTube. This app also crashes on load. In both cases, the project runs fine in editor - I’m using the CsoundUnity v3.3.1 package (the v3.4.0 package is not working for me).

Here are the details of my test project and settings:
Unity 2022.3.10f1
Scripting backend: IL2CPP
Minimum API Level: Android 10.0 (API level 29)
Target API Level: Android 12.0 (12L, API level 32)
Target Architectures: ARM64

Are you building with IL2CPP and enabled the 64bit support? It is required for the Quest

image

About the 3.4.0 package not working, we have some issues on Windows so that Csound grabs the system Csound instead of the one that ships with the package. So having a different version installed could lead to crashes of the editor. Try reinstalling the latest Csound and see if that fixes it.

Thanks a lot - I believe you’re correct that it’s a an issue with the installed version of Csound. Apologies, I started a thread over on Github too Unity crashes on play with package v3.4.0 Would you prefer we continue the discussion there or here?

Yeah about the Windows editor crash let’s continue there, it will be useful in case someone else has the same issue.
About the crash on the Quest we can continue here.
I will add more details on the build process on Quest on the readme for version 3.5.0 (no ETA on this yet though)

@rorywalsh I discovered the cause of the crash on Android when using Unity >= 2022: it’s the call to GetParams
If I comment those lines related with PARAMS, it runs ok with no crash.

I’m not sure why this causes a crash since the C# struct looks correct after comparing it with the C one.
I also tried forcing the use of System.Double for MYFLT.
:thinking:

Instead of using GetParams() could we just use the CsOptions flags for overriding sample and control rate? --sample-rate= and --control-rate=? But I’m now wondering if they can be set using SetOption. My gut instinct is they can’t…?

IIRC we are using CSOUND_PARAMS because that’s the only way to override sample rate and control rate.
The surprising thing here is why the same code works for older Unity versions. It could mean that some size in the struct changes for some reason. I thought that maybe it could be the fact that new Unity versions force Android to work with System.Doubles, but I had no luck with that. I will try again as that looks the only suspicious thing.

I think you’re right. What you could try is removed the SetParams, and adding the sample override to the CsOptions of the .csd file to see if that works. Btw, did you have any luck building the Csound Android libraries?

I noticed today that builds were also crashing on startup when built with Unity 2021.3.31. I knew it was definitely working correctly with my build from U2021.3.25, so I went through the process of installing Unity versions to find where things started breaking. I’ve now confirmed that the last working Unity version is U2021.3.27, but that builds fail to launch with U2021.3.28 and onward. Maybe you can spot something relevant in the release notes for that version unity.com/releases/editor/whats-new/2021.3.28
For reference, the builds were identical building the Simple Sampler demo scene, with minimum API level set to Android 10.0 (level 29), with IL2CPP and 64 bit support.
Everything was working fine in editor, by the way, with the latest version of Cabbage installed (and the version of Csound that comes with it).

@giovannibedetti did you start distributing a newer Csound build with the package? I recall you were asking about building the Android lib yourself at some point. I’m just wondering a change there might be causing the problem?

Thanks @MoShang this is an invaluable investigation.
I don’t see anything suspicious in the release notes though, so I guess it could be the case of opening an issue on the Unity Issue tracker. They have been very helpful in the past identifying the cause of issues like this.
I will investigate a bit on this during the weekend and then open an issue if I don’t find any clue.

@rorywalsh no unfortunately I haven’t built Csound Android for Windows yet, only on macOS (but I don’t use that anymore for development since my Mac is too old). But I will have to at some point!

What we could try to avoid using Get/SetParams is modifying the serialised csd string itself, overwriting the line with the Csound options maybe?
Ugly indeed but should do the trick of using the Unity project Sample Rate settings.
Maybe it could be the hotfix until we understand the cause of the crash.

I think anything that helps users get on with their work is to be welcoming :slight_smile: So if you think that would work, I say go for it!

1 Like

Oh it looks like you were right!

It is as simple as that, so we can get rid of the CSOUND_PARAMS completely

And it works!

CsoundUnity 3.4.1 (uhm I don’t remember why I never published this as a version but I just made hotfixes on the master branch) with this patch will land soon. I will do some more testing on Android first.

In the 3.5.0 version I will add the option for the user to choose if overriding the sample rate or not.

Unfortunately there are not only good news: I can confirm the Editor Crash on Windows if you have a Csound version installed on the system that is different from the one used in CsoundUnity.
I don’t know how this can be possible (maybe plugin linking fails?), but it means that the dll is looking for stuff in the system path.

=================================================================
	Managed Stacktrace:
=================================================================
	  at <unknown> <0xffffffff>
	  at NativeMethods:csoundCreate <0x000e3>
	  at CsoundUnityBridge:.ctor <0x00242>
	  at CsoundUnity:Awake <0x0081a>
	  at System.Object:runtime_invoke_void__this__ <0x00187>
=================================================================
Received signal SIGSEGV

I have 6.18.1 installed on the system, instead on the 3.4.0 CsoundUnity package we’re using 6.18.
If I update the dll in the package to 6.18.1 I don’t have the crash.
If I uninstall Csound from the system completely, I don’t have the crash and the Unity editor still produces Csound output as expected.
Victor told me there are no relevant changes between 6.18 and 6.18.1 but this behaviour confuses me.

This call we have in the bridge doesn’t make any difference apparently

if (Application.platform == RuntimePlatform.WindowsPlayer)
            Csound6.NativeMethods.csoundSetOpcodedir(".");

Any idea?

But THIS makes the difference instead :man_facepalming: Editor crash is gone even if I have 6.18.1 installed!

    // if working on Windows, disable searching of plugins unless explicitly set using
    // the env settings in the editor
    if (Application.platform == RuntimePlatform.WindowsEditor || 
        Application.platform == RuntimePlatform.WindowsPlayer)
    {
        Csound6.NativeMethods.csoundSetOpcodedir(".");
    }

:partying_face:

@MoShang let me know how it goes with this new version!

Great work @giovannibedetti, I also noticed the crash with conflicting versions. In my case I just removed the one that ships with CsoundUnity because I didn’t need it. But your fix is good, it will stop the Csound library that ships with CsoundUnity from trying to access the system opcodes :slight_smile:

Awesome! @giovannibedetti I’ve updated my Unity project from U2021.3.27 to U2022.3.11 (the currently latest LTS version) and my scene is working perfectly both in editor and in a build on Quest 2. Sincere thanks!

2 Likes

I wonder why the sample rate and control rate are both set to AudioSettings.outputSampleRate, i.e 48000?
setting ksmps and kr doesn’t seem to work.

Correct, the sample rate of the project sets the sample rate and control rate of every CsoundUnity instance. It’s in the plans to modify this behaviour and give the user full control.
Any suggestion or help is welcome!
I’m super busy atm and I can’t help in the short term. But I promise it will be there at some point :sweat_smile:

Explicitly setting the sample rate in your .CSD file can lead to tuning problems as soon as the end user selects a different SR. This is the reason we override it. It’s simple enough to change in the CsoundUnity.cs script if you need to.