No longer maintained packages in the readme

[KaJe5380]

To which pages does your suggestion apply?

• just_audio readme

Quote the sentences(s) from the documentation to be improved (if any)

Windows support is enabled by adding an additional dependency to your pubspec.yaml alongside just_audio. There are a number of alternative options:

• just_audio_windows
• just_audio_libwinmedia

Linux support is enabled by adding an additional dependency to your pubspec.yaml alongside just_audio. There are a number of alternative options:

• just_audio_mpv
• just_audio_libwinmedia (untested)

Describe your suggestion
just_audio_mpv & just_audio_libwinmedia have been marked as DISCONTINUED on pub.dev and
replaced by: just_audio_media_kit for Linux
replaced by: just_audio_windows for Windows.

just_audio_mpv's own GitHub no longer matches it's pub.dev readme, with the GitHub getting a new section 5 months ago:

In most cases, you probably should use just_audio_media_kit or raw media_kit instead. It's better made, better supported, much stabler, and it might even have more features.
...

just_audio_mpv & just_audio_libwinmedia should either be removed from documentation, or given parenthesis for no longer being maintained. Also adding just_audio_media_kit for Linux.

Would also need to see if Linux's Platform support list still matches with this new library.

Edit:

The mpv readme also suggests just_audio_media_kit. Have you tried it?

Didn't see this initially, but you actually seem to know about this package in issue #1199 about this package.

[ryanheise]

Hi @KaJe5380 , thanks for the request. Yes the plan is definitely link to just_audio_media_kit in the README, basically, to link to all federated implementations that work (thus also including just_audio_mpv, perhaps with the note you suggest).

Have you had any experience testing just_audio_media_kit on windows and/or linux?

[KaJe5380]

Have you had any experience testing just_audio_media_kit on windows and/or linux?

I started some initial testing on Linux. There are some stuff I didn't get to,

• those being for streaming (request headers, DASH / HLS) as I was only planning to play local files.
• Gapless playback "seemed to work" but it's marked as experimental, so I wouldn't really call it a feature.
• Need to look into their shuffling note; doesn't look to complicated, but needing to write conditional platform code for shuffling is a bit of a pain. Though once written, it could be used for all the other platforms 🤷

Though I'm on Arch Linux (Kernel 6.9.7 - latest)
It would need to be tested on other distros, as a lot of stable distros don't use the latest Linux dependencies or kernel. Nor have I tried it with the PulseAudio backend, am currently using Pipewire.

I haven't test any of it on Windows, as I started moving my workflow to Linux in 2020 & dropped it entirely in 2023.

[Pato05]

Hi, just_audio_media_kit maintainer here!

I've been using and testing the package for a while now, and playback works (either streaming or locally, and with Pulse or Pipewire, though pipewire-pulse is still needed iirc). media-kit should also work on all distros as long as mpv is installed (tested in Arch Linux and Fedora), and also on Windows since it ships a dll build of libmpv (tested as well).

The caveats are listed here, the major one being the shuffleOrder which is not respected, though it is being worked at in Pato05/just_audio_media_kit#13. The recommended solution (for now) would be to just shuffle the playlist manually in all platforms (which is what my audio player app does), alternatively, you can use Zensonaton's fork.

Gapless playback is marked as experimental, as libmpv does too (in my experience it works pretty well, though it might discard some downloaded content, thus downloading stuff uselessly).

[ryanheise]

Excellent, thanks for confirming its stability @Pato05 . I'd like to try updating the examples here and also in audio_service to use just_audio_media_kit, and list it as the first choice since it is cross-platform.

Also, it looks like flutter/flutter#80374 was finally resolved yesterday which means I can actually add just_audio_media_kit as an endorsed implementation to pubspec.yaml -- if you're open to that, of course. But there is no rush to decide on that, because I think it will still take time for that fix to make it into Flutter stable.

If just_audio_media_kit is endorsed, it would then just make it automatically used as the default Linux/Windows implementation, although that default could in theory now be overridden with that new fix.

(As just_audio is part of Flutter Favorites, though, I would just have to make sure that any endorsed implementation follows all of the same official practices that just_audio itself follows, such as strictly following the semantic versioning rules as they are interpreted by pub.dev. This is so that a breaking change to just_audio_media_kit, including such changes to its own dependencies would not be introduced without being reflected in the semantic version, otherwise it could end up breaking just_audio itself.)

[Pato05]

Nice.

As just_audio is part of Flutter Favorites, though, I would just have to make sure that any endorsed implementation follows all of the same official practices that just_audio itself follows, such as strictly following the semantic versioning rules as they are interpreted by pub.dev. This is so that a breaking change to just_audio_media_kit, including such changes to its own dependencies would not be introduced without being reflected in the semantic version, otherwise it could end up breaking just_audio itself.

Regarding this, I already use semantic versioning in just_audio_media_kit. Though I wonder what the rules are specifically, would you mind providing a link?

[ryanheise]

Pub's rules for semantic versioning are at this link, which follows normal semantic versioning except that pub adds its own rules for versions pre 1.0.0. I see that just_audio_media_kit is post 1.0.0 so this distinction wouldn't matter. The main thing is that if just_audio depends on just_audio_media_kit ^2.0.0, then no breaking changes should be introduced in any version 2.x.x, including either to the public API or to its dependencies. So for example, when I recently bumped up the version of the rxdart dependency in just_audio, I used the constraint rxdart '>=0.26.0 <0.29.0' so that I would not break any apps that were previously depending on the older version of rxdart, and doing some testing to ensure that just_audio would work in both the previous version and the new version of rxdart to justify that constraint range. Looking at that constraint range, rxdart 0.26.0 was 3 years ago, so I could probably make that rxdart '>=0.27.0 <0.29.0' now without breaking anything, but I should certainly still keep support for 0.27.x since that was the latest version up until 1 month ago and I should not break apps that still require that version.

More broadly, the Flutter Favorite quality requirements are here but these are just what I must personally adhere to with just_audio itself. Although the last requirement is to also use high quality dependencies, so I think on your end, it would mainly be a matter of adhering to best practices regarding breaking changes. They mention unit test coverage further down the page, I don't think that's strictly necessary, although it wouldn't be a bad thing of course. The permissive license requirement is already met, I believe, since the GPL part of this is assumed to be installed separately outside of this package.