Add Support For More Platforms (iOS, Mac Catalyst, tvOS, Android)

[drasticactions]

This PR makes a few under-the-hood changes to how the runtime drivers are loaded and run, enabling support for more platforms that whisper.cpp supports, including iOS, Catalyst, tvOS, and Android.

To do this, I need to make some changes in how the runtime drivers were loaded, and add some new scripts:

• The current version assumes the libraries are dynamically loaded via whatever is in the runtime folder. While the default Whisper drivers are compiled as dynamic libraries, they don't have to be. You can create static versions and link them in. Moreover, if you did compile a version for a different platform, like iOS, the NativeLibraryLoader class would assume that it needs to load a driver and will throw since the platforms are not listed.
• To make this work, I made some changes.
  • I added new TargetFrameworks to the base library. Suppose you're running on iOS/Catalyst/tvOS/Android. In that case, you will need to have linked the library before running the app (Generally, you can't load dynamic libraries on those platforms.), meaning you can avoid loading it dynamically at all.
  • If you still want to load your driver anyway, you can use the overloads to add a path directly to the one you wish to load.
• In the NativeMethods class, I added a directive to change the Library name to__Internal for iOS and Catalyst, as the library is already loaded and linked, and this name is required for it to work.
• I removed the default Runtime folder from Whisper.net and created a new nuget, Whisper.net.Runtime, including a targets file and all the native libraries.
  • This was required, as the current version would dump runtime files into every project where it was referenced. That is not sustainable if you need to reference the base assembly in several projects. Still, it would cause some platforms like iOS and Android to break on compile since it would try to reference the libraries from other platforms in its output.
  • While this is a breaking change (Users updating to the new version containing this change would need the Runtime Nuget or their own library to load) IMO it's much more sustainable. It would make it much easier to add new platforms or try and update the library versions "out of band" from the one it was built against.
  • For users running a console app with a base TFM (net7.0, etc), if you include the Runtime nuget, it will function like the original library and dump the desktop libraries into the runtime folder.
• I've also written new scripts for building these runtimes and putting them into the Whisper.net.Runtime directory.
  • To build the iOS/Catalyst/tvOS/Mac libraries, run make apple. This will build all of the runtime libraries and lipo them into smaller linked versions.
  • To build Android, run make android
  • The other Powershell scripts are left in place, but I've moved the directory output to the new one I created.

I have an example of the nuget in action at https://github.com/drasticactions/Drastic.Whisper/tree/main/samples and https://github.com/drasticactions/Drastic.Whisper/tree/main/nuget

[sandrohanea]

Hello @drasticactions, First, I want to thank you for this amazing contribution. I cloned it locally and check a few more cases but overall, it looks awesome 😎

Really great work!

[drasticactions]

In terms of your CI, I'm not sure if the NativeBuild YAML works, but the Dotnet one , the way I wrote it, will only compile under Windows and Mac, because the apple TFMs (net6.0-ios, etc) are only supported there.

I introduced the TFMs because of the NativeMethods class and DllImport as it (AFAIK) requires the __Internal name for linked libraries on iOS platforms. If there is another way to make that work, I could change it back to be netstandard2.0 and 2.1. The targets file should still work fine as that's on the users project rather than the library itself to put the files in the right place, and with the flags I have it should work.

[sandrohanea]

I can fix remaining warnings (marked as errors in CI) in future PR (They were there even before but only these workloads identified them).

[drasticactions]

Thanks! For anyone reading this who wants to try it out now (As I'm not sure if you want to push a point release for this or wait for the next Whisper.cpp), you can create your own nugets with an updated version tag:

• Clone the repo
• On Mac, run make nuget
• On Windows, you can run the dotnet pack commands directly

nuget pack Whisper.net.Runtime.nuspec -Version $(VERSION) -OutputDirectory ./nupkgs
dotnet pack Whisper.net/Whisper.net.csproj -p:Version=$(VERSION) -o ./nupkgs -c Release

Replacing $(VERSION) with whatever you want to call it (Ex. 1.3.0.1).

Then you can install them locally, and update them to the newest version whenever that lands.

[sandrohanea]

Thanks again for this capability!

I was thinking to create a preview version 1.4.0.0-preview1 in nuget, so it will be easier to try it out for everyone :)

Will wait for the whisper.cpp to release 1.4.0.0 in order to create 1.4.0.0 as stable version.