Add windows support

[dxvid-pts]

Is your feature request related to a problem? Please describe.
This is a follow-up to this issue

Describe the solution you'd like
Currently audio_service supports Android, IOS, MacOS and the web. It would be helpful to add windows support, especially regarding the current situation of Flutter 2.0 more and more transforming into a desktop target.

Describe alternatives you've considered

Additional context
This is probably blocked by #473 and we should wait until #415 landed

[ryanheise]

The main thing blocking at the moment is #415 , so I would definitely appreciate people's help to get that out the door sooner (testing, debugging, feedback).

[ryanheise]

This is unblocked. Any takers?

Also, it could actually be a good idea to provide a default platform implementation that just enables the audio logic to run on any platform without necessarily showing notification controls.

If anyone is interested in working on this, it would be good to announce below first in the off chance of ending up with duplicated efforts.

[keaganhilliard]

I wouldn't mind taking on a generic handler which wouldn't be a huge departure from the web version. Not sure I have the expertise to work with the Windows APIs. They appear to be a nuisance. There also aren't really any good stable audio libraries that work on the desktop (Windows and Linux) as of yet. So I'm not sure how much this would help developers without the actual audio playback. That said I am totally willing to cobble a default dart implementation together.

[keaganhilliard]

@ryanheise Does it need to be more complicated than this?

static AudioServicePlatform _instance =
      (!kIsWeb && (Platform.isWindows || Platform.isLinux))
          ? NoOpAudioService()
          : MethodChannelAudioService();

import 'package:flutter/services.dart';

import 'audio_service_platform_interface.dart';

class NoOpAudioService extends AudioServicePlatform {
  @override
  Future<ConfigureResponse> configure(ConfigureRequest request) async {
    return ConfigureResponse();
  }

  @override
  Future<void> setState(SetStateRequest request) async {}

  @override
  Future<void> setQueue(SetQueueRequest request) async {}

  @override
  Future<void> setMediaItem(SetMediaItemRequest request) async {}

  @override
  Future<void> stopService(StopServiceRequest request) async {}

  @override
  Future<void> androidForceEnableMediaButtons(
      AndroidForceEnableMediaButtonsRequest request) async {}

  @override
  Future<void> notifyChildrenChanged(
      NotifyChildrenChangedRequest request) async {}

  @override
  Future<void> setAndroidPlaybackInfo(
      SetAndroidPlaybackInfoRequest request) async {}

  void setClientCallbacks(AudioClientCallbacks callbacks) {}

  void setHandlerCallbacks(AudioHandlerCallbacks callbacks) {}
}

[ryanheise]

The callbacks implementation looks good to me. Like you, I was also thinking we might hard code the defaults into the platform interface. We just need to make sure that it is possible to override these defaults if someone creates another Windows implementation that does more than the defaults. And I think this should still work. If someone creates a Windows package and an app developer adds that as a pubspec dependency, then the generated plugin registrant should trigger that package to install its own override instance of the interface.

[keaganhilliard]

Assuming it works the same way as the web version, it should work correctly. Probably would need a test.

[kmod-midori]

I might be able to do this recently, but I need some pointers:

• Is it fine to give setQueue an empty implementation? Windows' SMTC does not control queues.
• What should stopService do on platforms that do not require a service? Should I simply remove the system notification/controls?

[ryanheise]

Hi @chengyuhui , good to hear you are interested in tackling this!

Yes to both questions. That sounds perfectly reasonable.

[ryanheise]

@yhsj0919 just pointed me to this interesting project:

https://github.com/KRTirtho/smtc_windows (created by @KRTirtho)

@KRTirtho , judging by the comment in your README, "This is the windows equivalent of android's audio_session" (by which I assume you meant "audio_service"), was your intention to make this work with audio_service? If you maintain smtc_windows as a separate library that is intended to be reusable independently of audio_service, then it would also be possible to create an audio_service_windows subdirectory/package here in this repository that simply adds smtc_windows as a dependency.

Do you have any thoughts on this? And well done on your project, by the way!

[KRTirtho]

@KRTirtho , judging by the comment in your README, "This is the windows equivalent of android's audio_session" (by which I assume you meant "audio_service"), was your intention to make this work with audio_service?

Sorry, my mistake. Yes I meant audio_service 😅. And also yes, it'll be great if audio_service includes support for windows out of the box

If you maintain smtc_windows as a separate library that is intended to be reusable independently of audio_service, then it would also be possible to create an audio_service_windows subdirectory/package here in this repository that simply adds smtc_windows as a dependency.

I'll be more than happy if it was managed by audio_service team. And I think smtc_windows makes more sense with audio_service. So, if you want, you can just copy the entire library and modify+use it in audio_service or you can create a federated package as you pointed out. Either way, it's a yes from me 😄

Also, since we're talking about windows support, you can even add Linux support too. There's an unpublished package used by harmonoid named mprsi_service by @alexmercerind (MIT Licensed) that can be utilized if @alexmercerind approves.

Or you can use dbus to create your own MPRIS.MediaPlayer2 bus implementation following the specifications like I'm doing for Spotube

By the way MPRIS requires Gnome's xdg-run/gvfs filesystem permission on Flatpak Flathub

Thanks for this awesome project❤️. Keep making it better 🚀

[Pato05]

Also, since we're talking about windows support, you can even add Linux support too. There's an unpublished package used by harmonoid named mprsi_service by @alexmercerind (MIT Licensed) that can be utilized if @alexmercerind approves.

About that, there's also the audio_service_mpris package by @bdrazhzhov, which can directly integrate with audio_service.

[ryanheise]

Nice! I'd be happy to add a mention of this in the audio_service README.

[ryanheise]

Thanks to @bdrazhzhov 's excellent audio_service_mpris package, I have updated the example to use it and updated the README to link to it. It's quite easy to use, after just adding the audio_service_mpris dependency to your pubspec, it should start working out of the box. If someone creates another implementation in the future, that is certainly no problem, and I would be happy to link to both in the README in a similar fashion to just_audio.

So I think we can close this issue now.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs, or use StackOverflow if you need help with audio_service.

[ryanheise]

Oops, I'm not sure what I was thinking when I closed this 😅

Obviously the Windows implementation hasn't been added yet.

While I can hypothetically attempt to build a Windows implementation based on @KRTirtho 's excellent work, the problem is that I don't have a Windows computer myself and wouldn't be the right person to test and maintain it.

So if anyone is interested in working on such an adaptation, I'd be happy to work with a volunteer on it.