Why
#71 introduced an internal audio.backend interface and split the implementation behind build tags, but on Windows the package currently uses backend_stub.go (a silent no-op). --vibes and --notify therefore do nothing on Windows builds. This issue tracks wiring a real Windows backend so audio reaches parity with macOS/Linux.
Where
internal/audio/backend.go — interface to implement (available, playLoop, fadeOut, stop, playSound)
internal/audio/backend_stub.go — current Windows fallback; has a TODO(#71) pointing at this work
internal/audio/backend_beep.go — reference implementation (gopxl/beep) for macOS / CGO-enabled builds
Library candidates
github.com/hajimehoshi/oto/v2 — pure-Go on Windows (DirectSound), CGO-free; same maintainer as ebitengine. Could also replace beep on Linux later if we want a single backend everywhere.
winmm via golang.org/x/sys/windows — call PlaySound / waveOutWrite directly. Smallest dependency footprint, most code to write (we'd own the decoder + mixing + fade ramp).
powershell -c (New-Object Media.SoundPlayer …).PlaySync() shim — easiest, but only WAV, no looping/fade, one process per sound. Probably not viable for --vibes.
Recommendation: try oto/v2 first. The beep mp3.Decode decoder is decoupled from the speaker and can be reused — the Windows backend would decode the embedded MP3s the same way and push samples to oto. Keeping the option open to consolidate to a single backend later.
Acceptance
Why
#71 introduced an internal
audio.backendinterface and split the implementation behind build tags, but on Windows the package currently usesbackend_stub.go(a silent no-op).--vibesand--notifytherefore do nothing on Windows builds. This issue tracks wiring a real Windows backend so audio reaches parity with macOS/Linux.Where
internal/audio/backend.go— interface to implement (available,playLoop,fadeOut,stop,playSound)internal/audio/backend_stub.go— current Windows fallback; has aTODO(#71)pointing at this workinternal/audio/backend_beep.go— reference implementation (gopxl/beep) for macOS / CGO-enabled buildsLibrary candidates
github.com/hajimehoshi/oto/v2— pure-Go on Windows (DirectSound), CGO-free; same maintainer as ebitengine. Could also replace beep on Linux later if we want a single backend everywhere.winmmviagolang.org/x/sys/windows— callPlaySound/waveOutWritedirectly. Smallest dependency footprint, most code to write (we'd own the decoder + mixing + fade ramp).powershell -c (New-Object Media.SoundPlayer …).PlaySync()shim — easiest, but only WAV, no looping/fade, one process per sound. Probably not viable for--vibes.Recommendation: try
oto/v2first. The beepmp3.Decodedecoder is decoupled from the speaker and can be reused — the Windows backend would decode the embedded MP3s the same way and push samples to oto. Keeping the option open to consolidate to a single backend later.Acceptance
internal/audio/backend_windows.go(build tagwindows) implements thebackendinterfacebackend_stub.goconstrained to its remaining cases (or removed entirely if every supported target has a real backend)--vibesplays the looping track on Windows with fade-in / fade-out--notifyplays success / error / ding sounds on WindowsCGO_ENABLED=0 GOOS=windows go build ./...cleanly