support github actions for the asio-juce branch

[wkpark]

This is based on the recent obs-ndi work

• .github/* files are imported from the obs-plugintemplate
• fetch the JUCE and the asio-sdk sources on the fly.
  • JUCE lib v7.0.2 (from github)
  • ASIO-SDK(v2.3.3-2019-06-14) from Steinberg SDKs (Please see https://www.steinberg.net/developers/)
• misc fixes added to make it work with the Actions flows
• support OBS 28 now

you can download this obs-asio prebuilt from the following link:
https://github.com/wkpark/obs-asio/actions/runs/2996020467#artifacts
https://github.com/wkpark/obs-asio/actions/runs/3017510916#artifacts
https://github.com/wkpark/obs-asio/actions/runs/3019152627#artifacts
https://github.com/wkpark/obs-asio/actions/runs/3019464346#artifacts

[Andersama]

Hey just a heads up, Wizard and I are likely to get around to this over the weekend, but there needs to be a couple changes. For licensing problems with the steinberg sdk you'll want to try to automate the build against: https://github.com/Andersama/JUCE/tree/open_asio_juce

Shouldn't require the steinberg sdk, also if possible squash all your commits into one (if not we'll likely end up doing that anyway).

[wkpark]

Hey just a heads up, Wizard and I are likely to get around to this over the weekend, but there needs to be a couple changes. For licensing problems with the steinberg sdk you'll want to try to automate the build against: https://github.com/Andersama/JUCE/tree/open_asio_juce

OK. now the openasio_sdk support fix has been cherry-picked manually and applied.

Shouldn't require the steinberg sdk, also if possible squash all your commits into one (if not we'll likely end up doing that anyway).

and many fixes have been rebased to show this PR briefly (might be rebased again after all hunks are reviewed carefully, as you wish.)

New builds are available here:
https://github.com/wkpark/obs-asio/actions/runs/3016880635#artifacts

[Andersama]

Ah I forgot I had to modify Juce furthur, @wkpark the kAsioCanReportOverload value we never found, we only found a reference to the name*. Do you have a source for where that value came from that isn't from the steinberg sdk? I think that would bring the openasio wrapper into full compatibility with the asio standard because I think that was the only thing missing. It also might be the the source for some people's issue with crackling / popping.

Worst case I remove the conditional check which is how the plugin was originally built.

Second, does the FetchContent_Declare cmake thing not work for building a branch of juce directly? I'd rather just do that over having bash / shell scripting to move things around.

[wkpark]

Ah I forgot I had to modify Juce furthur, @wkpark the kAsioCanReportOverload value we never found, we only found a reference to the name*. Do you have a source for where that value came from that isn't from the steinberg sdk? I think that would bring the openasio wrapper into full compatibility with the asio standard because I think that was the only thing missing. It also might be the the source for some people's issue with crackling / popping.

I've found kAsioCanReportOverload at
https://fossies.org/dox/lmms_1.2.2/asio_8h.html#adc29c2ff13d900c2f185ee95427fb06caecc90f364253d8c306dc720c9604d6c0
(and it seems this const added a recent version of the SDK.)

Second, does the FetchContent_Declare cmake thing not work for building a branch of juce directly? I'd rather just do that over having bash / shell scripting to move things around.

you mean the prepare.sh?
undefined kAsioCanReportOverload prevent me to build with https://github.com/Andersama/JUCE/tree/open_asio_juce

I've just seen your last fix so I'll fix/rebase it soon again.

[Andersama]

Unfortunately that link won't work as a source, it's a doxygen doc of the steinberg sdk. Dead give away is that I've seen plenty of doxygen docs of the thing and the reference to "iasiodrv.h". Funny I played around with carla for a while because it was a pretty ok asio host, although it had some issues. Originally, 5 or so years ago pkv and I spent about 3+ days trying to reverse engineer the asio header for just this reason. Pretty confident that was the only thing missing because I vaguely remember making the same edit to build Juce.

In short, good luck finding a source for that value that isn't the steinberg sdk, if you do, let me know, but don't worry I made that edit before so if that edit introduces a bug, that's been on me the entire time.

[wkpark]

I've just seen your last fix so I'll fix/rebase it soon again.

This is the last build. https://github.com/wkpark/obs-asio/actions/runs/3017510916#artifacts

[Andersama]

Unless I'm mistaken you don't need the ENABLE_OPENASIO_SDK option, that's sort've what I was aiming for.

[Andersama]

@wkpark sorry, I ended up force-pushing to your branch instead of mine (I'll try to restore it later), if you'd like make sure you create a new workflows branch as a backup*.

Edit: I restored your original branch on my end, Wizard and I will be going through it later (we'll do the squash which'll keep you as author).

[wkpark]

no problem.
Thanks for your concern! :)

This PR closed by commit cef5c61