Crash on Windows when no audio output device is available

[Princeofnorth06]

Checklist

• I read the troubleshooting guide before raising this issue
• I made sure that the issue I am raising doesn't already exist

Current bug behaviour

Bug Description

The application crashes on Windows when there is no audio output device available (e.g., no speakers, disabled audio device, or remote environment without sound output).

Instead of handling the missing audio device gracefully, the plugin throws an exception and crashes the app.

• OS: Windows (tested on Windows 10/11)
• Flutter version: [your version]
• audioplayers version: [your version]

---

📌 Additional Context

This issue makes it difficult to run apps in:

• Virtual machines
• Remote desktops
• Systems without audio hardware

A fallback mechanism or safe exception handling would be helpful.

---

💡 Suggested Fix

• Check for available audio devices before playback
• Return a controlled error instead of crashing
• Provide a callback or error stream for handling this scenario

---

📎 Minimal Code Example

final player = AudioPlayer();
await player.play(AssetSource('audio.mp3'));

### Expected behaviour

The plugin should:
- Fail gracefully OR
- Return an error without crashing the app

### Steps to reproduce

1. Run a Flutter Windows app using `audioplayers`
2. Ensure no audio output device is available:
  - Use a system without audio hardware (VM / remote desktop)
3. Try to play any audio using `AudioPlayer.play()`

### Code sample

Future<void> playAudioSafely(String assetPath, {double volume = 1.0}) async {
  try {
    if (await hasAudioOutput() == false) {
      print('No audio output found. Skipping playback.');
      return;
    }
    

    if (!Get.find<StoreController>().isOrderSoundEnabled) {
      print('Audio playback is disabled in settings. Skipping playback.');
      return;
    }

    final player = AudioPlayer();
    await player.play(
      AssetSource(assetPath),
      volume: volume,
    );
  } catch (e) {
    print('Failed to play audio: $e');
  }
}

### Affected platforms

Windows

### Platform details

_No response_

### AudioPlayers Version

6.5.1

### Build mode

_No response_

### Audio Files/URLs/Sources

_No response_

### Screenshots

_No response_

### Logs

<!-- Code block with 2-3 relevant log lines -->

my relevant logs

<details>
  <summary>Full Logs</summary>

  <!-- You **must** use code blocks (or link gists) to paste in log lines. -->

my full logs or a link to a gist

Flutter doctor:

Output of: flutter doctor -v

</details>


### Related issues / more information

_No response_

### Working on PR

no way

[Sebastien-VZN]

Hello,

I ran into this issue as well. After analysis, the root cause is that the Windows plugin had no exception handling on the entire processing chain. When MediaFoundation cannot find an audio renderer (VM, remote desktop, disabled audio service), C++ exceptions propagate uncaught all the way up to Flutter, crashing the application.

There was also a secondary deadlock bug in RunSyncInMTA (STA path): if an exception was thrown inside the worker thread, the synchronization event was never signaled, and the calling thread would block indefinitely.

Fixes applied

I fixed both issues in my fork, replicating the same error handling pattern I implemented on the Linux plugin (where GStreamer was crashing similarly on a missing device):

1. HandleMethodCall — a global try-catch wrapping the entire method body, catching std::exception with ex.what() forwarded to result->Error("WindowsAudioError", ...). All commands are protected: create, play, resume, stop, seek, setSourceUrl, setSourceBytes, setVolume, etc.

2. AudioPlayer constructor — try-catch around MediaFoundation initialization (MFPlatform::Startup() + MediaEngineWrapper::Initialize()), log via OutputDebugStringA, then rethrow for propagation to the global catch.

3. RunSyncInMTA (STA path) — the exception is captured via std::current_exception(), the event is always signaled via complete.SetEvent(), then the exception is rethrown on the calling thread via std::rethrow_exception. The deadlock is resolved.

4. SetSourceBytes — added missing THROW_IF_FAILED checks on MFCreateMFByteStreamOnStream and CreateObjectFromByteStream (return codes were silently ignored before).

Validation

The fix was validated by disabling the Windows Audio service (services.msc → Windows Audio → Stop). The plugin now returns a PlatformException(WindowsAudioError, ...) to Dart instead of crashing, and the error is caught by the existing logging system (AudioLogger.error()).

CI/CD tests

I added tests to the CI to prevent regressions:

• 7 Dart mock tests validating the Flutter layer (player creation with PlatformException, resume() failure, async errors on the event stream, multiple sequential errors). Runs on the existing Linux CI job.
• 9 native C++ tests validating the error handling logic on the Windows side (EventStreamHandler null-check/mutex, RunSyncInMTA exception capture + no deadlock + rethrow, PlatformThreadHelper exception does not block the queue). New CI job windows-native-test on windows-latest.

Testing the fork

If you want to test it on your side, you can add this to your pubspec.yaml:

audioplayers:
  git:
    url: https://github.com/Sebastien-VZN/audioplayers
    path: packages/audioplayers

The fork is actively maintained. I don't have macOS/iOS hardware, so on those two platforms I apply the official repo as-is. Maintainers are free to check out the fork if they wish to apply the same error handling strategy.

Best regards.