You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Adds an opt-in experimental Windows host device for Linux's existing virtio_snd driver. The backend provides deterministic synthetic input and capture from an explicitly selected Windows WASAPI endpoint. Build and runtime defaults remain disabled. This implements a capture-focused part of #7327; playback, automatic reconnect, arbitrary formats, and universal device compatibility are out of scope.
The companion x86 kernel configuration change is available on the kernel fork branch. A companion PR could not be opened because that repository currently restricts interactions to collaborators. Both host and guest support are required.
Communication: Core-contributor discussion is still pending.
Tests: Revision fc875937 passed the standalone Debug build and 11/11 CTests, full-tree x64 Release service/test-target compilation, and the capture checks below. Revision 3d42e694 subsequently passed the standalone Debug build with Unity compilation enabled (batch size 4) and all 11 CTests; the latest full-tree and physical capture follow-up is recorded below. Full package/CI acceptance and execution of the WSL integration test suite remain pending.
Localization: New end-user strings are in the repository's en-US source resources.
Dev docs: Added repository technical and developer documentation.
Documentation updated: A separate microsoftdocs/wsl pull request has not been prepared.
Detailed Description of the Pull Request / Additional comments
The VM uses a virtio-sound device backed by a VM-owned host process. Synthetic capture is deterministic. Physical capture uses a worker in the originating user session and requires an explicit Windows capture endpoint; it does not silently choose a default microphone. Guest PCM START initiates microphone access, so selecting the experimental feature is not a per-application permission prompt.
The HDV child retains SYSTEM identity at High integrity. The process and job boundaries do not make it a privilege sandbox. Minimum privileges, device lifecycle, permission UX, coexistence with WSL's existing device host, and supported HCS/HDV ownership semantics need maintainer and security review before shipping. The feature remains experimental and opt-in.
AI assistance was used. Contributor identity, human review, and CLA completion remain the submitter's responsibility.
Validation Steps Performed
The master-based source at tested revision fc875937bb0cb7d594e5c387f79b594a37b13da4 built with Visual Studio 2022 x64 using the standalone CMake project. All 11 CTest tests passed. This covers the device core, Windows adapter compilation, worker/IPC logic, and mocked lifecycle/security checks.
Revision fc875937bb0cb7d594e5c387f79b594a37b13da4 also successfully compiled and linked the full-tree wslservice and wsltests targets in x64 Release with the experimental feature enabled. Local configuration used UTF-8 compiler flags and a private copy-staging equivalent of the Appx symlink helper because Developer Mode was unavailable; public source was unchanged. This was not an MSI/MSIX or ALL_BUILD package build, and compiling wsltests.dll does not mean the WSL integration test suite was executed.
The pre-rebase source patch (SHA-256 02362cfbf0e97edab2732dcb4ca68c0cb67c2398c057fa19407e89f7863c8cb2) previously passed 11 standalone tests and was checked against WSL release sources 2.9.13 and 3.0.3. Those results predate this master-based checkout and have not been rerun here.
The independent standard-library Python ALSA probe was tested with a Samson Go Mic through WASAPI and native virtio_snd at 48 kHz, stereo S16_LE. It fails on XRUN without recovery and retains aggregate statistics only. An initial 600-second attempt failed around 64 seconds; a retry passed before any functional fix. That original failure did not have sufficient tracing to establish its cause.
A controlled host-pump delay reproduced a specific failure: the original pump completed 8,192 frames (four 2,048-frame periods, exactly the negotiated guest buffer) after the delay, followed by ALSA -EPIPE. The change caps each source-clocked pump at one period below the buffer size. With the same requested 200 ms delay, the candidate completed three periods and the independent probe passed 90 seconds (4,320,000 frames, 8,640,000 samples). The regression failed before this change and the 11-test standalone suite passed afterward. This is evidence for the controlled single-pump failure; it does not prove the earlier natural XRUN shared that cause or guarantee against arbitrary guest scheduling delays.
The runtime service for the controlled-delay and 300-second Compose tests was built from WSL source b5380f6ba529dabbbee0c1da2fe2a3e377851f4c with the feature and candidate core, using matched guest kernel/modules reporting 6.18.54.1-microsoft-standard-WSL2+. Its production capture core matches this proposal. Those tests predate the process-creation job-assignment fix below, and the public tree also contains newer unrelated WSL integration changes. These hardware results are not full-package acceptance of the current master-based tree. No Windows audio endpoint IDs, raw logs, or captured PCM are included.
The clean candidate (without the artificial delay) passed an independent 300-second Docker Compose capture: exactly 14,400,000 frames / 28,800,000 samples, nonzero signal, and no XRUN or recovery. The probe SHA-256 was 4b0c73ac07b8d98d788629b5e66a0da740b4af0b7d04b43aa10f118d51f90412. Compose mapped /dev/snd with UID/GID 65534, no capabilities, no network, and a read-only root filesystem. A local override selected the prepared image and bounded the container to 315 seconds; the probe command was python3 /app/alsa_capture_probe.py --device hw:0,0 --duration 300 --acknowledge-microphone-access. The Docker host's PCM and card-control nodes required temporary group access for this unprivileged test; both nodes' original permissions were restored. Host-side setup is required in addition to the Compose device mapping. This test establishes the tested capture path and frame count, not audio fidelity or universal stability.
Review follow-up
Commit fc875937bb0cb7d594e5c387f79b594a37b13da4 attaches the kill-on-close job through PROC_THREAD_ATTRIBUTE_JOB_LIST at process creation, closing the gap between creating a suspended child and assigning its job. It verifies job membership before resuming the child. The ring test now observes producer completion before reading and includes a deterministic final-publication race regression. The standalone Debug build, all 11 CTests, and full-tree service/test-target compilation passed after these changes.
The service and audio worker built from this exact revision then passed a three-second exact synthetic-ramp test and a three-second Samson Go Mic capture through native ALSA. They also passed a fresh 300-second independent Python capture in the unprivileged Compose container: exactly 14,400,000 frames / 28,800,000 samples, nonzero input, and no XRUN or recovery. The Docker image was recreated from the unchanged pinned-base recipe using cached build layers; installed versions were Python 3.11.2-1+b1 and libasound2 1.2.8-1+b1. The probe hash and container restrictions were unchanged. Both trial stages verified restoration of the original runtime/configuration and Docker state; Compose also verified device permissions and owned-container cleanup, with no cleanup errors. These are startup/capture checks, not forced service-crash, audio-fidelity, or full-package acceptance tests. The guest kernel remains the earlier custom build described above, not an exact build of the companion kernel branch.
Synthetic pacing follow-up
Commit bd57ee37aaf8f0832ede78788a3110d1784923c0 removes the host's 20 ms elapsed-time clamp. A recurring 30 ms scheduling interval previously supplied only 20 ms of synthetic capture credit after advancing the host timestamp; the full positive interval now reaches the core, which already bounds accumulated credit and transfer size. The source-clocked Windows path continues to use available frames and the existing guest-ring headroom limit. This one-line follow-up initially shipped without new tests. The subsequent standalone build and offline tests below include it; full-tree and runtime results above remain scoped to fc875937.
Capture capacity and Unity-build review follow-up
Commit 3d42e694a5bff1e508fb98383f8bbb240240fd31 rejects source-clocked PCM parameters whose whole-period burst capacity cannot sustain the nominal 10 ms pump interval while preserving one guest period of headroom. For example, 512/128 frames at 48 kHz is rejected instead of accepting a stream capped at 38,400 frames/s; 1024/256 frames is accepted. The host wait and validation share the same interval constant. This does not promise immunity to scheduler stalls.
The HDV lifecycle test target disables Unity compilation because its test-only types intentionally have matching definitions in separate translation units. The standalone x64 Debug build succeeded with CMAKE_UNITY_BUILD=ON and batch size 4, including this target, and all 11 CTests passed. A new regression covers unsupported capacity, whole-period rounding, one-period rejection, unchanged synthetic acceptance, and 100 successive clocked pumps without growing backlog. The subsequent full-tree build and physical microphone/Compose rerun for this revision are recorded below.
Current-head build and physical capture acceptance (2026-10-18)
Revision 3d42e694a5bff1e508fb98383f8bbb240240fd31 successfully compiled and linked the full-tree x64 Release wslservice and wsltests targets and their dependencies. This local build used sccache 0.18.0 with a 2 GiB disk-cache limit and MSVC embedded debug information (/Z7); PCH-related calls can bypass caching. It was not an ALL_BUILD/MSI/MSIX package build, and the WSL integration suite was not executed.
The resulting service and capture worker passed three-second synthetic and native startup checks, followed by a 300-second real Samson Go Mic capture through the independent Python probe in an unprivileged Docker Compose container. The probe completed exactly 14,400,000 frames / 28,800,000 samples with nonzero signal and no XRUN recovery. Only aggregate statistics were retained; no audio file was written. Runtime payload hashes, WSL configuration, temporary PCM/control device permissions and owned-container cleanup were verified restored. Docker Desktop was stopped before the trial and returned to that stopped state afterward.
Service SHA-256: 7E96A9FC7899D503F5E21D4F723CBF4251830952070CCEA976DD8213A0C9A498.
Worker SHA-256: 9A42CD3BF4DEDD803B943EA09DDBDFB0DCFC5808DCADE070D51E54BFF6B92DCC.
This closes the current-head build/runtime verification gap for the tested configuration. It does not establish audio fidelity, universal hardware compatibility, security acceptance, or an exact build of the companion kernel branch. Maintainer CI and SYSTEM/HDV ownership review remain pending.
Adds experimental, opt-in ALSA capture support for WSL through Linux’s virtio_snd driver, addressing the capture portion of #7327 without adding playback.
Changes:
Adds synthetic capture and explicitly selected Windows WASAPI input.
Integrates VM lifecycle, configuration, packaging, and build gates; defaults remain disabled.
Adds offline tests, documentation, and an independent ALSA capture probe.
Review follow-up is in fc87593. Both reported issues are addressed. The exact submitted source compiled/linked the x64 Release service and test targets; 11 standalone CTests and synthetic/native startup checks passed, followed by a 300-second independent Python capture in an unprivileged Compose container. The PR body distinguishes these checks from full package/CI acceptance and describes the remaining experimental/security limitations.
Could a maintainer authorize CI for this fork PR and advise how to submit the config-only kernel companion? GitHub rejected opening its PR because WSL2-Linux-Kernel interactions are restricted to collaborators. The x86-only comparison is microsoft/WSL2-Linux-Kernel@linux-msft-wsl-6.18.y...whatisyourname0:codex/enable-virtio-sound-for-wsl . The exact companion branch still needs its own kernel build/package validation; the hardware tests used the documented earlier custom kernel. Both host and guest changes are required.
The 20 ms clamp permanently discards elapsed time because last has already advanced to now. With recurring 30 ms scheduling intervals, synthetic capture receives only 960 frames of credit per tick instead of 1,440, reducing its effective rate from 48 kHz to 32 kHz and potentially timing out duration-based probes. Pass the full interval to PumpCaptureElapsed; the core already caps accumulated credit and transfer size. The hardware-source path uses available frames rather than elapsed-time credit.
Forward the full positive host interval to the device core. The core already bounds accumulated credit and transfer size; truncating every delayed interval to 20 ms permanently loses synthetic capture time. Source-clocked Windows capture retains its availability and guest-ring headroom limits.
Addressed the synthetic pacing note in the follow-up review in commit bd57ee3. The host now forwards the full positive elapsed interval instead of truncating each delayed tick to 20 ms. The core retains its accumulated-credit and transfer-size limits; Windows capture still uses source availability and the existing guest-ring headroom bound. This is a one-line follow-up. No new build or tests were run for it; the documented build and microphone validation results apply to fc87593, not this revision. The SYSTEM identity and HCS/HDV ownership review boundaries remain documented for maintainer/security review.
@microsoft/wsl-reviewers Could you review this opt-in experimental virtio-sound capture proposal, or route it to the appropriate WSL/HCS/HDV and security maintainers?
In particular, I would appreciate guidance on:
SYSTEM privilege boundary: the VM-owned HDV child retains SYSTEM identity at High integrity and processes guest-controlled requests. The job/process boundary is not a security sandbox. Are this identity and the requested privileges appropriate, and what isolation or hardening would be required? Physical capture runs in a separate restricted worker in the originating user session.
HDV ownership and lifetime: the proposal borrows the WSL HCS system and treats HDV host ownership as unknown/shared. Please review coexistence with the existing device host, callback lifetime, and teardown behavior, including parent death where guest retirement has not been confirmed. I would like to confirm the supported ownership model before treating this as a shipping design.
At current head 3d42e694a5bff1e508fb98383f8bbb240240fd31, the standalone x64 Debug Unity build and all 11 offline tests passed. The full-tree compilation and physical microphone/Compose results in the PR description apply to the earlier fc875937 revision; current-head runtime acceptance and full upstream CI are still pending. The feature remains disabled by default.
An authorized maintainer may also need to approve the fork CI run. Thank you for helping assess whether this architecture is suitable for WSL.
A separate stacked follow-up is now available for review: whatisyourname0/WSL#1. It was opened as a Draft and has now been marked Ready for Review.
Scope and dependency: the follow-up targets this PR's exact head, 3d42e694a5bff1e508fb98383f8bbb240240fd31, in the fork. Its 15 commits / 47 changed files are only the additional delta: event-driven capture and I/O, bounded buffer reuse, IPC header-read improvements, orderly-stop HDV doorbell retirement, and documentation. None of those changes have been added to #41965; this PR's branch and scope are unchanged.
Validation of the follow-up implementation (5aa048a):
Full Windows x64 Release service/worker build and 19/19 standalone CTests passed.
A fresh synthetic ramp, then a 3-second precheck and 600-second non-root Docker Compose Samson Go Mic capture through /dev/snd completed: exactly 28,800,000 frames / 57,600,000 samples at 48 kHz stereo S16_LE. No ALSA XRUN/recovery or ongoing WASAPI discontinuity was observed.
Both VM lifecycles successfully unregistered the RX doorbell before orderly shutdown and received the parent acknowledgement. No post-exit unregister, emergency abort, or ETW event/buffer loss was observed.
The approximately 8GB test host used a temporary 1GiB WSL VM cap with GUI support disabled; the UID/GID 65534 container had a 128MiB limit, no network, a read-only root and no capabilities. Minimum host memory availability was 1.12GiB. Original binaries, configuration and temporary device permissions were restored and independently checked.
Submitted head 3a14ac2 adds only documentation to that tested implementation. Full hashes and detailed provenance are in the follow-up description. These results qualify the follow-up configuration; they do not replace or expand the parent PR's own validation.
After the parent lands, rebase the follow-up onto the resulting upstream history, verify that only the remaining delta is present, rerun applicable validation, and open the upstream follow-up against microsoft/WSL:master. If the parent changes before then, update/revalidate the stack accordingly.
Remaining limits: single x64 host/endpoint; ARM64, full-package/WSL CI, USB loss, and forced-crash runtime injection remain unqualified. Earlier overloaded trials had intermittent XRUNs; this unloaded pass does not establish overload reliability. Independent guest exit can still race doorbell preparation and produce an invalid-state error; the failure path retains callback/event ownership. The custom guest kernel is not an exact build of the companion kernel submission branch. No latency/CPU improvement or audio-fidelity claim is made. Maintainer and SYSTEM/HDV security review remain required.
Only aggregate capture statistics were retained; no audio file, raw trace, endpoint identifier or internal company code is included. Ready for Review means ready for code review, not production or merge approval.
Craig Loewen (@craigloewen-msft) Thanks for triaging this proposal. I’d appreciate guidance on the HCS/HDV ownership and security boundaries before taking the design further. I’m happy to provide a smaller reproducer or adjust the scope to help review. Could an authorized maintainer also approve the pending CI runs?
This branch has not been deployed
No deployments
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary of the Pull Request
Adds an opt-in experimental Windows host device for Linux's existing
virtio_snddriver. The backend provides deterministic synthetic input and capture from an explicitly selected Windows WASAPI endpoint. Build and runtime defaults remain disabled. This implements a capture-focused part of #7327; playback, automatic reconnect, arbitrary formats, and universal device compatibility are out of scope.The companion x86 kernel configuration change is available on the kernel fork branch. A companion PR could not be opened because that repository currently restricts interactions to collaborators. Both host and guest support are required.
PR Checklist
fc875937passed the standalone Debug build and 11/11 CTests, full-tree x64 Release service/test-target compilation, and the capture checks below. Revision3d42e694subsequently passed the standalone Debug build with Unity compilation enabled (batch size 4) and all 11 CTests; the latest full-tree and physical capture follow-up is recorded below. Full package/CI acceptance and execution of the WSL integration test suite remain pending.en-USsource resources.microsoftdocs/wslpull request has not been prepared.Detailed Description of the Pull Request / Additional comments
The VM uses a virtio-sound device backed by a VM-owned host process. Synthetic capture is deterministic. Physical capture uses a worker in the originating user session and requires an explicit Windows capture endpoint; it does not silently choose a default microphone. Guest PCM START initiates microphone access, so selecting the experimental feature is not a per-application permission prompt.
The HDV child retains SYSTEM identity at High integrity. The process and job boundaries do not make it a privilege sandbox. Minimum privileges, device lifecycle, permission UX, coexistence with WSL's existing device host, and supported HCS/HDV ownership semantics need maintainer and security review before shipping. The feature remains experimental and opt-in.
AI assistance was used. Contributor identity, human review, and CLA completion remain the submitter's responsibility.
Validation Steps Performed
The
master-based source at tested revisionfc875937bb0cb7d594e5c387f79b594a37b13da4built with Visual Studio 2022 x64 using the standalone CMake project. All 11 CTest tests passed. This covers the device core, Windows adapter compilation, worker/IPC logic, and mocked lifecycle/security checks.Revision
fc875937bb0cb7d594e5c387f79b594a37b13da4also successfully compiled and linked the full-treewslserviceandwslteststargets in x64 Release with the experimental feature enabled. Local configuration used UTF-8 compiler flags and a private copy-staging equivalent of the Appx symlink helper because Developer Mode was unavailable; public source was unchanged. This was not an MSI/MSIX orALL_BUILDpackage build, and compilingwsltests.dlldoes not mean the WSL integration test suite was executed.The pre-rebase source patch (SHA-256
02362cfbf0e97edab2732dcb4ca68c0cb67c2398c057fa19407e89f7863c8cb2) previously passed 11 standalone tests and was checked against WSL release sources 2.9.13 and 3.0.3. Those results predate thismaster-based checkout and have not been rerun here.The independent standard-library Python ALSA probe was tested with a Samson Go Mic through WASAPI and native
virtio_sndat 48 kHz, stereoS16_LE. It fails on XRUN without recovery and retains aggregate statistics only. An initial 600-second attempt failed around 64 seconds; a retry passed before any functional fix. That original failure did not have sufficient tracing to establish its cause.A controlled host-pump delay reproduced a specific failure: the original pump completed 8,192 frames (four 2,048-frame periods, exactly the negotiated guest buffer) after the delay, followed by ALSA
-EPIPE. The change caps each source-clocked pump at one period below the buffer size. With the same requested 200 ms delay, the candidate completed three periods and the independent probe passed 90 seconds (4,320,000 frames, 8,640,000 samples). The regression failed before this change and the 11-test standalone suite passed afterward. This is evidence for the controlled single-pump failure; it does not prove the earlier natural XRUN shared that cause or guarantee against arbitrary guest scheduling delays.The runtime service for the controlled-delay and 300-second Compose tests was built from WSL source
b5380f6ba529dabbbee0c1da2fe2a3e377851f4cwith the feature and candidate core, using matched guest kernel/modules reporting6.18.54.1-microsoft-standard-WSL2+. Its production capture core matches this proposal. Those tests predate the process-creation job-assignment fix below, and the public tree also contains newer unrelated WSL integration changes. These hardware results are not full-package acceptance of the currentmaster-based tree. No Windows audio endpoint IDs, raw logs, or captured PCM are included.The clean candidate (without the artificial delay) passed an independent 300-second Docker Compose capture: exactly 14,400,000 frames / 28,800,000 samples, nonzero signal, and no XRUN or recovery. The probe SHA-256 was
4b0c73ac07b8d98d788629b5e66a0da740b4af0b7d04b43aa10f118d51f90412. Compose mapped/dev/sndwith UID/GID 65534, no capabilities, no network, and a read-only root filesystem. A local override selected the prepared image and bounded the container to 315 seconds; the probe command waspython3 /app/alsa_capture_probe.py --device hw:0,0 --duration 300 --acknowledge-microphone-access. The Docker host's PCM and card-control nodes required temporary group access for this unprivileged test; both nodes' original permissions were restored. Host-side setup is required in addition to the Compose device mapping. This test establishes the tested capture path and frame count, not audio fidelity or universal stability.Review follow-up
Commit
fc875937bb0cb7d594e5c387f79b594a37b13da4attaches the kill-on-close job throughPROC_THREAD_ATTRIBUTE_JOB_LISTat process creation, closing the gap between creating a suspended child and assigning its job. It verifies job membership before resuming the child. The ring test now observes producer completion before reading and includes a deterministic final-publication race regression. The standalone Debug build, all 11 CTests, and full-tree service/test-target compilation passed after these changes.The service and audio worker built from this exact revision then passed a three-second exact synthetic-ramp test and a three-second Samson Go Mic capture through native ALSA. They also passed a fresh 300-second independent Python capture in the unprivileged Compose container: exactly 14,400,000 frames / 28,800,000 samples, nonzero input, and no XRUN or recovery. The Docker image was recreated from the unchanged pinned-base recipe using cached build layers; installed versions were Python 3.11.2-1+b1 and libasound2 1.2.8-1+b1. The probe hash and container restrictions were unchanged. Both trial stages verified restoration of the original runtime/configuration and Docker state; Compose also verified device permissions and owned-container cleanup, with no cleanup errors. These are startup/capture checks, not forced service-crash, audio-fidelity, or full-package acceptance tests. The guest kernel remains the earlier custom build described above, not an exact build of the companion kernel branch.
Synthetic pacing follow-up
Commit
bd57ee37aaf8f0832ede78788a3110d1784923c0removes the host's 20 ms elapsed-time clamp. A recurring 30 ms scheduling interval previously supplied only 20 ms of synthetic capture credit after advancing the host timestamp; the full positive interval now reaches the core, which already bounds accumulated credit and transfer size. The source-clocked Windows path continues to use available frames and the existing guest-ring headroom limit. This one-line follow-up initially shipped without new tests. The subsequent standalone build and offline tests below include it; full-tree and runtime results above remain scoped tofc875937.Capture capacity and Unity-build review follow-up
Commit
3d42e694a5bff1e508fb98383f8bbb240240fd31rejects source-clocked PCM parameters whose whole-period burst capacity cannot sustain the nominal 10 ms pump interval while preserving one guest period of headroom. For example, 512/128 frames at 48 kHz is rejected instead of accepting a stream capped at 38,400 frames/s; 1024/256 frames is accepted. The host wait and validation share the same interval constant. This does not promise immunity to scheduler stalls.The HDV lifecycle test target disables Unity compilation because its test-only types intentionally have matching definitions in separate translation units. The standalone x64 Debug build succeeded with
CMAKE_UNITY_BUILD=ONand batch size 4, including this target, and all 11 CTests passed. A new regression covers unsupported capacity, whole-period rounding, one-period rejection, unchanged synthetic acceptance, and 100 successive clocked pumps without growing backlog. The subsequent full-tree build and physical microphone/Compose rerun for this revision are recorded below.Current-head build and physical capture acceptance (2026-10-18)
Revision
3d42e694a5bff1e508fb98383f8bbb240240fd31successfully compiled and linked the full-tree x64 Releasewslserviceandwslteststargets and their dependencies. This local build used sccache 0.18.0 with a 2 GiB disk-cache limit and MSVC embedded debug information (/Z7); PCH-related calls can bypass caching. It was not an ALL_BUILD/MSI/MSIX package build, and the WSL integration suite was not executed.The resulting service and capture worker passed three-second synthetic and native startup checks, followed by a 300-second real Samson Go Mic capture through the independent Python probe in an unprivileged Docker Compose container. The probe completed exactly 14,400,000 frames / 28,800,000 samples with nonzero signal and no XRUN recovery. Only aggregate statistics were retained; no audio file was written. Runtime payload hashes, WSL configuration, temporary PCM/control device permissions and owned-container cleanup were verified restored. Docker Desktop was stopped before the trial and returned to that stopped state afterward.
Service SHA-256:
7E96A9FC7899D503F5E21D4F723CBF4251830952070CCEA976DD8213A0C9A498.Worker SHA-256:
9A42CD3BF4DEDD803B943EA09DDBDFB0DCFC5808DCADE070D51E54BFF6B92DCC.This closes the current-head build/runtime verification gap for the tested configuration. It does not establish audio fidelity, universal hardware compatibility, security acceptance, or an exact build of the companion kernel branch. Maintainer CI and SYSTEM/HDV ownership review remain pending.