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.

[hacker1024]

I'm not too familiar with the federated plugin architecture, but would it be possible to write two decoding implementations, each in their own federated plugin that connects to the windows implementation plugin?

One could use FFmpeg with the appropriate license, and the other could be a thin implementation that lets miniaudio do the decoding.

This way, users could choose whichever suits their needs. Abstracting the decoding would also make it easier to switch to something with a better license later, if needed.

(I need AAC, and I think it's a fairly popular codec for music streaming services.)

[ryanheise]

My understanding is that the app developer could choose one implementation among perhaps multiple alternatives. E.g. they could choose an FFmpeg implemention over another one. I am not sure what you mean by "federated plugin that connects to the windows implementation plugin" in that I don't think alternative implementations would talk to each other and you would only link one of them, but each implementation would link to the platform interface.

[alexmercerind]

@ryanheise I just noticed that you made a seprate dart file for the web platform. Can I do the same or embed the code in the original just_audio.dart (Making separate file will be easy for me) ?
I have to take a look at playing audio from network... My implementation is just simple & plays local files only right now.

I'm forking your project today & make a good PR soon, as Windows alpha support just came in.

[ryanheise]

Hi @alexmercerind , going forward the plan would be to use the federated plugin model mentioned above, so it wouldn't be a separate dart file as is the case for the web platform. But, you can try to get the windows implementation working in any which way, and then integration can wait until we sort out the federated plugin issue. I'll try to have a crack at it on the weekend.

[alexmercerind]

👋 @ryanheise,
I did a bit of stuff in my fork alexmercerind@e67d821c205e85aab789ba7523e8c9b663a7b682

All I did right now is add basic functionality (You can see your table in README). Adding things like changing playback speed, clipping, looping, playing from assets shouldn't be hard.
I also changed the main.dart of example to make it work on Windows. (Original main.dart is now main-original.dart for now).

I also changed the name of methods channel to match yours.

Ideally, it would've been great if Flutter team used C# in Windows like they are doing Java in Android etc. If it was C# I could help a lot more in terms of functionality (I still will) ... but they are using C++ for both Linux & Windows. And writing C++ isn't the most friendly thing when libraries are not great & native APIs look like this (I have no idea of this difficult mess).

😟 FFmpeg is hard...

It's very basic right now.

[alexmercerind]

Ah I forgot to say... Don't forget to save the miniaudio.h in the desktop folder of my fork before trying. Rest should go well for now.

[ryanheise]

Well done, @alexmercerind !

You can probably request c# support to the Flutter team (although it probably still won't make FFmpeg any easier to use ;-)

Is there an issue with checking the miniaudio.h file into Git?

[alexmercerind]

@ryanheise, 😃
No, there isn't any issue about miniaudio.h but if you add it then 95% of the code on this repository will be C. So...😅 I didn't add it.

[ryanheise]

I had forgotten how large that file is :-) I guess it is more like a library. What is the convention for adding dependencies in Windows and Linux plugins? Can it be tied into the build script in some way to automatically download the dependencies?

[hacker1024]

I am not sure what you mean by "federated plugin that connects to the windows implementation plugin"

@ryanheise
Perhaps "federated plugin" was the wrong terminology.
Is there a way to declare some sort of "decoder" interface, and have multiple plugins that can provide an implementation?

As in, a structure like this, where the developer can choose the decoder plugin:

                                  just_audio_windows_decoder_miniaudio
                                /
             just_audio_windows - just_audio_windows_decoder_ffmpeg
           /
just_audio - just_audio_android
           \
             etc...

just_audio_windows_decoder_miniaudio could use miniaudio to decode media, and just_audio_windows_decoder_ffmpeg could use ffmpeg.

just_audio_windows would then use the provided decoding implementation to decode media, and then play it with miniaudio.

[hacker1024]

Can it be tied into the build script in some way to automatically download the dependencies?

I feel like that would contradict pub.dev's policy:

It is central to this service that consumers of packages can trust that their dependencies do not suddenly disappear.

Downloading a source from another place would mean the plugin could break at any time, and it's out of pub.dev's control.

This seems to almost violate this part, too:

Thus, once a package has been published it cannot be unpublished or deleted.

[alexmercerind]

@ryanheise

Oh, when you push the package to the pub.dev just remove the miniaudio.h from the .gitignore... so that the miniaudio.h is present in the package. (You don't have to download on user's machine separately).
I'm doing the same in my flutter_audio_desktop & it works just fine.

There is not any specific way of adding the dependencies... I modified the CMakeLists to use the miniaudio.h from desktop folder. And I haven't really found any dedicated guide from Flutter yet for building plugins for Windows & Linux. All this stuff is completely written by reading the code of their engine & trial-error.

I'm not pro in any of C++ or Dart. Just doing my stuff.

[ryanheise]

@hacker1024 hmm, this is exactly the way that build scripts for Android and iOS/macOS work. If you depend on a large library like ExoPlayer, you do not embed the library into your git repo, you add the download URL in the build script so that it can be downloaded and cached. So I guess the question I'm asking is, what is the equivalent of this for Linux and Windows? It would not make sense to embed these large 3rd party libraries directly into every pub package.

[ryanheise]

I am not sure what you mean by "federated plugin that connects to the windows implementation plugin"

@ryanheise
Perhaps "federated plugin" was the wrong terminology.
Is there a way to declare some sort of "decoder" interface, and have multiple plugins that can provide an implementation?

As in, a structure like this, where the developer can choose the decoder plugin:

                                  just_audio_windows_decoder_miniaudio
                                /
             just_audio_windows - just_audio_windows_decoder_ffmpeg
           /
just_audio - just_audio_android
           \
             etc...

just_audio_windows_decoder_miniaudio could use miniaudio to decode media, and just_audio_windows_decoder_ffmpeg could use ffmpeg.

just_audio_windows would then use the provided decoding implementation to decode media, and then play it with miniaudio.

I suppose if just_audio_windows has a dependency on some other package just_audio_windows_decoder which in turn is a federated plugin, there might be a way for an app to specify the deeply nested dependency alternative for just_audio_windows_decoder with dependency overrides, although I'm not 100% sure. This is probably a good question for the Flutter team.

[hacker1024]

If you depend on a large library like ExoPlayer, you do not embed the library into your git repo, you add the download URL in the build script so that it can be downloaded and cached.

Right, but ExoPlayer and its own dependencies all come from the same place. It's unlikely that ExoPlayer's dependencies will go down. If you could upload the single file to pub.dev that would be fine, but it would need to be uploaded elsewhere, meaning the plugin (and all older versions) could break if that file goes down. I don't think they allow that kind of possibility in their policy.

[bdlukaa]

Hello everyone! I have made some progress on the Windows version on @libwinmedia's fork (https://github.com/libwinmedia/just_audio).

All the essential features (play, pause, seek, volume, speed and playlist) are supported.

Here's the Feature list compared to the other platforms:

Feature	Android	iOS	macOS	Web	Windows
read from URL	✅	✅	✅	✅	✅
read from file	✅	✅	✅	✅	✅
read from asset	✅	✅	✅	✅	✅
read from byte stream	✅	✅	✅	✅	(not tested)
request headers	✅	✅	✅
DASH	✅
HLS	✅	✅	✅
ICY metadata	✅	✅	✅
buffer status/position	✅	✅	✅	✅	✅
play/pause/seek	✅	✅	✅	✅	✅
set volume/speed	✅	✅	✅	✅	✅
clip audio	✅	✅	✅	✅
playlists	✅	✅	✅	✅	✅
looping/shuffling	✅	✅	✅	✅
compose audio	✅	✅	✅	✅
gapless playback	✅	✅	✅		✅
report player errors	✅	✅	✅	✅
handle phonecall interruptions	✅	✅
buffering/loading options	✅	✅	✅
set pitch	✅
skip silence	✅
equalizer	✅
volume boost	✅

@alexmercerind, thanks for building libwinmedia, used on the windows version.

@ryanheise Do you think this would fit in a PR?

[ryanheise]

Awesome, @bdlukaa ! Would someone who has Windows like to test this?

In terms of a PR, the beauty of the federated plugin model is that you don't need my approval, you can hold just the windows implementation in a separate repository and publish it as a separate package so long as it conforms to the just_audio platform interface (and ideally follows some package naming conventions that we agreed on above -- just_audio_nativelib_platform.)

[bdlukaa]

@ryanheise good to hear!

I will publish and maintain the windows plugin, and whenever I do some changes I'll do a PR upgrading the just_audio_windows version. Sounds good?

[ryanheise]

Sounds good, just note the package name as mentioned above (since we will possibly have multiple different windows implementations based on different native libraries), and also if maintaining a separate package, your git repository only needs to contain the windows implementation since your pubspec.yaml will point to the hosted version of just_audio_platform_interface.

[bdlukaa]

Okay! I am thinking of adding the Linux (and UWP support in the future) support too, since libwinmedia supports Linux as well!

[alexmercerind]

@bdlukaa

Okay! I am thinking of adding the Linux (and UWP support in the future) support too, since libwinmedia supports Linux as well!

libwinmedia already supports Windows & Linux itself, and there is no big deal in it. Infact, I just wrapped WebKit GTK instance to play media (ON LINUX ONLY), so essentially its just a <audio> tag (which in turn uses GStreamer). I implemented playlists aswell, within C++ itself.
Biggest thing you forgot to mention is that, libwinmedia only supports later versions of Windows 10 (v1703+).
"UWP support", there is nothing UWP/win32 in bare audio playback, libwinmedia already uses modern UWP (WinRT) APIs.

@ryanheise

Would someone who has Windows like to test this?

libwinmedia is part of Harmonoid project & internal dependency for playback on Windows & Linux. So, everything is being used in Harmonoid app, thus tested.

Sounds good, just note the package name as mentioned above (since we will possibly have multiple different windows implementations based on different native libraries), and also if maintaining a separate package, your git repository only needs to contain the windows implementation since your pubspec.yaml will point to the hosted version of just_audio_platform_interface.

libwinmedia is mainly a C++ library, and I had to create a basic Flutter package (FFI bindings) to power Harmonoid. A simple package can be enough (with no native code) or just use existing libwinmedia.dart (which Harmonoid uses) pub.dev dependency as @bdlukaa did above. I have no platform channel interface.
A lot of features are only implemented for Windows and not for Linux. Few things need testing, I can't do this alone. It's rather large thing to do. Would appreciate if community decides to expose more WinRT APIs.

audio_service

Apart from just_audio, libwinmedia is also capable of adding support to audio_service aswell, I exposed System Media Transport Control APIs aswell. Everything is well documented, examples are present on the repository. For Linux, there is already a MPRIS library.

So, I'll be glad if libwinmedia powers that.

Why libwinmedia ?

I was just tired of libVLC's large size & other options being either too weak or just very strictly licensed. Thus, I created my own C++ library. Linux implementation can be made to use GStreamer instead which will be a lot better than starting a WebKit webview.

Why not libwinmedia ?

You can yourself use C++/WinRT APIs (very much like C# to be honest, since it is a projection of those) instead of having another libwinmedia abstraction. libwinmedia's main goal was:

• To expose those modern WinRT APIs in a more standard & classic C-like API (for consumption with Dart FFI).
• To circumvent the current limitations in Dart FFI, by making my own custom "throw-in and works" DLL.

Features list

Most features mentioned in that list are already supported by WinRT APIs (and a lot more), its just that I didn't expose them all.

P.S. there really needs to be some discussions tab or discord to talk about just_audio or audio_service in general.

[ryanheise]

Windows support is now published with features and instructions listed in the README. All credit goes to @bdlukaa for the federated plugin implementation and @alexmercerind for libwinmedia. Awesome work!

I'll leave this issue open for a bit and so please post below if you encounter any serious issues. Once immediate issues are resolved, I'll close this issue and just_audio_libwinmedia can be used to report any future issues.

[bdlukaa]

I have tested it on my production app and it works as good as it should!

[bdlukaa]

I tried my best to implement all the features. Here's the features that can't be supported on Windows at all:

• set pitch ( I don't know if this is possible using some effect listed down below)
• Simultaneous downloading+caching (I haven't found any docs about this, maybe it's on by default)
• skip silence

Here are the options that are supported by Windows, but aren't implemented yet:

• read from byte stream
• request headers
• ICY metadata
• clip audio
• compose audio (I haven't tested this, but it may work)
• Background
• report player errors
• Effects
• Casting
• SilenceAudioSource (just don't play anything maybe?)
• FFT (Probably can be supported using AudioGraph)

Effects

Name	Index	Description
AcousticEchoCancellation	1	An acoustic echo cancellation effect.
AutomaticGainControl	3	A automatic gain control effect.
BassBoost	8	A bass boost effect.
BassManagement	13	A bass management effect.
BeamForming	4	A beam forming effect.
ConstantToneRemoval	5	A constant tone removal effect.
DynamicRangeCompression	17	A dynamic range compression effect.
EnvironmentalEffects	14	An environmental effect.
Equalizer	6	A equalizer effect.
FarFieldBeamForming	18	A far-field beam forming effect.
LoudnessEqualizer	7	A loudness equalizer effect.
NoiseSuppression	2	A noise suppression effect.
Other	0	Other.
RoomCorrection	12	A room correction effect.
SpeakerCompensation	16	A speaker compensation effect.
SpeakerFill	11	A speaker fill effect.
SpeakerProtection	15	A speaker protection effect.
VirtualHeadphones	10	A virtual headphones effect.
VirtualSurround	9	A virtual surround sound effect.

[ryanheise]

Nice, it looks like there's a lot of potential, and it's good to know that ClippingAudioSource can be supported which I think is the last core feature that is conditionally disabled from example_playlist.dart.

Some of those features you mentioned like caching and byte streams are currently handled in the Dart layer so shouldn't those work already? In both cases, just_audio sets up a proxy web server to implement the features, and then instead of getting the platform side of the plugin to play the original URL, it passes the proxy URL instead.

[bdlukaa]

just_audio sets up a proxy web server to implement the features

I didn't know that. So you're saying that byte streams should be working?

[ryanheise]

Yes, I would have expected this to work. One way to test it could be the caching example which uses a stream audio source under the hood, and that should activate the local proxy on all platforms except web.

[bdlukaa]

Hello everyone! As you all know, just_audio_libwinmedia was the option used to play audio on Windows, but there are several limitations when using libwinmedia.

While I was on my days off, I worked on a fully native implementation for windows that is working. Check it out on just_audio_windows. It isn't published to pub.dev because I'd like to know @ryanheise's opinion on endorsing the project.

If you'd like to try it, you can add it as a dependency to your project. No extra setups required:

dependencies:
  just_audio_windows:
    git:
      url: https://github.com/bdlukaa/just_audio.git
      path: just_audio_windows/

Note that this is an early version with only a few features (most important ones) implemented, but example/main.dart works as expected. Contributions are welcome!

[ryanheise]

I like the direction of this - I noticed it doesn't have a license yet, is that decided?

I'll just mention again that since I'm on Linux it is something I will need to rely on others to test.

From here, let's get some people trying out just_audio_windows. If it works for testers, let's publish it and get it advertised in the just_audio README where it will have more eyes to detect more bugs and help reach maturity.

Once it reaches maturity, we can start looking at the endorsement process which should include some quality assurance that is consistent with the Flutter Favorites programme. A key requirement I would have is to ensure that semantic versioning, as interpreted by pub.dev, is observed. This should guarantee that an update to just_audio_windows doesn't cause just_audio to break its own Flutter Favorite obligations via its transitive dependencies.

[bdlukaa]

@ryanheise cool! I'll be looking forward to implement all the missing features and fix bugs. I'll let you know when it gets in beta <3

[bdlukaa]

@ryanheise Hello! just_audio_windows is finally in beta. This means that the example/main.dart works completely. Playing, pausing, seeking, speed, volume and pitch are working properly. Also, you can use the play/pause button from the keyboard, and the app will update properly (thanks to the data event channel)

Next step is to impement playlists, documentated here.

just_audio_windows uses UWP's native MediaPlayer (winrt). This was chosen over the win32 because it's more recent. Also, Flutter deprecated support for Windows 7 and 8. UWP also works on X Box, targeting this device as well. UWP's MediaPlayer is a lot easier to use than the win32 one, with less boilerplate code.

LMK your toughts on endorsing the windows implementation once fully implementated.

In case anyone wants to try it, add the following to your pubspec.yaml;

dependencies:
  just_audio:
    git: https://github.com/bdlukaa/just_audio.git

[ryanheise]

Awesome!

Can people using Windows test this and let @bdlukaa know how it goes?

Of course I'd be happy to endorse it once it becomes stable, and in the meantime I should definitely update the README with instructions on how to use it by adding the explicit dependency.

[jmshrv]

This is great news, that only leaves us with Linux :)

For Linux, I've wanted to make a GStreamer package for a while but never got around to it, and I doubt it could be endorsed due to GStreamer's LGPL license (unless it doesn't really count since you wouldn't statically compile GStreamer?)

[ryanheise]

Actually I don't know if there really is a problem endorsing a federated plugin implementation for Linux licenced under the LGPL. An LGPL library does not require the package linking that library to itself become LGPL The issue with LGPL for Flutter apps has specifically been the dynamic linking clause which is incompatible with the iOS and Android app stores. However, when building for those platforms, the Linux implementation would not be linked anyway.

If I am wrong about that, it is no big hassle to simply provide instructions in the just_audio README for how to manually add an extra dependency for the Linux implementation. I actually prefer this over endorsement because it's really not too difficult an imposition on the app developer to add one line to their pubspec.yaml, and it also protects the main plugin should anything ever break in the future.

[ryanheise]

Hi @UnicornsOnLSD , have you seen the latest comments on #332 regarding GStreamer? Let's discuss over in that thread.

[ryanheise]

@bdlukaa Ii am updating the main README to point to this new Windows plugin. Since your plugin is now in beta, would you consider publishing the beta on pub.dev using appropriate semantic versioning for a beta prerelease?

[bdlukaa]

Sure! https://pub.dev/packages/just_audio_windows.

To use it, just add it to your dependencies:

dependencies:
  just_audio:
  just_audio_windows:

[bdlukaa]

Hi everyone! I'm glad to announce that just_audio_windows now has support for playlists (thanks to @chengyuhui - bdlukaa#8) in the latest version. Check it out!

[ryanheise]

Awesome! @chengyuhui out of curiosity, is it gapless?

Regarding concatenatingMove, if it's gapless, the iOS implementation might be a good basis for inspiration, but if it's not gapless, the web implementation might be more similar. For gapless, the idea was to handle all playlist reorderings through a single function (enqueueFrom) which covers all cases including adding, removing and moving. enqueueFrom is then a central place to first compare the old order to the new order and see if the "current item" would still be the same. If it is the same, we try not to interrupt its playback so the sound continues coming out smoothly.

[kmod-midori]

Yes, based on https://learn.microsoft.com/en-us/windows/uwp/audio-video-camera/media-playback-with-mediasource#play-a-list-of-media-items-with-mediaplaybacklist.

I will try to look into the iOS implementation to see how this can be done, though I don't really speak Objective-C :)