audio_flutter_windows 0.1.0 
audio_flutter_windows: ^0.1.0 copied to clipboard
Windows implementation of audio_flutter - WASAPI loopback and microphone capture plus render playback.
audio_flutter_windows #
Windows implementation of the audio_flutter platform contract: WASAPI
shared-mode loopback for system audio, WASAPI capture endpoints for the
microphone, and a WASAPI render client for playback.
The C++ in this package has never been compiled. It was written on macOS, where no MSVC toolchain is available, so the native half is unverified: it has been reviewed twice by hand but not built, linked, or run. Build it on a Windows machine or in Windows CI before depending on it. The Dart half is fully tested and does not share that caveat.
Mechanism #
| Concern | Windows answer |
|---|---|
| System audio | IAudioClient::Initialize(AUDCLNT_SHAREMODE_SHARED, AUDCLNT_STREAMFLAGS_LOOPBACK, …) on a render endpoint |
| Microphone | the same client on an eCapture endpoint, no loopback flag |
| Playback | IAudioRenderClient on the default render endpoint |
| Permission | none — shared-mode loopback needs no grant and no OS version gate |
| Format | endpoint mix format is read, never assumed: IEEE float32 and 8/16/24/32-bit integer PCM are decoded, down-mixed to mono, then resampled |
| Resampling | phase-continuous linear interpolation, carried across packet seams |
| Thread | one dedicated capture thread per session, on the MMCSS "Pro Audio" task, polling at half the endpoint buffer in 5 ms slices so stop latency stays bounded |
Audio is pulled, not pushed. Each session converts into its own bounded ring
and readCaptureFrames drains it. That is the main structural difference from
the Control Center plugin this code is derived from: it pushed every frame to
the platform thread through a private window message, and this one only does
that for the handful of lifecycle events per session.
Targeting #
PlatformCaptureRequest.inputDeviceId carries a WASAPI endpoint id for both
capture kinds — an eCapture endpoint for the microphone, an eRender endpoint
for system audio. Null selects the respective default. listAudioInputDevices()
enumerates capture endpoints; listSystemAudioSources() enumerates render
endpoints for system-audio targeting.
Unsupported request fields #
Both are rejected at prepareCapture rather than ignored, because honouring
them silently would return audio that does not match what was asked for:
processIds— per-process capture needsAUDIOCLIENT_ACTIVATION_TYPE_PROCESS_LOOPBACK(Windows 10 20H1+), which this implementation does not use yet.listAudioProcesses()returns empty for the same reason. Tracked as a follow-up.rawRecordingPath— no source-side recording. Record from the pulled frames instead.
Overflow policy #
dropOldest evicts the head and bills the drop to the next frame read;
dropNewest refuses the arrival and bills the next frame admitted;
failCapture fails the session with CaptureMailboxOverflow. sequence and
sampleOffset are assigned by the producer, so they keep advancing across drops
and a consumer can always tell how much it missed.
Health #
A capture that initialises cleanly but delivers nothing is reported rather than
left hanging: if no audio arrives within two seconds, the session fails with
CaptureStalled. Lifecycle events reach Dart over the event channel and are
demultiplexed per session.
Validation status #
| Layer | State |
|---|---|
| Dart platform client, wire codec, session demux | tested, 34 tests |
| C++ WASAPI capture, playback, enumeration | not compiled, not run |
See windows/README.md for how to build and what to check first on real
hardware.
Metadata
Documentation
Publisher
unverified uploader
Weekly Downloads
Metadata
Windows implementation of audio_flutter - WASAPI loopback and microphone capture plus render playback.
Repository (GitHub)
View/report issues
Topics
License
MIT (license)
Dependencies
audio_core, audio_flutter_platform_interface, flutter
More
Packages that depend on audio_flutter_windows
Packages that implement audio_flutter_windows