Yeah, I commented everything out there, it still persists.
I also commented out:
csoundReturnCode = csound->CompileCsdText(csdText.c_str());
csound->Start();
So it’s probably not csound?
Cabbage FMOD Android .so support
Ah no it is…
After commenting all code out which does ->GetCsound() including:
int result = ((FMODCsound*)dsp_state->plugindata)->CompileCsound(csdFilename);
It doesn’t crash anymore.
Since this I’m trying now to selectively uncomment and test, but so far, every uncomment results in a direct appcrash on scene load. (Except for all inside CompileCsound() which isn’t called anyways then.)
So, I can uncomment everything except the calls in void FMODCsound::generate which are:
csoundPerformKsmps(csound->GetCsound());
and
csoundInput[chans + position] = *inbuffer++;
*outbuffer++ = csoundOutput[chans + position];
And in the dsp create the one I mentioned above.
And I also checked the same thing with non android csound. There it behaves exactly the same. So maybe there is something wrong with how androidcsound is used.
Clearly the problem. Now how to fix that. You should be compiling for 64 bit Android which is what the Quest uses. Is that set somewhere in your project settings?
Yes, I’m compiling for arm64. Also the linked csoundandroid is 64 bit. I made this mistake before and it would produce an error in Unity of incompatible architecture.
But I just found out that it doesn’t complain when using csound in code but linking csoundandroid.
I’ll just try and link the windows version even though this probably doesn’t make much sense.
Edit: this doesn’t work because one is .lib and one is .so, so Android is needed of course.
But it’s just interesting that both Csound and CsoundAndroid are contained in this library, the latter probably building on top of the first one.
As you’ve worked out, this won’t work. Your plugins needs to use the Csound Android .so on Android.
Csound and CsoundAndroid are effectively the same library, one is compiled for desktop and the other for Android. That’s why you should be able to use the same code more or less for both interfaces.
If you comment out this:
csoundInput[chans + position] = *inbuffer++;
*outbuffer++ = csoundOutput[chans + position];
but leave in the performKsmps call does it still crash?
That makes very much sense!
Do you mean with the int result one also commented out?
When having this commented, uncommenting either of the ones in the generate function are making it crash on scene load.
But I’ll double check later.
Can you comment all mention of csoundOutput and csoundInput, i.e:
csoundInput = csoundGetSpin(csound->GetCsound());
csoundOutput = csoundGetSpout(csound->GetCsound());
And any other places they appear. Then leave in the rest of the code and see if it still crashes.
Unfortunately it still crashes. As soon as I activate the int result of DSP_Create, it crashes after those 10 seconds, when having commented out everything.
If I uncomment either perform Ksmps or the other two csoundInput or output and even all together, it crashes on sceneload.
Interesting there is that FMOD is trying to allocate more memory until it runs out (for all possible possible combinations the same result in the console (each one at it’s own uncommented and two of them and all of them)).
As soon as I uncomment the int result line, it doesn’t crash immediately but after those 9-10ish seconds.
I now also tried leaving in and output uncommented (in the csoundcompile and generate function), with no different results.
Ah, I just extended the debugpossibility with logcat which is available as a package for unity. This is way more readable than the monitor and gives new errors.
In those cases where FMOD is increasing the buffer, there is an error of the FMOD mixer thread:
2021.07.17 19:22:46.601 11386 11635 Error CRASH pid: 11386, tid: 11635, name: FMOD mixer thre >>> com.DefaultCompany.FMODPlugTestAndr <<<
2021.07.17 19:22:46.601 11386 11635 Error CRASH uid: 10111
2021.07.17 19:22:46.601 11386 11635 Error CRASH signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
2021.07.17 19:22:46.601 11386 11635 Error CRASH Cause: null pointer dereference
Unfortunately those CsoundAndroid Callbacks are still not coming in… but I’ll investigate more.
One more update, if i add to :: in front of the vsnprintf in the Android Message Callback Function, it finally works with the callbacks…
This is what I get when having the 10s configuration:
2021.07.17 19:55:15.866 13932 14049 Info AndroidCsound setOpenSlCallbacks
2021.07.17 19:55:15.866 13932 14049 Info AndroidCsound ==set callbacks
2021.07.17 19:55:15.866 13932 14049 Info AndroidCsound ==callbacks set
When uncommenting everything or selectively so it crashes on scene load don’t produce any callbacks. But maybe there are now additional debugg methods? Otherwise I don’t really have an idea what else to try…
With this debuging I also found out where the .so is located which will make it easier to locate the csd file in the assets folder, when we succeed with this.
I hope, we’ll get there though.
I just thought of a possible workaround for this. To avoid all this hassle could you use FMOD and CsoundUnity? You can stream audio from FMOD into CsoundUnity and back again? I know it won’t be as streamlined, but it gives you direct access to Csound?
Mh, that would certainly bypass those complications now, but I have no idea how to handle audio-streams from FMOD yet. Convenient automation in combination with my exitsting events and scripts would also be much more complex with reading them out from fmod and linking them to csound, which is easy but still a bit of a hackery.
But I could understand quite well if you said, that you don’t have the capacity to invest more into finding a .so-lution (haha… ^^). You’ve already helped me more than I would have ever anticipated, thank you so much!
But I’d love to get this working also for future projects. I’ll try some more with the new debug possibilities and would write here, if I’d find something nontrivial.
I just post here the logs from csound which are displayed when getting the 10 second crash setup with int result uncommented and the generate function commented.
2021.07.18 21:41:05.915 4617 4741 Info AndroidCsound STARTING FILE
2021.07.18 21:41:05.915 4617 4741 Info AndroidCsound Creating options
2021.07.18 21:41:05.915 4617 4741 Info AndroidCsound Creating orchestra
2021.07.18 21:41:05.915 4617 4741 Info AndroidCsound closing tag
2021.07.18 21:41:05.915 4617 4741 Info AndroidCsound Creating score
2021.07.18 21:41:05.915 4617 4741 Info AndroidCsound displays suppressed
2021.07.18 21:41:05.915 4617 4741 Info AndroidCsound 0dBFS level = 1.0
2021.07.18 21:41:05.915 4617 4741 Info AndroidCsound orch now loaded
2021.07.18 21:41:05.915 4617 4741 Info AndroidCsound audio buffered in 2048 sample-frame blocks
2021.07.18 21:41:05.915 4617 4741 Info AndroidCsound not writing to sound disk
2021.07.18 21:41:05.915 4617 4741 Info AndroidCsound SECTION 1:
2021.07.18 21:41:05.915 4617 4741 Info AndroidCsound ftable 1:
2021.07.18 21:41:05.915 4617 4741 Info AndroidCsound new alloc for instr 1:
As I said it doesn’t even sound and this doesn’t look too bad even though, the last three seem like empty messages, but that’s maybe normal.
Interesting now is, that I’m getting the memory error also when commenting out the int result and generate function but leaving the csound-debugstuff in. So it’s probably a problem of csound itself.
I’ll leave it for now and focus on other stuff.
If there are any more things, I could try out, I would be happy to know, but I see, that’s probably something deeper inside csound which isn’t working together with all this…
If I get some time during the week I can try and set up an Android dev system for this. I probably should set one up anyway…
That would be amazing!
Can you zip your entire VS project folder and upload it somewhere for me? Might be good also to get your test Unity project.
I think I’ve managed to get as far as you in terms of getting the project to build in VS. So perhaps all I need is a test Unity project now.