Example HTML pieces for the Csound for Android app not all working

[gogins]

• [x] Remove examples from the csound-android repository, and copy them directly from the csound-examples repository. I put them in as a submodule, and copy only needed stuff into the assets directory.
• [x] message.html works.
• [x] player.html works.
• [x] scrims.html, csound_loader.js is not found. Added the loader to the directory.
• [x] trichord_space.html, needs to be added to Examples menu, crashes. Now fixed, see below.

[gogins]

Interoperability between the Web, NW.js, and Android is tricky. Here are the issues:

1. Csound.Message. CsoundOboe on Android doesn't have a working Csound::SetMessageCallback function. On Android it does seem to work to do this: console.log = csound_message_callback. _I have modified the csound_loader.js script to do this (only on Android)._
2. Loading WebAssembly asynchronously. This has to happen before any scripts running in a Web page or other JavaScript context attempt to dereference the Csound object. It is best to declare Csound and probably some other things as var near the top of the page and then set them in async/wait constructs before anything else happens.
3. API inconsistencies. CsoundOboe on Android does not have the post-production facilities.
4. There is a name collision. If the Csound object is declared as var in a piece, then it clobbers the Android csound object. For this reason, all pieces should use another name for the Csound object, such as csound_.
5. Pieces for NW.js can use the filesystem, and so can pieces that use the WebAssembly build of Csound, but the way the filesystem is initialized is different. To enable pieces to run on both platforms, this polyfill can be placed at the top of the JavaScript:

       <script>
           var csound_ = null;
           try {
               var fs = require("fs");
               var __dirname = fs.realpathSync.native(".");
           } catch(e) {
               console.log(e);
           }
       </script>

[gogins]

I have verified that the Csound for Android app does recursively copy everything required to run the examples onto device storage in the Music directory.

[gogins]

The app does not reliably render HTML pages after loading an HTML piece.

[gogins]

Starting twice?

2021-01-17 11:40:19.432 18829-24620/com.csounds.Csound6 D/CsoundOboe:: Current CPU ID is 4.
2021-01-17 11:40:19.432 18829-24736/com.csounds.Csound6 D/AudioTrack: stop(130): called with 0 frames delivered
2021-01-17 11:40:19.432 18829-24620/com.csounds.Csound6 D/CsoundOboe:: Thread affinity set.
2021-01-17 11:40:19.432 18829-24620/com.csounds.Csound6 D/CsoundOboe:: new alloc for instr Controls:
2021-01-17 11:40:19.433 18829-24620/com.csounds.Csound6 D/CsoundOboe:: Controls       i   17.0000 t    0.0000 d   -1.0000 k    0.0000 v    0.0000 p    0.0000
2021-01-17 11:40:19.433 18829-24620/com.csounds.Csound6 D/CsoundOboe:: new alloc for instr SolinaChorus:
2021-01-17 11:40:19.433 18829-24620/com.csounds.Csound6 A/libc: stack corruption detected (-fstack-protector)
2021-01-17 11:40:19.448 18829-18829/com.csounds.Csound6 I/Csound:: CsoundOboe::Start...
2021-01-17 11:40:19.452 18829-18829/com.csounds.Csound6 I/Csound:: displays suppressed
2021-01-17 11:40:19.456 18829-18829/com.csounds.Csound6 I/Csound:: 0dBFS level = 15.0
2021-01-17 11:40:19.459 18829-18829/com.csounds.Csound6 I/Csound:: ftable 101:
2021-01-17 11:40:19.463 18829-18829/com.csounds.Csound6 I/Csound:: ftable 102:

[gogins]

Error in oboe now:

NDK 22.0.7026061

That was it. The version of the Oboe code that we include in JUCE isn’t compatible with the latest NDK version so we needed to update it. We’ve added this to develop here:

[gogins]

There's another possible Oboe library issue: https://github.com/google/oboe/releases/tag/1.4.2.

[gogins]

I don't get this: message.html plays but scrims.html and trichord_space.html crash on Play. Possible causes:

• [x] Excess memory use (I think I have ruled this out).
• [x] Usage of CsoundAC.js in an Android WebView. Looks OK.
• [x] Inconsistent threading logic. No.
• [x] Did the use of oboe callbacks for both input and output break recently? The Oboe examples use synchronous reads inside callback writes. No.
• [x] Failure of the alwayson opcode on Android. _Replaced with scorelinei and fixed long duration. No help
• [x] Failure of f 0 3600 on Android. _Replaced with scorelinei and fixed long duration. No help.
• [x] The csound_loader.js logic may be faulty on Android where the page is reloaded on Play. I will inspect the variable in the debugger. Looks OK.
• [x] Change of C++ standard to C++14 for Oboe. No help.
• [x] Debug native code. Crashes on first call to sensevents in first call to csoundPerformKsmps. The actual crash appears to be in the sprints opcode, which doesn't seem completely conformant with "C" in Android. This crashes on Android but not in native or WebAssembly code:

  prints      "%-24.24s i %9.4f t %9.4f d %9.4f k %9.4f v %9.4f p %9.4f #%3d\n", nstrstr(p1), p1, p2, p3, p4, p5, p7, active(p1)

• [x] Compare csound_message_callback code, see if there is a stack overflow. No help.

[gogins]

The Google Oboe library has several times recently changed how references to open streams are handled. It seems the latest thing is to use std::unique_ptr which deletes the stream when it goes out of scope.

_Not so, I checked the current code and my std::shared_ptr is correct._

Maybe https://github.com/google/oboe/issues/1126.

[gogins]

What a wild goose chase. On other platforms, for the prints opcode, "%-24.24s" works, on Android it crashes but "%24.24s" works. This is a Csound bug but omitting the left justification is an acceptable workaround.