No, sorry. Just the logging of the realtime and the ksample time are in sync.
It always crashes.
When I set the sr=22050 it crashed on 120 seconds (ksmpstime) and when I didn’t write anything it probably defaults to 44100 so it crashed at 110 (ksampstime).
Cabbage FMOD Android .so support
Is there some way you can check what the default SR is for FMOD/Unity on Android?
After some research, I still not quite get how the samplerate works in FMOD in combination with different hardware.
I can set different samplerates or take the system default, but I haven’t found out yet, how to retrieve that information.
There’s another debuglog from AudioStreamTrack which sets always a Sr from 0 to 48000 Hz, no matter what I enter as option.
When setting 48000 in the FMOD settings and in Csound, it also “syncs” the ksmps. But I haven’t yet made enough testing to be sure whether this is really connected.
I’ve tried anything now, what was in my mind without success.
I managed to make the csd file load from file and use the compile function. Just to try whether the compilecsdtext was a problem. It isn’t. At least I’d have a solution now, to read the file. (It’s totally hacky and not elegant… by writing the file into persistent data and then passing this filepath to the plugin).
The channel keeps breaking… do you maybe have another guess or know someone who could know, what the problem might be?
Try calling
csound->SetHostImplementedAudioIO(1, 0);
before compiling Csound. In case that doesn’t work let’s ping @giovannibedetti, he put together the Android interface for CsoundUnity. He might know what’s going on.
For @giovannibedetti’s sake here is a quick summary
- @JFuellem can get the FMOD plugin compiling and running on Android, but it crashes after a short time. We’ve been over the usual suspect, the spout/spin pointers, the float version stuff, file resources, etc. Changing the sample rate seems to affect how long it runs for. The basic FMOD plugin examples seem to work fine on Android so we don’t think the problem is there.
If the suggestion above doesn’t work, we’re fresh out of ideas. 
Thank you! I’ll try that today.
Thanks also for the summary.
A little correction. The samplerate doesn’t change how long it runs for, just how fast the ksmps timer counts. This affected the pitch of the synth for example like discussed in another post.
I have no clue, what exactly is affecting the crashtime.
One factor is the architecture. It lasted the longest when I chose both arm7 and arm64.
There are other factors too. While I was experimenting with the loading of the csd file, it always varied in length. But I didn’t pay too much attention there unfortunately. But building the same build or relaunching the app makes it crash after the same time.
I have the assumption that it has to do something with gc allocation or something else memory wise, but I know too little there and have to look at this more. It just raises slowly over time and I think crashes always at 0.8mb (I have to check this also again) but this is now just a new thought.
Yes! That’s it. It always crashes on GC collection. Disabled it and it doesn’t crash anymore. So it disposes something needed or some other problem with it. Maybe something is freed that is needed or it has to do with unmanaged part of the code. Csound is probably unmanaged? (I have no experience).
I don’t know why I didn’t find this earlier… but very happy to finally know where the issue is! 
This seemed to happen also here.
I have more questions than solutions though… do you have an idea of a pointer which could potentially point to an illegal address? Maybe I’m following the wrong route, but it’s defenitely crashing everytime garbage collection is doing it’s thing (also when called manually at different times).
Did you add the csound->SetHostImplementedAudioIO(1, 0);? I mentioned it because we had issues with CsoundUnity before adding it.
It might be that the GC is trying to clear memory that Csound is using, which causes the take down. I’m not sure. In the past I’ve had issues with the Csound spin.spout pointers. I suggesting removing the calls to those at some point but it still seems to crash. Is the FMOD plugin playing from the get go, or is it restarted at some point? It might be that restarting is the problem as it involves a recompile of Csound. I’ve seen problems before where Csound hasn’t been able to completely free its resources for some reason or another. I’m running out of straws to clutch from 
Yes, I’ve added it without any noticeable effect…
The fmod bank gets loaded right at the beginning in a default manner, the event, I’m starting at 5 seconds and is several minutes long.
The app crashes both when calling gc before those 5 seconds and after, so it hasn’t to do with any instrument or something with the compiled csd.
As soon as the plugin is loaded, at the fmod init I’m assuming or maybe at bank loading (I haven’t tested that but makes not really a difference), the app crashes on gc.
This is really frustrating, because this seems to be just happening on android.
But as you got csoundunity running on android, we also know, that csound is able to run on android. There it is probably just differently tracked or however gc exactly works.
I’ll try again now at this point, experimenting with spin spout once more again with the things I know more now.
It could also be a problem with how fmod handles plugins. Here, we seen in the example script how to create fmod callbacks which have to be initialised in a way that they don’t get freed by gc and the data is somehow handled by a gchandler (I don’t really understand what’s happening in this script, even though I used it a few times). I’m assuming this is needed for a flawless communication. But it doesn’t smell like an easy solution from this direction.
I’ve now invested quite a lot in this now and don’t want to give up on it yet.
But maybe it would be better 
This is wrong… I don’t know why this happened yesterday. But today, GC collect works fine before the event is playing…
I’m able to trigger gc as many times as I want before, but as soon as the event is playing, it crashes.
In CsoundUnity all Csound we are not linking to Csound, but simply reading the dll/dylib/so for use at runtime. All calls to the library are managed. But in this context you link to the Csound library when building.
Is the GC a function of the FMOD API?
I’ve also tested a bit with commenting out again. But it’s difficult…
It often crashes with a backtrace to dspprocess and a nullpointer dereference error. I’d have to try more.
I always thought GC in Unity was automatic, and in most cases people never have to call the GC object directly? Are you being a little over zealous with the GC maybe? What happens if you never call it? I assume Unity will just do it itself.
Or have you arrived at the point whereby it crashes when Unity automatically calls it, so you’re now calling it manually to try to sort the issue?
Exactly, I’m able to disable GC. ( GarbageCollector.GCMode = GarbageCollector.Mode.Disabled; ) And then it doesn’t crash anymore and everything works. When calling GC manually, as soon as the event is running, it crashes. So it’s definitely connected to that.
No sorry. Once GC is disabled, manually triggering it doesn’t do anything, I forgot that.
But when it’s activated, I can either wait for Unity to trigger it and when it’s after the event started playing, it crashes or I can do it manually and it also crashes.
Right, I see. So sort the GC issue to win the game. Are any FMOD API callbacks triggered via the GC?
Yes, that would mean most likely mean victory.
I’m not using the FMOD callback system in this testproject. FMOD uses GChandles at a few points internally, I saw but not connected to callbacks.
If we’re not able to solve it, I’ll just disable gc for now and hope it doesn’t run out of memory. My game isn’t that large anyways so maybe that works.