forked from Manuel/meeting-assistant
53 lines
5.0 KiB
Markdown
53 lines
5.0 KiB
Markdown
## Implementation Evidence
|
|
|
|
Date: 2026-07-21
|
|
Host: macOS arm64
|
|
|
|
### Live audio verification
|
|
|
|
- The bundled Swift helper compiled as an arm64 Mach-O executable and was launched directly from the portable application build output.
|
|
- AVFoundation microphone capture emitted 546,920 bytes of signed 16-bit, 16 kHz mono PCM during the final 17-second proof window. The selected default input was `Jabra Link 390`; its captured samples were all zero, consistent with a muted/silent input rather than a capture-process failure.
|
|
- ScreenCaptureKit system capture emitted 551,680 bytes of signed 16-bit, 16 kHz mono PCM while the repository's known `sample-16khz-mono.wav` fixture was played 12 times through the default system output.
|
|
- The captured streams were aligned to their shared duration, summed with 16-bit clamping, and written to `docs/evidence/macos-meeting-audio-proof.wav`.
|
|
- `afinfo` reports the proof as 17.091250 seconds, mono, 16000 Hz, signed 16-bit PCM, with 546,920 audio bytes.
|
|
- Signal inspection found 48,133 non-zero samples and a peak amplitude of 12,000 in the proof WAV.
|
|
- SHA-256: `f38285a5386067f0c2637698f2e3c720ad30b65cebaaefe8d00454c78d8c2d05`.
|
|
|
|
### Behavior and packaging verification
|
|
|
|
- Public recording endpoint behavior:
|
|
- Test: `RecordingEndpointsCaptureMixedMacOsAudioAndStopNativeProcesses` calls `/recording/start`, observes known microphone/system samples combined into one `12000` PCM sample at the speech-pipeline boundary, calls `/recording/stop`, and verifies both native capture processes were terminated.
|
|
- The test uses deterministic process-boundary audio because automated test hosts cannot depend on live devices or macOS privacy state.
|
|
- Focused macOS-source, public endpoint, and existing mixer tests:
|
|
- Command: `dotnet test MeetingAssistant.Tests/MeetingAssistant.Tests.csproj --filter 'FullyQualifiedName~MacOsMeetingAudioSourceTests|FullyQualifiedName~AudioMixingTests' --no-restore --nologo`
|
|
- Result: passed, 11/11.
|
|
- Portable application build:
|
|
- Command: `dotnet build MeetingAssistant/MeetingAssistant.csproj -f net10.0 --no-restore --nologo`
|
|
- Result: succeeded with 0 warnings and 0 errors; the Swift helper was compiled into the application output.
|
|
- macOS publish:
|
|
- Command: `dotnet publish MeetingAssistant/MeetingAssistant.csproj -f net10.0 -r osx-arm64 --self-contained false -p:EnableWindowsTargeting=true -o tmp/macos-publish-proof --nologo`
|
|
- Result: succeeded; `Native/macos-meeting-audio-capture` is an executable arm64 Mach-O file in publish output.
|
|
- OpenSpec validation:
|
|
- Command: `openspec validate add-macos-meeting-audio-capture --strict`
|
|
- Result: valid.
|
|
|
|
### Windows isolation verification
|
|
|
|
- The existing `#if WINDOWS` registration continues to use `MicrophoneAudioSource`, `SystemAudioSource`, `AdaptiveFilterAcousticEchoCancellerFactory`, and `CompositeMeetingAudioSource`. macOS selection exists only inside the portable `#else` branch.
|
|
- Windows C# compilation:
|
|
- Command: `dotnet msbuild MeetingAssistant/MeetingAssistant.csproj -t:Compile -p:TargetFramework=net10.0-windows10.0.19041.0 -p:EnableWindowsTargeting=true -nologo -v:minimal`
|
|
- Result: succeeded.
|
|
- A full Windows-target build cannot finish on macOS because the Windows App SDK attempts to execute `MakePri.exe` and returns `Exec format error`. This occurs after managed compilation and is the repository's known cross-host limitation; Windows CI or a Windows host remains the full binary verification environment.
|
|
|
|
### Full portable test result
|
|
|
|
- Command: `dotnet test MeetingAssistant.Tests/MeetingAssistant.Tests.csproj --no-restore --nologo`
|
|
- Result: 425 passed and 10 failed in the combined run. One unrelated inactivity-timer test was then rerun in isolation and passed (1/1), leaving the effective result at 426 passing tests and the same 9 unrelated baseline failures.
|
|
- The 9 failures are the same pre-existing macOS baseline recorded by the active `detect-host-operating-system` change: Windows/GDI+ image rendering, Windows-path expectations, and Windows user-environment behavior. None exercises macOS audio capture or the shared mixer.
|
|
|
|
### Operational verification boundary
|
|
|
|
The live helpers were verified while the macOS display session was awake and produced the committed proof signal. The public endpoint path was verified deterministically in-process through the real registration, macOS source adapters, shared mixer, coordinator, and start/stop endpoints. A later attempt to repeat live ScreenCaptureKit capture under the transient `vstest`/console proof host could not enumerate a display after the built-in display entered the asleep state; ScreenCaptureKit returned `ScreenCaptureKit could not find a display for system-audio capture`. The production port-5090 service was deliberately not restarted or reconfigured with fake ASR dependencies. These are the reasons live native input and the public application path were verified in two complementary passes rather than one production meeting run.
|
|
|
|
The live Meeting Assistant service was not restarted, and no active recording or meeting artifacts were modified during verification.
|