Support Microsoft Windows ?

[chuoichien]

Sorry, is this plugin support microsoft windows ?

[sachaarbonel]

Some of my research notes on the subject. We could make FFI bindings to:
"ASIO is an audio driver protocol by Steinberg. While it is available on multiple operating systems, it is most commonly used on Windows to work around limitations of WASAPI including access to large numbers of channels and lower-latency audio processing.". This the design decision the cross-platform Rust library Cpal made.

[hacker1024]

I may attempt this.
@ryanheise, would using Windows code from Musikcube be okay? It has a BSD 3-Clause "New" or "Revised" License.

Musikcore supports gapless playback, so it looks like a good fit.

It's also written in C++, so if FFI bindings are done right, we could share the code between Windows and Linux (and even macOS, if it's better than AVPlayer).

[hacker1024]

I've looked at Musikcube / Musikcore a little more - the core is completely undocumented, but there's a plugin system. There exists a documented plugin that exposes a web server to interface with the core.

It shouldn't be too hard to modify the server to use Flutter platform channels instead of HTTP, and then all the plugin documentation will apply.

https://github.com/clangen/musikcube/wiki/remote-api-documentation

If we were to uses Musikcore, that leaves two choices:

• Use FFI and use the core library directly
• Use the platform channel method I just described

[ryanheise]

The Musikcore license still looks complicated to me since the individual decoders have separate license agreements (including the GPL). It's also not clear to me what the codec support is for each platform target. ExoPlayer is mentioned, for example, but ExoPlayer taps into hardware decoders that are available on device via the Android SDK, so I would probably expect to see a different set of codecs supported for each platform.

[hacker1024]

That's difficult, then.
On another note, Musikcore uses the Visual Studio build system on Windows. I've been trying to build a CMake script instead (since Flutter uses CMake), but it's proving difficult.

Unfortunately, there aren't many high-level C/C++ Windows audio libraries out there...
I don't think ASIO can decode codecs, and it definitely can't fetch and play stuff from the Internet. We'd need to either find a library to do those things, or do them manually.

[alexmercerind]

@chuoichien @ryanheise I made a little project here. It can play audio files on Windows 10 & Linux now. I'm ready to help add support for Windows to your this project, if you say. (I'm not pro however 😅).

I used miniaudio because it was only audio library with MIT license (even though it wasn't high level & initially I used closed source junk irrKlang). Right now it supports MP3, FLAC & WAV. For supporting more formats, I think I can write something using FFmpeg to convert audio stream to MP3 before playback.

I'm using MethodChannel instead of dart::ffi (even though I first used dart::ffi), but main problem came out that one still had to compile different dynamic libraries & change path while loading in Flutter project. But using MethodChannel makes installation simple as to just adding in pubspec.yaml.

@hacker1024, C++ libraries I agree aren't super user friendly, some are closed source, some are not openly licensed & some are too low level.

Thankyou @ryanheise 💝!

[ryanheise]

@alexmercerind great!

Perhaps the way to go is to use the federated plugin model. I wasn't really a fan of this model for my plugins since I had intended to write all of the platform implementations myself and I thought it would be a maintenance burden to have a separate plugin for each implementation and keep them in sync. However, I believe this model may actually be a potential solution to our license issue.

The LGPL is basically incompatible with iOS because iOS doesn't provide a way for users to install their own version of a DLL. There are ways you could get close by having a separate app to hold the LGPL code and then use IPC between the two apps, but as far as I can see the same developer needs to own both apps, so the user couldn't substitute the LGPL one and have the non-LGPL one use it. Android might be a bit more flexible with IPC but still it's not convenient for most users to have to install the LGPL'd component as a separate app.

However, Windows and Linux don't have this restriction with DLLs, so in theory we could have the Windows and Linux implementations have different sets of licenses, which will be easier to manage in the federated model.

[alexmercerind]

😃 Thankyou for your reply!

I'm understanding the situation & your problem with the management of the plugin right now.
But I don't know how can one can distribute the .dll or .so to the users. I think it will just even more responsibility of distribution & management of dynamic libraries as you said, if you decide to use federated model. I feel it will be difficult for both, you & user to setup dynamic libraries in the app.
Best way in my opinion is still to use the MethodChannel for a plugin instead of dealing with DLLs or SOs with dart:ffi. From the developer point of view, he just needs to mention the package in the pubspec.yaml & the plugin starts working, but I doubt dealing with pre-compiled .dll or .so will be difficult for an average Flutter developer.

Right now, in my plugin...
I'm using same C++ code for supporting audio playback in both Linux & Windows (I modified the CMakeLists a little). And same plugin is compatible with both Windows & Linux. You can try out... It will be pretty easy to add same code to your project as I tried to keep the method & class names close to your API.

I just wanted to help (if I can)... & sorry if any of my knowledge is incorrect. (I'm just 17. I'm learning everything by reading the documentation online) 😄

[ryanheise]

Just to be sure we're on the same page, section 6a of the LGPL reads:

Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.)

If any app developer uses ffmpeg in their app, then they must comply with this license, and this makes it difficult to "legally" distribute an app on the app store or play store where section 6a can't be fulfilled. That is why I do not accept any LGPL-licensed code in just_audio.

But, this issue only exists for mobile apps. Since we're talking about Windows and Linux, it is possible to meet Section 6a of the LGPL, so there is no problem using an LGPL'd library.

The federated plugin model makes it possible to keep the LGPL'd portion separate from the rest of the plugin so that the license files can be separate for each part. You can read about federated plugins here:

https://flutter.dev/docs/development/packages-and-plugins/developing-packages

[alexmercerind]

Great! It's good thing that we can separate licenses in federated plugin model. 😁

I just came to know that miniaudio already supports OGG aswell.
Only audio format that seems missing in my sight, is M4A. Both DASH & AAC do not work on miniaudio.

Possibly we might not need LGPL'd FFmpeg.

[ryanheise]

I've just had a look at miniaudio and I'm really impressed. Even though it has limited decoder support, I might use this for some other projects just for the mp3 decoder.

I didn't see OGG mentioned in the README.