It seems that if we specify some sfz (for example, Ixox Flute) sfizz freezes somewhere non-debuggable by lldb. It needs further investigation, but it so far blocks upgrading various bits (aap core, aap-lv2, sfizz itself).

Sfizz has some option to not depend on libsndfile (st_audiofile), which would make porting easier. If that works, then the big chain of dependencies can go away, which is a big win.

There is almost no actual failure details around, but the latest import does not complete run(), especially around resync_cc. It was why I have implemented ResizePort support, but even after its working allocation it seems to crash. It does not seem to be an isolatable culprit - commenting it out did not work.

logcat almost only reports SEGV and lldb only catches ASanDie() (when ASAN is enabled, of course no details without it either).

No difference between sfizz 1.2.0, 1.1.1 and 1.1.0.

Current aap-lv2-sfizz fails to load sfz from files (datadir directory). It is because we resolve files from assets (serd/lilv), as well as passing the asset path as bundle_path to lilv_plugin_instantiate(). The asset path (/lv2/sfizz.lv2/) is not equivalent to datadir (/data/data/... etc.), therefore the resources have to be resolved from file for aap-sfizz case, while the remaining LV2 ports should be based on assets (e.g. aap-fluidsynth).

There should be some way to make it conditional.

By default, if we use aap_metadata.xml which was generated from aap-lv2-metadata-importer, MIDI device instantiation fails with the error:

02:44:21.417  1891-1913  JavaBinder      org...n.samples.aap_sfizz  E  *** Uncaught remote exception!  (Exceptions are not yet supported across processes.)
                                                                       java.lang.AssertionError: Assertion failed
                                                                       	at org.androidaudioplugin.midideviceservice.AudioPluginMidiDeviceService.getPluginId(AudioPluginMidiDeviceService.kt:22)
                                                                       	at org.androidaudioplugin.midideviceservice.AudioPluginMidiDeviceService.getPluginId$default(AudioPluginMidiDeviceService.kt:17)
                                                                       	at org.androidaudioplugin.midideviceservice.AudioPluginMidiReceiver.onDeviceOpened(AudioPluginMidiReceiver.kt:37)
                                                                       	at org.androidaudioplugin.midideviceservice.AudioPluginMidiDeviceService.onDeviceStatusChanged(AudioPluginMidiDeviceService.kt:59)
                                                                       	at android.media.midi.MidiDeviceService$1.onDeviceStatusChanged(MidiDeviceService.java:60)

It seems to be due to some failure in plugin resolution by pluginId (sfizz vs. sfizz-multi).

(details TBD)

I need to a latest working LV2 SDK setup first but so far aap-sfizz crashes at process() (run() in sfizz LV2). It is due to insufficient atom buffer that sfizz_lv2_send_controller() fails to handle gracefully (it calls lv2_atom_forge_frame_time() which subsequently calls lv2_atom_forge_push() but returns non-OK, and thus skips lv2_atom_forge_pop() within the function, which causes inconsistent ATOM force stack.

It is for sure an inssue in sfizz but I'm not sure what is actually causing the insufficient buffer.

The latest import of sfizz triggered process()-time failure for some reason.

It seems that our resetPorts() in android-audio-plugin-lv2-bridge.cpp is receiving 20 from lilv_plugin_get_num_ports(lilvPlugin) which should return 23. AudioPluginServiceImpl receives 23 prepareMemory requests and prepare() correctly passes them. Only resetPorts() at process() time gets 20 instead.