Audio System and Media Player

What is it?

The audio system is the software half of sound on Impossible OS: one kernel audio API, a mixer that plays several sounds at once, decoders for WAV, MP3, Ogg Vorbis and FLAC, and the programs on top (a media player, the volume overlay and the Sound applet, mmsys.cpl). None of its ten sections has shipped, and there is no audio hardware driver yet either, so today the OS makes no sound at all.

How does it work?

Today. Nothing in src/ or include/ plays audio. No sound card driver exists: the Audio Drivers roadmap that owns AC97, Intel HDA, VirtIO Sound and USB Audio is entirely open. The QEMU and VirtualBox launch scripts do not attach a sound device; run-vbox.sh passes --audio-driver none.

Planned design. The plan is layered so each piece can be tested on its own:

flowchart LR
    A[Media player, system sounds, apps] --> B["audio_load(path)"]
    B --> C[WAV / MP3 / OGG / FLAC decoders]
    C --> D[8-stream mixer]
    D --> E[audio_device_t driver vtable]
    E --> F[AC97, HDA, VirtIO Sound, USB Audio]

Abstraction layer. An audio_play, audio_stop, audio_set_volume and audio_is_playing API over whichever device the driver layer registers, with the master volume kept in the Registry.
Mixer. Up to eight PCM streams summed into 32-bit accumulators, clamped to 16 bits, scaled by master volume and fed to the device's DMA ring from its interrupt.
Decoders. Single-header libraries (dr_wav, dr_mp3, stb_vorbis, dr_flac) with their allocators redirected to the kernel heap for small clips and to pmm_alloc_contiguous() for anything over 4 KB, plus a linear resampler when a file's rate differs from the device's.
Loader. audio_load(path) picks the decoder from the extension, and audio_play_file() wraps load and play.
Programs. A media player (transport buttons, seek bar, ID3v2 title and artist, playlist, shuffle and repeat), volume in Quick Settings with a 196 by 48 pixel overlay pill for the volume keys, and mmsys.cpl for master volume, output device, system sounds and a test tone.

What are its interfaces?

Interface	Status
`audio_play()`, `audio_stop()`, `audio_set_volume()`, `audio_get_volume()`, `audio_is_playing()`	Planned
Mixer streams, `audio_load()`, `audio_play_file()`	Planned
Audio syscalls	Planned; numbers not assigned. The highest assigned `SYS_*` is 48 (`syscall.h`)
`HKLM\SYSTEM\Sound\Volume`, `HKCU\Software\Impossible\MediaPlayer\*`	Planned Registry values, through the shipped `RegSetDword()` and `RegGetDword()` (`registry.h`)
`pmm_alloc_contiguous()` for PCM buffers	Shipped (`pmm.h`)

How do I use it?

There is nothing to run yet. When the driver and the first two sections land, the test will be a WAV file played from cmd.exe on QEMU with an intel-hda device attached, and the roadmap's Verification section lists the checks for each decoder.

What is not implemented yet?

Everything in this roadmap, in dependency order:

Audio Abstraction Layer, which needs a driver from the Audio Drivers roadmap
Audio Mixer
WAV, MP3, Ogg Vorbis and FLAC decoders, none of which is vendored yet
Unified Audio Loader
Media Player App, Volume Control and mmsys.cpl

Two design questions are open in the roadmaps and need settling before code: the driver roadmap defines its own audio_device_t vtable and says the mixer lives on the desktop side, while this roadmap puts the mixer in the kernel; and mmsys.cpl is also specified, with different calls, in the Control Panel roadmap.

How does it compare with Windows 11 and Linux?

Windows 11 layers WASAPI over WaveRT drivers with a shared-mode mixer, and decodes WAV, MP3 and FLAC through Media Foundation, but has no built-in Ogg Vorbis decoder. Linux uses ALSA drivers with PipeWire or PulseAudio mixing in a user-space daemon and decodes everything through libraries such as FFmpeg. The Impossible OS plan is an in-kernel stack with no daemon: one driver vtable, one fixed-point mixer and one audio_load() call for all four formats. None of it exists yet.