System Requirements Document for audio-mixer-onie82

1. Introduction

ONIE82 PRO AUDIO MIXER is a professional Windows desktop application that functions as a real-time digital audio mixer with professional sound processing capabilities. It is built for live streaming, karaoke, singing, podcasting, radio broadcasting, and music playback through YouTube.

The application must be fully functional, not merely a UI mockup or prototype. All mixer controls, equalizers, audio effects, routing, and meters must be connected to a working real-time audio engine.

The product intent is a Windows-native real-time audio console whose operators — performers, broadcasters, and audio engineers — judge it the way they judge a hardware mixer: by whether the meters tell the truth and the controls feel machined. The audience are operators, not casual listeners; they work in dim rooms, at night, with headphones on, and they need technical confidence, tactile luxury, and calm authority under pressure.

Core mixing functions must work locally without requiring a cloud subscription.

2. System Overview

ONIE82 PRO AUDIO MIXER is delivered as a Windows 10 / Windows 11 64-bit desktop application built with C++ and the JUCE Framework (or an equivalent technology capable of high-quality real-time digital signal processing). It provides:

• Automatic soundcard detection across USB soundcards, built-in audio devices, USB headsets, and compatible audio interfaces (including devices such as the Siborie F999 soundcard through their available Windows drivers), with WASAPI and ASIO driver support, hot-plug handling, device-loss notification and reconnect, and configurable buffer size and latency.
• A multichannel mixer with at least four configurable channels — MIC 1, MIC 2, MUSIC, and SYSTEM AUDIO — each with independent signal routing so microphones and music can be sent to different outputs or recording/streaming destinations.
• A professional 10-band graphic equalizer for microphone and music channels with the fixed default center frequencies 31 Hz, 62 Hz, 125 Hz, 250 Hz, 500 Hz, 1 kHz, 2 kHz, 4 kHz, 8 kHz, and 16 kHz.
• A vocal delay with a dedicated TAP TEMPO button, BPM calculation from tap intervals, note-division synchronization, and runaway-feedback protection.
• A studio-quality vocal reverb module with six reverb types and continuous parameter control, operating simultaneously with EQ, compression, delay, and harmony without interrupting audio playback.

2a. Product Interpretation and Delivery Boundary

Delivery ownership. The product is a first-party Windows desktop application. Its audio engine, mixer surface, device management, EQ, delay, and reverb are all owned and rendered by the application itself. There is no cloud subscription requirement for core mixing functions, and no provider-owned surface carries any accepted mixing responsibility.

Access ownership. The application is a local, single-operator instrument. No accepted requirement establishes accounts, sign-in, roles, or differentiated permissions, and no accepted journey requires a human to privately own or resume durable actor-specific state across sessions. Every page in the current contract is therefore reachable without an identity gate. Device selection, buffer size, and channel configuration are session-local operator decisions, not entitlements bound to a participant.

External and provider boundaries. Two accepted behaviors depend on resources the application does not own:

• SYSTEM AUDIO capture depends on WASAPI loopback or a compatible virtual audio device being technically available on the machine. Support for browsers, media players, and other applications is limited to when technically available.
• MUSIC playback depends on local music files, supported streaming sources, or authorized playback sources. The application does not itself provide a streaming catalog; it accepts audio from those sources.

Current vs. future. Everything specified in this document is current. No future-horizon requirements were accepted in the authoritative thread.

2b. Source Content Inventory

Not applicable — no reference directive in this project declares a content_source.

2c. Page Content and Component Coverage

Landing

• Information/state: Anonymous first impression of ONIE82 PRO AUDIO MIXER. States the product name, its identity as a professional real-time Windows digital audio mixer, and the supported uses: live streaming, karaoke, singing, podcasting, radio broadcasting, and music playback through YouTube. States that core mixing functions work locally without a cloud subscription.
• Primary action: Enter the console (proceed to the mixer surface).
• Supporting actions: Reach device management; reach the mixer routing surface.
• Domain entities: Product identity, supported-use list, local-operation statement.
• Component responsibilities: Wordmark (Saira Condensed, letterspaced, left); a live device pill showing the currently selected device, driver type, sample rate, buffer size, and latency; a master meter that is already moving; the console composition itself as the dominant visual.
• States: Loading — device pill shows a resolving state while the engine enumerates devices. Empty — no device detected: pill reads as unavailable and the entry point to Devices is emphasized. Success — device pill populated, master meter live. Error — engine failed to start: pill shows the failure and the entry point to Audio Tests / Reset Audio Engine is emphasized. Recovery — after a successful reset or device selection, the pill and meter resume.

Devices

• Information/state: Inventory of detected audio devices. For each device: device name, driver type, available input/output channels, sample rate, and connection status. Covers USB soundcards, built-in audio devices, USB headsets, and compatible audio interfaces, including devices such as the Siborie F999 soundcard through their available Windows drivers. Distinguishes microphone inputs, speaker outputs, and headphone outputs. On first launch, the default audio device is selected automatically.
• Primary action: Inspect a detected device's details.
• Supporting actions: Refresh Device; proceed to Device Select; proceed to Audio Tests; proceed to Latency; proceed to Device Recovery.
• Domain entities: Audio device (name, driver type, input channels, output channels, sample rate, connection status, port role).
• Component responsibilities: Device detection as a port diagram rather than a dropdown list — each detected interface renders as a labelled panel with driver type, in/out channel counts, sample rate, a status ring (teal = connected, muted steel = available, red LED = lost), and inline Refresh / Test In / Test Out / Reset Engine controls in a ruled row. Ruled label/value rows with 2px hairlines.
• States: Loading — enumeration in progress, panels render as pending. Empty — no devices detected: explicit empty state with Refresh Device. Success — device panels populated with driver, channel, sample-rate, and status facts. Error — enumeration failure surfaced on the affected panel without discarding other panels. Recovery — Refresh Device re-runs detection; a previously lost device returns to connected status.

Device Select

• Information/state: Current input device selection and current output device selection, shown independently. Available devices for each role.
• Primary action: Select the input device and select the output device independently.
• Supporting actions: Refresh the device list; return to Devices.
• Domain entities: Input device selection, output device selection, device list.
• Component responsibilities: Two independent ruled selection rows (input, output) with the current selection marked; a Refresh control; device metadata shown inline so the operator can distinguish similarly named interfaces.
• States: Loading — list resolving. Empty — no selectable device for a role: that row states the absence and offers Refresh. Success — both roles bound to a device and the engine reconfigures. Error — a selected device fails to open: the row reverts to the previous working selection and states the failure. Recovery — choose another device or Refresh, then re-select.

Audio Tests

• Information/state: Current engine state and the result of the most recent test.
• Primary action: Run Test Input or Test Output.
• Supporting actions: Reset Audio Engine; return to Devices.
• Domain entities: Test result (input test, output test), engine state.
• Component responsibilities: Ruled rows for Test Input, Test Output, and Reset Audio Engine; a result readout per test; a live level indication during a test so the operator can confirm signal presence.
• States: Loading — test running. Empty — no test run yet in this session. Success — test reports signal detected on the tested path. Error — test reports no signal or a device-open failure. Recovery — Reset Audio Engine, then re-run the test.

Latency

• Information/state: Current buffer size and the resulting latency, alongside the current sample rate. Supported sample rates include 44.1 kHz, 48 kHz, and other sample rates supported by the selected device.
• Primary action: Set the buffer size.
• Supporting actions: Observe the resulting latency; return to Devices.
• Domain entities: Buffer size, latency, sample rate.
• Component responsibilities: A ruled buffer-size row with the value right-aligned in tabular numerals; a latency readout; a sample-rate readout reflecting the selected device.
• States: Loading — engine reconfiguring after a buffer change. Empty — no device bound: buffer and latency rows state that a device is required. Success — new buffer size applied and latency readout updated without corrupting the engine. Error — the device rejects the buffer size: the previous value is restored and the rejection is stated. Recovery — choose a supported buffer size or re-select the device.

Device Recovery

• Information/state: Hot-plug status. When a device becomes unavailable, the application automatically notifies the user and provides a reconnect option. Device changes are handled without crashing or corrupting the audio engine.
• Primary action: Reconnect an unavailable device.
• Supporting actions: Refresh Device; return to Devices; proceed to Device Select.
• Domain entities: Device availability event (connected, disconnected, lost), reconnect action.
• Component responsibilities: A status ring per affected device (teal = connected, muted steel = available, red LED = lost); an automatic unavailability notification; a reconnect control; a 200ms status-ring pulse on connect/disconnect.
• States: Loading — reconnect attempt in progress. Empty — no device events in this session. Success — device reconnected and the engine resumes without corruption. Error — reconnect fails because the device is still absent: the notification persists and the reconnect option remains available. Recovery — physically reconnect the device or Refresh Device, then reconnect.

Meters

• Information/state: Real-time input and output level meters, peak levels, and clipping indicators. Clipping is the only red in the system and appears exclusively as a peak-hold LED.
• Primary action: Observe levels and act on clipping.
• Supporting actions: Reach the channel that is clipping; reach feedback-loop prevention controls.
• Domain entities: Input level, output level, peak level, peak-hold state, clipping state.
• Component responsibilities: Meters updating at 60fps with 300ms peak-hold decay and a 1.5s peak-hold reset; dB gradations drawn as SVG meter scales; clipping LED; feedback-loop prevention between microphone inputs and outputs.
• States: Loading — engine starting, meters idle at floor. Empty — no signal present: meters rest at the floor with no clipping indication. Success — meters track signal truthfully and peak-hold decays as specified. Error — clipping detected: the peak-hold LED lights red. Recovery — reduce gain or fader level on the offending channel; the LED clears on the next peak-hold reset.

Mixer Routing

• Information/state: The four configurable mixer channels — MIC 1, MIC 2, MUSIC, SYSTEM AUDIO — and the master bus. Each channel's routing destination. All channels have independent signal routing so that microphones and music can be sent to different outputs or recording/streaming destinations.
• Primary action: Configure each channel's routing to an output or a recording/streaming destination.
• Supporting actions: Reach Microphones, Music, and System Audio channel surfaces; reach Meters.
• Domain entities: Channel (MIC 1, MIC 2, MUSIC, SYSTEM AUDIO), master bus, output destination, recording/streaming destination, routing assignment.
• Component responsibilities: A routing matrix drawn as a signal-flow diagram with right-angle traces; a horizontal bank of channel strips — MIC 1, MIC 2, MUSIC, SYSTEM, MASTER — each a vertical column with a fixed 96px minimum width, internally scrollable horizontally on narrow viewports with each strip fully reachable; the master strip 1.4× wider with a 72px condensed dB readout and a peak-hold LED.
• States: Loading — engine binding channels. Empty — no destination available: routing rows state the absence. Success — each channel routed to its intended destination and audible there. Error — a destination becomes unavailable: the affected routing row is marked and the channel is not silently rerouted. Recovery — re-select a destination or restore the device, then re-route.

Microphones

• Information/state: MIC 1 and MIC 2 channel state. MIC 1 provides input gain and trim, volume fader, mute and solo, stereo pan, phase inversion, high-pass filter, optional noise gate or expander, 10-band graphic equalizer, vocal compressor, vocal delay, vocal reverb, vocal harmony, and a real-time peak meter with clipping indicator. MIC 2 provides the same processing capabilities as MIC 1, subject to available physical input channels.
• Primary action: Set gain and trim, then ride the fader during a performance.
• Supporting actions: Mute, solo, pan, phase invert, engage the high-pass filter, engage the optional noise gate or expander, open the 10-band EQ, open the vocal compressor, open the vocal delay, open the vocal reverb, set vocal harmony.
• Domain entities: MIC 1 channel, MIC 2 channel, gain, trim, fader level, mute state, solo state, pan position, phase state, high-pass filter state, noise gate/expander state, compressor, delay, reverb, harmony, peak level, clipping state.
• Component responsibilities: Channel strips as physical instrument columns — inset fader grooves, chamfered tops, a champagne-amber cap, and a meter beside the fader rather than above it; a circular gain knob with a machined indicator line; a lower module bay of ruled 32px label/value rows for compressor, delay, reverb, and harmony.
• States: Loading — channel initializing against the bound input. Empty — MIC 2 unavailable because no physical input channel is available: the strip states the constraint rather than presenting dead controls. Success — processed vocal audible with live peak metering. Error — clipping or input loss: the clipping LED lights, or the input-loss state is stated on the strip. Recovery — reduce gain or fader, or restore the input device and reconnect.

Music

• Information/state: MUSIC channel state. Accepts audio from local music files, supported streaming sources, or authorized playback sources. Provides independent volume fader, mute, solo, pan, and peak meter; a dedicated 10-band music equalizer; a dedicated music compressor; an output limiter; safe stereo-width controls; and independent music and vocal level balancing.
• Primary action: Start and control music playback into the channel.
• Supporting actions: Ride the fader; mute; solo; pan; open the dedicated music EQ; open the music compressor; engage the output limiter; adjust stereo width; balance music against vocal level.
• Domain entities: Music source, playback state, fader level, mute state, solo state, pan position, music EQ, music compressor, output limiter, stereo width, music/vocal balance, peak level.
• Component responsibilities: A channel strip with the same machined column treatment; ruled label/value rows for compressor, limiter, stereo width, and music/vocal balance; a dedicated 10-band EQ panel with a live teal response curve.
• States: Loading — source opening. Empty — no source loaded: the strip states that a local file, supported streaming source, or authorized playback source is required. Success — music audible and metered, balanced against vocal level. Error — source unavailable or unsupported: the failure is stated without disturbing other channels. Recovery — choose another local file or authorized source and restart playback.

System Audio

• Information/state: SYSTEM AUDIO channel state. Captures audio from Windows applications using WASAPI loopback or a compatible virtual audio device. Supports audio from browsers, media players, and other applications when technically available. Provides volume fader, mute, peak meter, and routing controls. Captured audio can be sent to the master output or other supported buses.
• Primary action: Capture Windows application audio into the channel.
• Supporting actions: Ride the fader; mute; observe the peak meter; route the captured audio to the master output or another supported bus.
• Domain entities: Loopback/virtual capture source, capture state, fader level, mute state, routing assignment, peak level.
• Component responsibilities: A channel strip with the same machined column treatment; a ruled capture-source row naming the loopback or virtual device; routing rows for master and other supported buses.
• States: Loading — capture source opening. Empty — loopback or compatible virtual-device support not technically available: the strip states the limitation rather than presenting dead controls. Success — application audio captured, metered, and routed. Error — capture drops when the source application or device changes. Recovery — re-select the capture source or restore the device, then re-route.

Equalizer

• Information/state: The 10-band graphic equalizer for the selected microphone or music channel, with default center frequencies 31 Hz, 62 Hz, 125 Hz, 250 Hz, 500 Hz, 1 kHz, 2 kHz, 4 kHz, 8 kHz, and 16 kHz. Per-band gain adjustable from at least -12 dB to +12 dB. Independent EQ settings for each microphone and music channel.
• Primary action: Adjust per-band gain on vertical sliders.
• Supporting actions: EQ ON/OFF; Flat; Reset; Bypass; optional Q-factor or bandwidth adjustment; observe the visual frequency-response curve.
• Domain entities: Band (center frequency, gain), EQ enabled state, bypass state, Q-factor/bandwidth, frequency-response curve, per-channel EQ settings.
• Component responsibilities: The 10-band EQ drawn as a ruled instrument panel — ten vertical fader grooves on a fixed dB grid with 31 Hz–16 kHz labels in Barlow Semi Condensed, and a live teal response curve stroked over the grid at 2px with a soft outer glow only on the curve itself. High-quality filters with smooth parameter transitions and minimal audible artifacts.
• States: Loading — EQ binding to the selected channel. Empty — no channel selected: the panel states that a microphone or music channel must be selected. Success — band changes take effect in real time without stopping audio playback. Error — a parameter transition produces an artifact or a band value is rejected: the previous value is restored. Recovery — Reset or Flat returns the curve to a known state.

EQ Presets

• Information/state: The available EQ presets — Vocal Clear, Warm Vocal, Podcast, Radio Voice, Karaoke, and Music Enhancement — and which preset is currently applied to which channel.
• Primary action: Apply a preset to the selected microphone or music channel.
• Supporting actions: Return to Equalizer to refine the applied curve.
• Domain entities: Preset (Vocal Clear, Warm Vocal, Podcast, Radio Voice, Karaoke, Music Enhancement), target channel, applied state.
• Component responsibilities: Ruled preset rows with the applied preset marked; independent application per microphone and music channel.
• States: Loading — preset applying. Empty — no channel selected: preset rows state the requirement. Success — preset applied and audible immediately without stopping playback. Error — preset application fails: the previous curve is retained. Recovery — re-apply or return to Equalizer and set bands manually.

Vocal Delay

• Information/state: The vocal delay module with its dedicated TAP TEMPO button. Users tap the button repeatedly to match the rhythm of the playing music; BPM is calculated automatically from the intervals between taps and displayed in real time. Initial BPM range is 40–240 BPM. Delay time synchronizes to musical note divisions: 1/1, 1/2, 1/4, 1/8, 1/16, dotted 1/8, and triplet 1/8 note.
• Primary action: Tap the TAP TEMPO button repeatedly in time with the music.
• Supporting actions: Select a note division; enable or disable Tempo Sync; observe the detected BPM.
• Domain entities: Tap event, tap interval, detected BPM, note division, tempo-sync state.
• Component responsibilities: The tap-tempo beat ring — a circular gauge around the TAP button whose champagne-amber arc sweeps once per detected beat, with the BPM set in 44px condensed tabular numerals inside the ring and the note division as a ruled row of small caps chips beneath it.
• States: Loading — awaiting the first tap. Empty — no taps registered: BPM readout is blank and the ring is at rest. Success — BPM detected within 40–240 BPM and the beat ring sweeps once per beat. Error — taps fall outside the 40–240 BPM range or are too irregular to resolve: the readout states that the tempo could not be resolved. Recovery — tap again at a steadier interval.

Delay Controls

• Information/state: Delay feedback, wet/dry mix, delay level, stereo ping-pong delay mode, mono delay mode, tempo sync ON/OFF, optional Freeze or Hold mode, and delay ON/OFF and bypass state. Runaway feedback and uncontrolled volume increases are prevented.
• Primary action: Set feedback, wet/dry mix, and delay level.
• Supporting actions: Choose stereo ping-pong or mono mode; toggle Tempo Sync; engage optional Freeze or Hold; toggle delay ON/OFF; bypass.
• Domain entities: Feedback amount, wet/dry mix, delay level, delay mode, tempo-sync state, freeze/hold state, bypass state.
• Component responsibilities: Ruled 32px label/value rows with the label left in muted steel small caps and the value right-aligned in tabular numerals, separated by 2px hairlines; runaway-feedback protection applied in the engine.
• States: Loading — delay module initializing. Empty — delay bypassed: rows remain readable and operable. Success — delay audible with the set feedback, mix, level, and mode, processed at low latency in real time. Error — feedback would run away or volume would increase uncontrolled: the engine prevents it and the condition is surfaced. Recovery — reduce feedback or level, or bypass the delay.

Tempo

• Information/state: The visual beat indicator and the detected tempo display used to synchronize vocal delay with music.
• Primary action: Read the beat indicator and tempo while tapping or while Tempo Sync is engaged.
• Supporting actions: Return to Vocal Delay to re-tap or change the note division.
• Domain entities: Beat indicator state, detected BPM, note division.
• Component responsibilities: The champagne-amber beat arc sweeping clockwise once per beat so tempo is legible from across the room; BPM in 44px condensed tabular numerals; the note-division chips as a ruled row.
• States: Loading — awaiting tempo. Empty — no tempo detected: indicator at rest. Success — indicator sweeps in time with the detected BPM. Error — tempo lost or out of range: the indicator stops and the readout states the condition. Recovery — re-tap in Vocal Delay.

Reverb

• Information/state: The vocal reverb module with types Room, Hall, Plate, Chamber, Spring, and Vocal Studio. Controls: Decay Time, Pre-delay, Wet/Dry Mix, Reverb Level, Room Size, Damping, High Cut and Low Cut, Stereo Width, Early Reflections, and Reverb ON/OFF and Bypass.
• Primary action: Select a reverb type and set its parameters.
• Supporting actions: Toggle reverb ON/OFF; bypass.
• Domain entities: Reverb type, decay time, pre-delay, wet/dry mix, reverb level, room size, damping, high cut, low cut, stereo width, early reflections, bypass state.
• Component responsibilities: Ruled 32px label/value rows for every parameter; a type selector as a ruled row of small caps chips; reverb operating simultaneously with EQ, compression, delay, and harmony without interrupting audio playback.
• States: Loading — reverb module initializing. Empty — reverb bypassed: rows remain readable and operable. Success — reverb audible with the selected type and parameters while EQ, compression, delay, and harmony continue uninterrupted. Error — a parameter change would interrupt playback or a value is rejected: the previous value is retained. Recovery — re-select the type or reset the parameter.

Reverb Presets

• Information/state: The available reverb presets — Male Vocal, Female Vocal, Live Singing, Podcast Ambience, and Big Hall — and which preset is currently applied.
• Primary action: Apply a reverb preset.
• Supporting actions: Return to Reverb to refine parameters.
• Domain entities: Preset (Male Vocal, Female Vocal, Live Singing, Podcast Ambience, Big Hall), applied state.
• Component responsibilities: Ruled preset rows with the applied preset marked; preset application must not interrupt EQ, compression, delay, or harmony.
• States: Loading — preset applying. Empty — no preset applied yet. Success — preset applied and audible with all other processing still running. Error — preset application fails: the previous reverb settings are retained. Recovery — re-apply or return to Reverb and set parameters manually.

3. Functional Requirements

Platform and Delivery

FR-1 — Windows desktop delivery (explicit) As a Live Performer / Karaoke Singer, I should run ONIE82 PRO AUDIO MIXER as a 64-bit Windows desktop application on Windows 10 and Windows 11, so that I can operate a professional mixer on my own machine.

• Trigger/input: Launch the application on a Windows 10 or Windows 11 64-bit system.
• Observable result: The application opens and its console surface is usable.
• Access state: No identity gate.
• Failure/recovery: If the OS is not a supported 64-bit Windows version, the application does not run.
• Continuation: Proceed to device detection and mixing.

FR-2 — Real-time engine, not a mockup (explicit) As an Audio Engineer / Mix Operator, I should have every mixer control, equalizer, audio effect, routing control, and meter connected to a working real-time audio engine, so that the application is fully functional rather than a UI mockup or prototype.

• Trigger/input: Any control change on any channel, EQ, effect, routing, or meter.
• Observable result: The audible signal and the meters change accordingly in real time.
• Access state: No identity gate.
• Failure/recovery: If the engine fails to start, the failure is surfaced and Reset Audio Engine is available.
• Continuation: Continue operating the console.

FR-3 — Local operation without cloud subscription (explicit) As a Live Performer / Karaoke Singer, I should use all core mixing functions locally without a cloud subscription, so that a performance is never blocked by connectivity or billing.

• Trigger/input: Use any core mixing function.
• Observable result: The function works with no cloud subscription and no network dependency.
• Access state: No identity gate.
• Failure/recovery: Not applicable — local operation is the baseline.
• Continuation: Continue the session offline.

FR-4 — Windows executable and installer (explicit) As an Audio Engineer / Mix Operator, I should receive a Windows executable (.exe) and an installer when the build environment supports them, so that the application can be deployed on a Windows machine.

• Trigger/input: Build the project in an environment that supports Windows packaging.
• Observable result: A .exe and an installer are produced.
• Access state: No identity gate.
• Failure/recovery: If the build environment does not support them, the executable and installer are not produced; this is a build-environment limitation, not a product behavior.
• Continuation: Install and launch the application.

FR-5 — Professional console interface (explicit) As a Live Performer / Karaoke Singer, I should work in a modern, professional user interface inspired by high-end digital mixing consoles, so that the software reads and operates like a real instrument.

• Trigger/input: Open the console surface.
• Observable result: The interface presents channel strips, meters, faders, and module bays in a console-first layout.
• Access state: No identity gate.
• Failure/recovery: Not applicable.
• Continuation: Operate the console.

FR-6 — Sample rate support (explicit) As an Audio Engineer / Mix Operator, I should run the engine at 44.1 kHz, 48 kHz, and other sample rates supported by the selected device, so that the mixer matches my hardware.

• Trigger/input: Select a device and a sample rate it supports.
• Observable result: The engine runs at the selected sample rate and the rate is displayed.
• Access state: No identity gate.
• Failure/recovery: If the device does not support a rate, that rate is not offered for that device.
• Continuation: Continue mixing at the selected rate.

FR-7 — Stereo low-latency processing (explicit) As a Live Performer / Karaoke Singer, I should have stereo audio processing with low latency, so that my monitored vocal stays in time with the music.

• Trigger/input: Perform with a microphone and music playing.
• Observable result: Stereo processing runs with low latency and the latency figure is visible.
• Access state: No identity gate.
• Failure/recovery: If latency is too high, reduce the buffer size in Latency.
• Continuation: Continue performing.

Automatic Soundcard Detection

FR-8 — Automatic device detection (explicit) As an Audio Engineer / Mix Operator, I should have the application automatically detect connected audio devices — USB soundcards, built-in audio devices, USB headsets, and compatible audio interfaces — so that I do not have to configure hardware manually.

• Trigger/input: Launch the application or connect a device.
• Observable result: Detected devices appear in the device inventory.
• Access state: No identity gate.
• Failure/recovery: If detection finds nothing, Refresh Device re-runs detection.
• Continuation: Inspect or select a device.

FR-9 — Siborie F999 and comparable interfaces (explicit) As an Audio Engineer / Mix Operator, I should be able to use devices such as the Siborie F999 soundcard through their available Windows drivers, so that my specific hardware works with the mixer.

• Trigger/input: Connect the device with its Windows driver installed.
• Observable result: The device is detected and selectable with its driver type and channel counts shown.
• Access state: No identity gate.
• Failure/recovery: If the driver is unavailable, the device does not appear; install the vendor driver and Refresh Device.
• Continuation: Select the device for input or output.

FR-10 — Input, speaker, and headphone detection (explicit) As an Audio Engineer / Mix Operator, I should have microphone inputs, speaker outputs, and headphone outputs detected, so that I can route to the correct physical ports.

• Trigger/input: Device enumeration.
• Observable result: Each device's port role is identified in the inventory.
• Access state: No identity gate.
• Failure/recovery: If a port role cannot be determined, the device is still listed with its available channels.
• Continuation: Select input and output devices.

FR-11 — Device detail display (explicit) As an Audio Engineer / Mix Operator, I should see device name, driver type, available input/output channels, sample rate, and connection status for each device, so that I can choose correctly between similarly named interfaces.

• Trigger/input: Open Devices.
• Observable result: Each device panel shows name, driver type, in/out channel counts, sample rate, and a status ring.
• Access state: No identity gate.
• Failure/recovery: If a field is unavailable from the driver, it is shown as unavailable rather than fabricated.
• Continuation: Select the device.

FR-12 — First-launch default device selection (explicit) As a Live Performer / Karaoke Singer, I should have the default audio device selected automatically on first launch, so that I can start working immediately.

• Trigger/input: First launch of the application.
• Observable result: A default input and output device are bound and the engine is running.
• Access state: No identity gate.
• Failure/recovery: If no default device exists, the empty state directs me to Device Select.
• Continuation: Adjust selection if needed.

FR-13 — Independent input and output selection (explicit) As an Audio Engineer / Mix Operator, I should select input and output devices independently, so that I can capture from one interface and monitor on another.

• Trigger/input: Choose an input device and an output device in Device Select.
• Observable result: The engine binds the chosen input and output separately and both are shown.
• Access state: No identity gate.
• Failure/recovery: If a chosen device fails to open, the previous working selection is restored and the failure is stated.
• Continuation: Continue mixing with the new routing.

FR-14 — Hot-plug detection (explicit) As an Audio Engineer / Mix Operator, I should have hot-plug detection when audio devices are connected or disconnected, so that the mixer reflects reality without a restart.

• Trigger/input: Connect or disconnect a device while the application is running.
• Observable result: The device inventory and status rings update; a 200ms status-ring pulse marks the change.
• Access state: No identity gate.
• Failure/recovery: If the engine is affected, it recovers without crashing or corrupting.
• Continuation: Continue the session.

FR-15 — Unavailability notification and reconnect (explicit) As an Audio Engineer / Mix Operator, I should be automatically notified when a device becomes unavailable and be given a reconnect option, so that I can restore the signal path quickly.

• Trigger/input: A bound device becomes unavailable.
• Observable result: A notification appears and a reconnect control is offered.
• Access state: No identity gate.
• Failure/recovery: If reconnect fails because the device is still absent, the notification persists and reconnect remains available.
• Continuation: Reconnect, or select a different device.

FR-16 — Refresh Device, Test Input, Test Output, Reset Audio Engine (explicit) As an Audio Engineer / Mix Operator, I should have Refresh Device, Test Input, Test Output, and Reset Audio Engine controls, so that I can diagnose and recover the audio path.

• Trigger/input: Activate any of the four controls.
• Observable result: Refresh re-enumerates devices; Test Input and Test Output report signal presence on the tested path; Reset Audio Engine restarts the engine.
• Access state: No identity gate.
• Failure/recovery: If a test reports no signal, Reset Audio Engine and re-test.
• Continuation: Return to mixing once the path is confirmed.

FR-17 — Real-time level, peak, and clipping display (explicit) As a Live Performer / Karaoke Singer, I should see real-time input/output level meters, peak levels, and clipping indicators, so that I can keep levels safe.

• Trigger/input: Signal present on any input or output.
• Observable result: Meters track at 60fps with 300ms peak-hold decay and a 1.5s peak-hold reset; clipping lights the peak-hold LED.
• Access state: No identity gate.
• Failure/recovery: If clipping occurs, reduce gain or fader level; the LED clears on the next peak-hold reset.
• Continuation: Continue performing.

FR-18 — Feedback-loop prevention (explicit) As an Audio Engineer / Mix Operator, I should have audio feedback loops between microphone inputs and outputs prevented, so that the system does not howl.

• Trigger/input: A routing configuration that would create a microphone input-to-output loop.
• Observable result: The loop is prevented.
• Access state: No identity gate.
• Failure/recovery: If a loop condition is detected, it is prevented and surfaced.
• Continuation: Continue mixing with a safe routing.

FR-19 — Configurable buffer size and latency (explicit) As an Audio Engineer / Mix Operator, I should configure buffer size and latency settings, so that I can trade latency against stability for my machine.

• Trigger/input: Change the buffer size in Latency.
• Observable result: The buffer size applies and the latency readout updates.
• Access state: No identity gate.
• Failure/recovery: If the device rejects the buffer size, the previous value is restored and the rejection is stated.
• Continuation: Continue mixing at the accepted buffer size.

FR-20 — Device changes without engine corruption (explicit) As an Audio Engineer / Mix Operator, I should have device changes handled without crashing or corrupting the audio engine, so that a mid-session unplug does not end the show.

• Trigger/input: Any device connect, disconnect, or loss event.
• Observable result: The engine remains stable and recovers its state.
• Access state: No identity gate.
• Failure/recovery: If the engine is disrupted, Reset Audio Engine restores it.
• Continuation: Reconnect the device and continue.

Multichannel Mixer

FR-21 — At least four configurable channels (explicit) As an Audio Engineer / Mix Operator, I should have at least four configurable mixer channels, so that microphones, music, and system audio can be mixed together.

• Trigger/input: Open Mixer Routing.
• Observable result: MIC 1, MIC 2, MUSIC, and SYSTEM AUDIO channels are present and configurable.
• Access state: No identity gate.
• Failure/recovery: If a channel's source is unavailable, that channel states the constraint.
• Continuation: Configure and mix the channels.

FR-22 — MIC 1 processing chain (explicit) As a Live Performer / Karaoke Singer, I should have MIC 1 provide input gain and trim, volume fader, mute and solo, stereo pan, phase inversion, high-pass filter, optional noise gate or expander, 10-band graphic equalizer, vocal compressor, vocal delay, vocal reverb, vocal harmony, and a real-time peak meter with clipping indicator, so that my vocal is fully processed in real time.

• Trigger/input: Speak or sing into the microphone bound to MIC 1.
• Observable result: The processed vocal is audible with live peak metering and clipping indication.
• Access state: No identity gate.
• Failure/recovery: If the input is lost, the strip states the loss and Device Recovery offers reconnect.
• Continuation: Continue performing.

FR-23 — MIC 2 parity (explicit) As a Live Performer / Karaoke Singer, I should have MIC 2 provide the same processing capabilities as MIC 1, subject to available physical input channels, so that a second vocalist gets the same treatment.

• Trigger/input: Bind a second physical input channel to MIC 2.
• Observable result: MIC 2 exposes the same processing chain as MIC 1.
• Access state: No identity gate.
• Failure/recovery: If no second physical input channel is available, MIC 2 states the constraint rather than presenting dead controls.
• Continuation: Continue performing with the available channels.

FR-24 — MUSIC channel (explicit) As a Live Performer / Karaoke Singer, I should have a MUSIC channel that accepts audio from local music files, supported streaming sources, or authorized playback sources, with an independent volume fader, mute, solo, pan, and peak meter, a dedicated 10-band music equalizer, a dedicated music compressor, an output limiter, safe stereo-width controls, and independent music and vocal level balancing, so that backing music sits correctly under the vocal.

• Trigger/input: Load a local file or an authorized playback source into the MUSIC channel.
• Observable result: Music plays, is metered, and can be balanced against the vocal.
• Access state: No identity gate.
• Failure/recovery: If the source is unavailable or unsupported, the failure is stated without disturbing other channels.
• Continuation: Continue the performance with music and vocal balanced.

FR-25 — SYSTEM AUDIO channel (explicit) As a Broadcaster / Podcast Producer, I should have a SYSTEM AUDIO channel that captures audio from Windows applications using WASAPI loopback or a compatible virtual audio device, supports audio from browsers, media players, and other applications when technically available, provides volume fader, mute, peak meter, and routing controls, and allows the captured audio to be sent to the master output or other supported buses, so that I can mix application audio into the show.

• Trigger/input: Select a loopback or compatible virtual capture source.
• Observable result: Application audio is captured, metered, and routed to the chosen bus.
• Access state: No identity gate.
• Failure/recovery: If loopback or a compatible virtual device is not technically available, the channel states the limitation; if capture drops, re-select the source.
• Continuation: Continue the broadcast with application audio in the mix.

FR-26 — Independent signal routing per channel (explicit) As a Broadcaster / Podcast Producer, I should have all channels independently routed so that microphones and music can be sent to different outputs or recording/streaming destinations, so that I can deliver separate mixes to separate places.

• Trigger/input: Assign a destination to each channel in Mixer Routing.
• Observable result: Each channel reaches its assigned destination independently.
• Access state: No identity gate.
• Failure/recovery: If a destination becomes unavailable, the affected routing row is marked and the channel is not silently rerouted.
• Continuation: Re-route or restore the destination.

10-Band Graphic Equalizer

FR-27 — Ten fixed default center frequencies (explicit) As an Audio Engineer / Mix Operator, I should have a professional 10-band graphic equalizer for microphone and music channels using the default center frequencies 31 Hz, 62 Hz, 125 Hz, 250 Hz, 500 Hz, 1 kHz, 2 kHz, 4 kHz, 8 kHz, and 16 kHz, so that EQ work is predictable and repeatable.

• Trigger/input: Open Equalizer for a microphone or music channel.
• Observable result: Ten bands are presented at exactly those center frequencies.
• Access state: No identity gate.
• Failure/recovery: Not applicable.
• Continuation: Adjust bands.

FR-28 — Per-band gain range (explicit) As an Audio Engineer / Mix Operator, I should adjust gain from at least -12 dB to +12 dB per band, so that I have enough range for corrective and creative work.

• Trigger/input: Move a band slider.
• Observable result: The band gain changes within at least -12 dB to +12 dB.
• Access state: No identity gate.
• Failure/recovery: If a value is rejected, the previous value is restored.
• Continuation: Continue adjusting.

FR-29 — Vertical sliders and response curve (explicit) As an Audio Engineer / Mix Operator, I should have vertical sliders and a visual frequency-response curve, so that I can see the shape I am applying.

• Trigger/input: Adjust any band.
• Observable result: The teal response curve redraws over the 10-band grid in real time.
• Access state: No identity gate.
• Failure/recovery: Not applicable.
• Continuation: Continue shaping the curve.

FR-30 — EQ ON/OFF, Flat, Reset, Bypass (explicit) As an Audio Engineer / Mix Operator, I should have EQ ON/OFF, Flat, Reset, and Bypass controls, so that I can compare and recover quickly.

• Trigger/input: Activate any of the four controls.
• Observable result: ON/OFF toggles processing; Flat sets all bands to flat; Reset returns the EQ to its default state; Bypass removes the EQ from the signal path.
• Access state: No identity gate.
• Failure/recovery: Reset or Flat always returns the curve to a known state.
• Continuation: Continue mixing.

FR-31 — EQ presets (explicit) As a Broadcaster / Podcast Producer, I should have the presets Vocal Clear, Warm Vocal, Podcast, Radio Voice, Karaoke, and Music Enhancement, so that I can reach a usable voice or music curve immediately.

• Trigger/input: Apply a preset in EQ Presets.
• Observable result: The preset curve is applied and audible immediately.
• Access state: No identity gate.
• Failure/recovery: If application fails, the previous curve is retained.
• Continuation: Refine in Equalizer if needed.

FR-32 — Real-time EQ changes without stopping playback (explicit) As a Live Performer / Karaoke Singer, I should hear EQ changes in real time without stopping audio playback, so that I can tune during a performance.

• Trigger/input: Change any EQ parameter while audio is playing.
• Observable result: The change is audible immediately and playback continues uninterrupted.
• Access state: No identity gate.
• Failure/recovery: If a transition produces an artifact, the previous value is restored.
• Continuation: Continue performing.

FR-33 — Independent EQ per channel (explicit) As an Audio Engineer / Mix Operator, I should have independent EQ settings for each microphone and music channel, so that each source keeps its own curve.

• Trigger/input: Switch between channels in Equalizer.
• Observable result: Each channel retains its own band settings.
• Access state: No identity gate.
• Failure/recovery: Not applicable.
• Continuation: Continue tuning each channel.

FR-34 — Optional Q-factor or bandwidth adjustment (explicit) As an Audio Engineer / Mix Operator, I should be able to adjust Q-factor or bandwidth, so that I can control how wide each band's effect is.

• Trigger/input: Adjust the Q-factor or bandwidth control.
• Observable result: The band's width changes and the response curve reflects it.
• Access state: No identity gate.
• Failure/recovery: If a value is rejected, the previous value is restored.
• Continuation: Continue tuning.

FR-35 — High-quality filters and smooth transitions (explicit) As an Audio Engineer / Mix Operator, I should have high-quality filters with smooth parameter transitions and minimal audible artifacts, so that tuning never introduces noise or zipper artifacts.

• Trigger/input: Move any EQ parameter.
• Observable result: The transition is smooth with minimal audible artifacts.
• Access state: No identity gate.
• Failure/recovery: If an artifact occurs, the previous value is restored.
• Continuation: Continue tuning.

Vocal Delay with Tap Tempo

FR-36 — Tap tempo BPM detection (explicit) As a Live Performer / Karaoke Singer, I should tap the dedicated TAP TEMPO button repeatedly to match the rhythm of the playing music, with BPM calculated automatically from the intervals between taps and displayed in real time, so that the delay locks to the song.

• Trigger/input: Repeated taps on the TAP TEMPO button.
• Observable result: The detected BPM is displayed in real time and the beat ring sweeps once per beat.
• Access state: No identity gate.
• Failure/recovery: If taps are too irregular or fall outside 40–240 BPM, the readout states that the tempo could not be resolved.
• Continuation: Tap again at a steadier interval.

FR-37 — Initial BPM range 40–240 (explicit) As a Live Performer / Karaoke Singer, I should have an initial BPM range of 40–240 BPM, so that the delay covers the tempos I actually perform.

• Trigger/input: Tap tempo.
• Observable result: Detected BPM is resolved within 40–240 BPM.
• Access state: No identity gate.
• Failure/recovery: Taps outside the range do not resolve to a BPM.
• Continuation: Re-tap within range.

FR-38 — Note-division synchronization (explicit) As a Live Performer / Karaoke Singer, I should synchronize delay time to the note divisions 1/1, 1/2, 1/4, 1/8, 1/16, dotted 1/8, and triplet 1/8 note, so that the delay sits musically against the beat.

• Trigger/input: Select a note division.
• Observable result: Delay time follows the selected division relative to the detected BPM.
• Access state: No identity gate.
• Failure/recovery: If no tempo is detected, the division has no effect until a tempo exists.
• Continuation: Continue performing.

FR-39 — Delay controls (explicit) As an Audio Engineer / Mix Operator, I should have feedback control, wet/dry mix, delay level, stereo ping-pong delay mode, mono delay mode, tempo sync ON/OFF, optional Freeze or Hold mode, and delay ON/OFF and bypass controls, so that I can shape the delay fully.

• Trigger/input: Adjust any delay control.
• Observable result: The delay changes audibly in real time.
• Access state: No identity gate.
• Failure/recovery: If a value would cause runaway feedback, the engine prevents it and surfaces the condition.
• Continuation: Continue performing.

FR-40 — Runaway feedback prevention (explicit) As an Audio Engineer / Mix Operator, I should have runaway feedback and uncontrolled volume increases prevented, so that the delay can never blow up the mix.

• Trigger/input: Increase feedback or level toward an unstable setting.
• Observable result: The engine prevents runaway feedback and uncontrolled volume increase.
• Access state: No identity gate.
• Failure/recovery: Reduce feedback or level, or bypass the delay.
• Continuation: Continue performing.

FR-41 — Low-latency real-time delay processing (explicit) As a Live Performer / Karaoke Singer, I should have the delay processed at low latency in real time, so that the effect stays in time with my voice.

• Trigger/input: Sing with the delay engaged.
• Observable result: The delay is audible with low latency.
• Access state: No identity gate.
• Failure/recovery: If latency is too high, reduce the buffer size in Latency.
• Continuation: Continue performing.

FR-42 — Visual beat indicator and tempo display (explicit) As a Live Performer / Karaoke Singer, I should have a visual beat indicator and tempo display to help me synchronize vocal delay with music, so that I can see the tempo from across the room.

• Trigger/input: A detected tempo.
• Observable result: The champagne-amber beat arc sweeps once per beat and the BPM is shown in condensed tabular numerals.
• Access state: No identity gate.
• Failure/recovery: If tempo is lost, the indicator stops and the readout states the condition.
• Continuation: Re-tap in Vocal Delay.

Professional Vocal Reverb

FR-43 — Six reverb types (explicit) As a Live Performer / Karaoke Singer, I should have a studio-quality vocal reverb module with the types Room, Hall, Plate, Chamber, Spring, and Vocal Studio, so that I can match the space to the material.

• Trigger/input: Select a reverb type.
• Observable result: The reverb character changes to the selected type.
• Access state: No identity gate.
• Failure/recovery: If a type change would interrupt playback, the previous type is retained.
• Continuation: Continue performing.

FR-44 — Reverb parameter controls (explicit) As an Audio Engineer / Mix Operator, I should have Decay Time, Pre-delay, Wet/Dry Mix, Reverb Level, Room Size, Damping, High Cut and Low Cut, Stereo Width, Early Reflections, and Reverb ON/OFF and Bypass controls, so that I can shape the reverb precisely.

• Trigger/input: Adjust any reverb parameter.
• Observable result: The reverb changes audibly in real time.
• Access state: No identity gate.
• Failure/recovery: If a value is rejected, the previous value is retained.
• Continuation: Continue performing.

FR-45 — Reverb presets (explicit) As a Broadcaster / Podcast Producer, I should have presets for Male Vocal, Female Vocal, Live Singing, Podcast Ambience, and Big Hall, so that I can reach a usable space immediately.

• Trigger/input: Apply a reverb preset.
• Observable result: The preset is applied and audible.
• Access state: No identity gate.
• Failure/recovery: If application fails, the previous reverb settings are retained.
• Continuation: Refine in Reverb if needed.

FR-46 — Simultaneous processing without interruption (explicit) As a Live Performer / Karaoke Singer, I should have reverb operate simultaneously with EQ, compression, delay, and harmony without interrupting audio playback, so that the full vocal chain runs live.

• Trigger/input: Engage reverb alongside EQ, compression, delay, and harmony.
• Observable result: All processors run together and audio playback is never interrupted.
• Access state: No identity gate.
• Failure/recovery: If a change would interrupt playback, the previous value is retained.
• Continuation: Continue performing.

4. User Personas

Live Performer / Karaoke Singer

Product context. This persona runs live singing, karaoke, and streaming sessions where microphone vocals must be processed in real time. They are on stage or in front of a camera, often in a dim room, wearing headphones, and they cannot stop the performance to fix software.

Primary goal. A clean, latency-free vocal mix that stays synchronized with the backing music throughout the performance.

Distinct accepted responsibilities. This persona is the only one whose work is judged in the moment by ear: they set mic gain and trim and ride the fader while singing, apply EQ, compression, delay with tap tempo, reverb, and harmony to their own voice, and watch peak meters and clipping indicators to keep levels safe. They are the persona who taps the TAP TEMPO button in time with the song and reads the beat ring from across the room. They also select and monitor input and output devices, but they do so as a performer checking their own monitoring path, not as a system configurator.

Relevant inputs and decisions. Microphone level and tone; the tempo of the song being performed; how much delay, reverb, and harmony the arrangement needs; whether the music is sitting correctly under the vocal; whether the meters show headroom or clipping.

Interactions with other accepted participants. The Live Performer depends on the Audio Engineer / Mix Operator having established a stable engine, correct device selection, and safe routing before the set. During a performance, the Live Performer works the Microphones, Music, Equalizer, EQ Presets, Vocal Delay, Delay Controls, Tempo, Reverb, Reverb Presets, and Meters surfaces. If a device is lost mid-set, the Live Performer is the one who feels it first and who must be told what happened.

Observable success. The vocal is audible, processed, and in time with the music; the beat ring sweeps with the song; the meters show signal without clipping; the performance continues without interruption.

Broadcaster / Podcast Producer

Product context. This persona produces radio broadcasts, podcasts, and streamed shows that combine spoken voice with music and system audio. Their output goes to an audience, so consistency matters more than improvisation, and a silent or clipped segment is a visible failure.

Primary goal. A consistent, broadcast-ready mix delivered to the intended destinations without feedback or clipping.

Distinct accepted responsibilities. This persona is the only one whose core work is balancing independent sources against each other and delivering them to separate destinations. They balance the mic, music, and system-audio channels; route each channel to the required output or recording/streaming destination; and apply voice-oriented EQ presets and compression. They are the persona who captures Windows application audio — browsers, media players, and other applications when technically available — into the SYSTEM AUDIO channel and sends it to the master output or another supported bus. They also apply reverb presets such as Podcast Ambience and Male or Female Vocal.

Relevant inputs and decisions. Which sources belong in the show; how much music sits under the voice; whether application audio needs to be captured at all; which destination each channel feeds; whether the voice needs a broadcast curve or a warmer one.

Interactions with other accepted participants. The Broadcaster depends on the Audio Engineer / Mix Operator for a stable engine and correct routing infrastructure, and on the Live Performer when a show includes live singing. The Broadcaster works the Music, System Audio, Mixer Routing, Equalizer, EQ Presets, Reverb, Reverb Presets, and Meters surfaces.

Observable success. Every channel reaches its intended destination; the voice is consistent and intelligible; music and application audio sit correctly under it; no feedback and no clipping reach the audience.

Audio Engineer / Mix Operator

Product context. This persona configures and maintains the mixer's audio engine and signal chain for a session. They are the person who is called when something is wrong, and they judge the software by whether it behaves like a trustworthy instrument.

Primary goal. A stable, low-latency engine with correctly routed, artifact-free channels that survive device changes.

Distinct accepted responsibilities. This persona is the only one whose work is the engine and the signal path itself. They detect and select devices, set buffer size and latency, refresh or reset the audio engine, handle hot-plug and device-loss notifications with reconnect, and tune per-channel processing, routing, and EQ presets. They are the persona who runs Test Input, Test Output, and Reset Audio Engine, and who reads device driver type, channel counts, sample rate, and connection status to choose correctly between interfaces. They also configure the optional noise gate or expander and the optional Q-factor or bandwidth adjustment.

Relevant inputs and decisions. Which interfaces are connected and what drivers they expose; how much latency the machine can sustain; whether a channel's problem is a device, a routing, or a processing issue; whether a device change requires a reconnect or a full engine reset.

Interactions with other accepted participants. The Audio Engineer prepares the engine and routing that the Live Performer and the Broadcaster depend on, and is the person who responds when either of them loses a device mid-session. They work the Devices, Device Select, Audio Tests, Latency, Device Recovery, Mixer Routing, Microphones, Equalizer, and Meters surfaces.

Observable success. The engine runs at the chosen sample rate and buffer size; every channel is routed as intended; device changes are absorbed without a crash or a corrupted engine; the meters tell the truth.

5. Core User Flows

Flow 1 — Live Performer / Karaoke Singer: run a live vocal performance

1. Starting context. The Live Performer opens ONIE82 PRO AUDIO MIXER on a Windows 10 or 11 64-bit machine. The Audio Engineer has already bound the input and output devices and set the buffer size, or the application has auto-selected the default device on first launch.
2. On Landing, the device pill shows the bound device, driver type, sample rate, buffer size, and latency, and the master meter is already moving. The performer enters the console.
3. On Microphones, the performer sets MIC 1 input gain and trim using the circular gain knob, watching the strip's peak meter beside the fader. If a second vocalist is present and a second physical input channel is available, MIC 2 is configured the same way; if no second physical input channel is available, MIC 2 states that constraint.
4. The performer engages the high-pass filter and, if needed, the optional noise gate or expander, then opens the vocal compressor and sets it so the voice stays even.
5. On Equalizer, the performer shapes the vocal across the ten bands at 31 Hz, 62 Hz, 125 Hz, 250 Hz, 500 Hz, 1 kHz, 2 kHz, 4 kHz, 8 kHz, and 16 kHz, watching the teal response curve redraw over the grid. On EQ Presets, they may apply Vocal Clear, Warm Vocal, Karaoke, or Radio Voice as a starting point and refine it. All changes are audible immediately and playback never stops.
6. On Music, the performer starts the backing track from a local music file or an authorized playback source, rides the music fader, and balances music against vocal level. The dedicated music EQ, music compressor, output limiter, and safe stereo-width controls are available on the same channel.

7. On Vocal Delay, the performer taps the TAP TEMPO button repeatedly in time with the playing music. The application calculates BPM from the intervals between taps and displays it in real time within the 40–240 BPM range. On Tempo, the champagne-amber beat ring sweeps once per beat and the BPM reads in condensed tabular numerals, legible from across the room.
8. On Vocal Delay, the performer selects a note division — 1/1, 1/2, 1/4, 1/8, 1/16, dotted 1/8, or triplet 1/8 — and enables Tempo Sync so the delay locks to the song.
9. On Delay Controls, the performer sets feedback, wet/dry mix, and delay level, and chooses stereo ping-pong or mono mode. If they push feedback toward an unstable setting, the engine prevents runaway feedback and uncontrolled volume increase and surfaces the condition; the performer reduces feedback or level, or bypasses the delay.
10. On Reverb, the performer selects Room, Hall, Plate, Chamber, Spring, or Vocal Studio and sets Decay Time, Pre-delay, Wet/Dry Mix, Reverb Level, Room Size, Damping, High Cut and Low Cut, Stereo Width, and Early Reflections. On Reverb Presets, they may apply Male Vocal, Female Vocal, Live Singing, or Big Hall. Reverb runs simultaneously with EQ, compression, delay, and harmony without interrupting playback.
11. On Microphones, the performer engages vocal harmony for the MIC 1 channel.
12. Observable result. The processed vocal is audible in stereo with low latency, in time with the music, with reverb, delay, compression, EQ, and harmony all running together.
13. Failure and recovery. If the performer sees the clipping LED light on Meters, they reduce gain or fader level on the offending channel; the LED clears on the next peak-hold reset. If the input device is lost mid-song, the application notifies them and offers reconnect; the performer reconnects, or the Audio Engineer does, and the performance resumes.
14. Continuation. The performer continues the set, adjusting fader, EQ, delay, and reverb live as the songs change.

Flow 2 — Broadcaster / Podcast Producer: build and deliver a broadcast mix

1. Starting context. The Broadcaster opens the application for a radio broadcast, podcast, or streamed show. The engine is running with a bound input and output device.
2. On Microphones, the Broadcaster sets MIC 1 gain and trim and engages the vocal compressor so the spoken voice stays consistent.
3. On Equalizer, the Broadcaster shapes the voice, and on EQ Presets applies Podcast or Radio Voice as the broadcast curve. The change is audible immediately without stopping playback.
4. On Music, the Broadcaster loads a local music file or an authorized playback source, sets the music fader, and uses the independent music and vocal level balancing control to sit the music under the voice. The music compressor, output limiter, and safe stereo-width controls are set on the same channel.
5. On System Audio, the Broadcaster selects a WASAPI loopback or compatible virtual audio device to capture audio from Windows applications — browsers, media players, and other applications when technically available. If loopback or a compatible virtual device is not technically available on the machine, the channel states that limitation rather than presenting dead controls.
6. On System Audio, the Broadcaster sets the capture fader, checks the peak meter, and routes the captured audio to the master output or another supported bus.
7. On Mixer Routing, the Broadcaster assigns each channel's destination independently — for example, microphones to the master output and music to a separate recording or streaming destination — using the routing matrix drawn as a signal-flow diagram with right-angle traces.
8. On Reverb, the Broadcaster selects a type and, on Reverb Presets, applies Podcast Ambience, Male Vocal, or Female Vocal. Reverb runs alongside EQ, compression, delay, and harmony without interrupting playback.

9. Observable result. The voice, music, and application audio are balanced and each channel reaches its intended destination. On Meters, levels show signal without clipping.
10. Failure and recovery. If a destination becomes unavailable, the affected routing row on Mixer Routing is marked and the channel is not silently rerouted; the Broadcaster re-selects a destination or restores the device. If the captured application audio drops when the source application or device changes, the Broadcaster re-selects the capture source on System Audio and re-routes.
11. Continuation. The Broadcaster continues the show, adjusting levels and routing as segments change.

Flow 3 — Audio Engineer / Mix Operator: configure the engine and recover from a device change

1. Starting context. The Audio Engineer opens the application before a session to prepare the engine, or is called to it because a device was lost mid-session.
2. On Devices, the engineer reviews the detected inventory. Each detected interface renders as a labelled port diagram showing device name, driver type, available input/output channels, sample rate, and a status ring — teal for connected, muted steel for available, red LED for lost. Devices such as the Siborie F999 soundcard appear through their available Windows drivers. Microphone inputs, speaker outputs, and headphone outputs are identified.
3. If a device is missing, the engineer activates Refresh Device and detection re-runs.
4. On Device Select, the engineer chooses the input device and the output device independently. If a chosen device fails to open, the row reverts to the previous working selection and states the failure.
5. On Latency, the engineer sets the buffer size and reads the resulting latency alongside the current sample rate — 44.1 kHz, 48 kHz, or another rate supported by the selected device. If the device rejects the buffer size, the previous value is restored and the rejection is stated.
6. On Audio Tests, the engineer runs Test Input and Test Output to confirm signal presence on each path. If a test reports no signal, the engineer activates Reset Audio Engine and re-runs the test.
7. On Mixer Routing, the engineer configures the four channels — MIC 1, MIC 2, MUSIC, SYSTEM AUDIO — and assigns each an independent destination so microphones and music can be sent to different outputs or recording/streaming destinations.

8. On Microphones, the engineer tunes per-channel processing: gain and trim, phase inversion, high-pass filter, the optional noise gate or expander, and the vocal compressor. On Equalizer, they set per-channel curves and, if needed, the optional Q-factor or bandwidth adjustment.
9. Device change event. A device is connected or disconnected. Hot-plug detection updates the inventory and a 200ms status-ring pulse marks the change. If a bound device becomes unavailable, the application automatically notifies the engineer and offers a reconnect option.
10. Observable result. The engineer activates reconnect. The device returns to connected status and the engine resumes without crashing or corrupting.
11. Failure and recovery. If reconnect fails because the device is still physically absent, the notification persists and the reconnect option remains available; the engineer physically reconnects the device or activates Refresh Device, then reconnects. If the engine is disrupted, Reset Audio Engine restores it.
12. Continuation. The engineer confirms the routing and levels on Meters and hands the session back to the performer or broadcaster.

Flow 4 — Audio Engineer / Mix Operator: verify feedback-loop prevention and safe levels

1. Starting context. The engineer has microphones and outputs routed and wants to confirm the system cannot howl.
2. On Mixer Routing, the engineer configures a routing that would otherwise create a microphone input-to-output loop.
3. Observable result. The application prevents the audio feedback loop between microphone inputs and outputs and surfaces the condition.
4. On Meters, the engineer confirms that input and output meters track at 60fps with 300ms peak-hold decay and a 1.5s peak-hold reset, and that the clipping indicator — the only red in the system, shown exclusively as a peak-hold LED — is not lit.
5. Failure and recovery. If clipping is indicated, the engineer reduces gain or fader level on the offending channel; the LED clears on the next peak-hold reset.
6. Continuation. The engineer leaves the session running with a safe routing and confirmed headroom.

6. Visuals, Colors and Theme

Muse and headline. MARQ by Garmin — luxury instrument aesthetic. Instrument-grade precision for the ONIE82 Pro Audio Mixer. The console should feel like a precision instrument you own, not a web app in a window: technical confidence, tactile luxury, calm authority under pressure.

Color tokens (dark mode)

Typography

• Headings and numeric readouts: Saira Condensed 600–700. Uppercase, tight tracking (-0.01em), narrow enough that "MIC 1 — VOCAL COMPRESSOR" fits a 96px strip at 375px.
• Body, help text, device metadata: Barlow 400/500 at 13–15px. Body never below 13px.
• Slider value labels: Barlow Semi Condensed 500, so dB numbers align in ruled rows.
• Numerals: Tabular everywhere a number changes in real time.
• Type scale: 1.25 modular — 56 / 36 / 24 / 17 / 15 / 13.
• Display readouts (BPM, master dB, peak hold): a separate condensed numeric scale — 72 / 44 / 28 with -0.02em tracking.

Shape language

Machined, not rounded-off. Channel strips are hard-edged rectangles with 2px chamfered top corners. Fader tracks are inset grooves with a 1px inner highlight on the top edge and a 1px shadow beneath, so the cap reads as a physical part sitting in a recess. Circular elements are reserved for gauges: pan knobs, gain trim, the tap-tempo beat ring, and the device status ring. Buttons are 4px radius with a 1px top highlight and 1px bottom shadow; the pressed state inverts the highlight with no bounce. 2px hairline rules separate every ruled data row.

Spacing rhythm

Everything aligns to an 8pt baseline. Every readout sits in a right-aligned numeric column. Module rows are 32px tall.

Imagery style

No stock photography, no illustration, no gradient blobs. The imagery is the instrument itself: SVG-drawn meter scales with dB gradations, a frequency-response curve rendered live over a 10-band grid, a routing matrix drawn as a signal-flow diagram with right-angle traces, and a device panel that renders each detected interface as a labelled port diagram (ins, outs, driver type, channel count). Macro material texture is implied by surface treatment — brushed vertical noise at 2% opacity on strip backgrounds, a 1px specular line on bezels — not by images.

7. Signature Design Concept

The console, running — a photograph of a device, not a landing page.

The first screen is the console itself, already live. There is no marketing headline, no centred CTA, and no gradient. A full-bleed graphite-titanium surface (#0E1013) carries a 56px top transport rail: the ONIE82 wordmark in letterspaced Saira Condensed at the left, the live device pill in the centre ("F999 USB · WASAPI · 48 kHz · 128 smp · 5.3 ms"), and a master meter at the right that is already moving.

Below the rail, four channel strips and a master strip span the viewport edge-to-edge. Each strip is a vertical instrument column with a fixed 96px minimum width: a chamfered top, an inset fader groove with a 1px inner highlight above and a 1px shadow below, a champagne-amber fader cap (#C9A227) sitting in that recess, a circular gain knob with a machined indicator line, and a live peak meter that lives beside the fader rather than above it. The master strip at the right edge is 1.4× the width of a channel strip, with a 72px condensed dB readout in tabular numerals and a peak-hold LED that is the only red on the screen.

The composition is horizontal, dense, and symmetrical. It reads as a photograph of a device. At 375px the rail stacks to two rows at 96px and the strip bank scrolls horizontally with each strip fully reachable, while the master strip stays pinned to the right edge so it is always visible.

Selecting a strip opens the lower module bay — 10-band EQ with curve, compressor, delay, reverb, routing matrix — arranged as ruled rows of label/value pairs, never as a grid of floating cards.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: restrained Hero Dimensionality: dimensional_css

Landing Hero Motion Brief

• Focal subject. The console itself: the top transport rail with its live device pill, the four channel strips and master strip, and the master meter that is already moving.
• Input → transformation → outcome thesis. The operator's real signal enters the bound input device → the engine processes it through the channel chain and the meters track it at 60fps with 300ms peak-hold decay and a 1.5s peak-hold reset → the outcome is a console whose meters tell the truth, so the operator can trust what they see before they touch anything.
• Motion vocabulary. Precise and instrument-like, never decorative. Meters update at 60fps. Faders and knobs respond instantly with no easing on drag. The one choreographed loop is the tap-tempo beat ring: a champagne-amber arc that sweeps clockwise once per beat, so tempo is legible from across the room. Module bay transitions are a 140ms mechanical slide with no overshoot. Device connect/disconnect plays a single 200ms status-ring pulse. Nothing floats, nothing lifts, nothing bounces.
• Composed first frame. The 56px rail with the wordmark left, the live device pill centre, and the master meter right; four channel strips and the master strip spanning edge-to-edge; the master strip 1.4× wider with its 72px condensed dB readout and peak-hold LED; the master meter already in motion on the first frame.
• Reduced-motion state. With prefers-reduced-motion, the beat ring holds a static arc at the current beat position instead of sweeping, the status-ring pulse resolves to a static connected/lost state, and the module bay transition becomes an instant swap. Meters continue to update because they are the instrument's readout, not decoration. The strip bank remains horizontally scrollable so every strip can be brought fully into view.

9. Non-Functional Requirements

NFR-1 — Windows 10 and Windows 11, 64-bit only (explicit) The application targets Windows 10 and Windows 11, 64-bit. Rationale: this is the explicit platform constraint in the authoritative requirement.

NFR-2 — C++ with JUCE, or equivalent real-time DSP technology (explicit) The audio engine and interface are built with C++ and the JUCE Framework, or an equivalent technology capable of high-quality real-time digital signal processing. Rationale: explicit technology constraint; the engine must sustain real-time processing, not approximate it.

NFR-3 — WASAPI and ASIO driver support (explicit) WASAPI is supported for Windows audio devices and ASIO for compatible soundcards and audio interfaces. Rationale: explicit driver constraint; ASIO is required for low-latency operation on compatible interfaces.

NFR-4 — Sample rate support (explicit) 44.1 kHz, 48 kHz, and other sample rates supported by the selected device are supported. Rationale: explicit constraint; the engine must follow the device rather than force a fixed rate.

NFR-5 — Stereo processing with low latency (explicit) Stereo audio processing runs with low latency. Rationale: explicit constraint; a performer monitoring their own voice cannot tolerate perceptible delay.

NFR-6 — Local operation without cloud subscription (explicit) Core mixing functions work locally without requiring a cloud subscription. Rationale: explicit constraint; a live performance must not depend on connectivity or billing.

NFR-7 — Fully functional, not a mockup (explicit) The application must be fully functional, not merely a UI mockup or prototype. Rationale: explicit constraint; every control, EQ, effect, routing control, and meter must be connected to the working real-time audio engine.

NFR-8 — Engine stability across device changes (explicit) Device changes are handled without crashing or corrupting the audio engine. Rationale: explicit constraint; a mid-session unplug must not end the show.

NFR-9 — Feedback-loop prevention (explicit) Audio feedback loops between microphone inputs and outputs are prevented. Rationale: explicit constraint; a howl is a hard failure in a live setting.

NFR-10 — Runaway feedback and uncontrolled gain prevention (explicit) The delay prevents runaway feedback and uncontrolled volume increases. Rationale: explicit constraint; an unstable delay can destroy a live mix and damage monitoring.

NFR-11 — Smooth parameter transitions and minimal artifacts (explicit) EQ filters are high-quality with smooth parameter transitions and minimal audible artifacts. Rationale: explicit constraint; tuning during a performance must not introduce zipper noise or clicks.

NFR-12 — Uninterrupted simultaneous processing (explicit) Reverb operates simultaneously with EQ, compression, delay, and harmony without interrupting audio playback, and EQ changes take effect in real time without stopping playback. Rationale: explicit constraint; the full vocal chain must run live.

NFR-13 — Low-latency delay processing (explicit) The vocal delay uses low-latency real-time processing. Rationale: explicit constraint; the delay must stay in time with the performer's voice.

NFR-14 — Meter update and peak-hold timing (required_inference) Meters update at 60fps with 300ms peak-hold decay and a 1.5s peak-hold reset. Rationale: required to make the accepted real-time peak-meter and clipping-indicator behavior observable and trustworthy; the timing values come from the authoritative creative direction.

NFR-15 — Readable text and controls at every viewport (explicit) Headlines, wordmarks, labels, numbers, card text, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit, and no other element covers any part of them. Moving and scrollable content may cross the viewport or container edge by design, provided every item becomes fully readable as it passes. With prefers-reduced-motion, a usable static arrangement is provided. Rationale: explicit readability constraint.

10. Tech Stack

• Language and framework: C++ with the JUCE Framework for the audio engine and interface, or an equivalent technology capable of high-quality real-time digital signal processing. (explicit)
• Target platform: Windows 10 and Windows 11, 64-bit. (explicit)
• Audio drivers: WASAPI for Windows audio devices; ASIO for compatible soundcards and audio interfaces. (explicit)
• Sample rates: 44.1 kHz, 48 kHz, and other sample rates supported by the selected device. (explicit)
• Channel processing: Stereo audio processing with low latency. (explicit)
• Packaging: Windows executable (.exe) and installer when the build environment supports them. (explicit)
• Runtime dependency: Windows 10 or Windows 11 64-bit runtime and supported audio drivers. (required_inference)
• Device dependency: WASAPI or compatible ASIO device availability for input and output processing. (required_inference)
• Input dependency: At least one available physical input channel for MIC 1; MIC 2 depends on available physical input channels. (required_inference)
• System-audio dependency: System-audio capture depends on technically available WASAPI loopback or compatible virtual-device support. (required_inference)
• Music dependency: Music playback depends on local, supported streaming, or authorized playback sources. (required_inference)
• Typography: Saira Condensed (headings and numeric readouts), Barlow (body), Barlow Semi Condensed (slider value labels). (explicit — creative direction)
• No cloud backend: Core mixing functions run locally without a cloud subscription; no server-side service is required by any accepted requirement. (explicit)

11. Assumptions and Constraints

Constraints

1. Operating system: Windows 10 and Windows 11, 64-bit only. (explicit)
2. Technology: C++ with the JUCE Framework for the audio engine and interface, or an equivalent technology capable of high-quality real-time digital signal processing. (explicit)
3. Drivers: WASAPI for Windows audio devices and ASIO for compatible soundcards and audio interfaces. (explicit)
4. Sample rates: 44.1 kHz, 48 kHz, and other sample rates supported by the selected device. (explicit)
5. Processing: Stereo audio processing with low latency. (explicit)
6. Packaging: A Windows executable (.exe) and installer are provided when the build environment supports them. (explicit)
7. Local operation: Core mixing functions must work locally without requiring a cloud subscription. (explicit)
8. MIC 2 scope: MIC 2 processing capabilities are subject to available physical input channels. (explicit)
9. SYSTEM AUDIO scope: Capture support for browsers, media players, and other applications is limited to when technically available. (explicit)
10. MUSIC sources: The MUSIC channel accepts audio from local music files, supported streaming sources, or authorized playback sources. (explicit)
11. Delay BPM range: The delay BPM range is initially 40–240 BPM. (explicit)
12. Delay stability: The delay must prevent runaway feedback and uncontrolled volume increases. (explicit)
13. Simultaneous processing: Reverb must operate simultaneously with EQ, compression, delay, and harmony without interrupting audio playback. (explicit)

14. Functional completeness: The application must be fully functional, not merely a UI mockup or prototype. (explicit)
15. No identity gate: No accepted requirement establishes accounts, sign-in, roles, or differentiated permissions; every page in the current contract is reachable without an identity gate. (required_inference)
16. No cloud backend: No accepted requirement requires a server-side service; all accepted behavior is local to the Windows machine. (required_inference)

Assumptions

1. The operator's machine has at least one working audio device with a Windows driver installed. (required_inference)
2. The operator has the vendor driver installed for specialized interfaces such as the Siborie F999 soundcard; without it, the device does not appear. (required_inference)
3. Music playback sources are local files, supported streaming sources, or authorized playback sources that the operator is entitled to use. (explicit)
4. System-audio capture is available only where WASAPI loopback or a compatible virtual audio device is technically present. (explicit)
5. The build environment used to produce the deliverable supports Windows packaging; if it does not, the .exe and installer are not produced. (explicit)
6. The console is operated by a single local operator at a time; no multi-operator concurrency is required by any accepted requirement. (required_inference)

12. Glossary

• ASIO — Audio Stream Input/Output; a low-latency Windows audio driver standard used by compatible soundcards and audio interfaces.
• BPM — Beats per minute; the tempo value calculated from tap intervals in the vocal delay module, initially within 40–240 BPM.
• Bypass — Removing a processor (EQ, delay, or reverb) from the signal path without discarding its settings.
• Channel strip — The vertical control column for one mixer channel (MIC 1, MIC 2, MUSIC, SYSTEM AUDIO, or MASTER), containing its fader, meter, and processing access.
• Clipping indicator — The peak-hold LED that lights when signal exceeds the ceiling; the only red element in the interface.
• Damping — A reverb control that attenuates high-frequency content in the reverb tail.
• Early Reflections — The first discrete reflections in a reverb, controlled separately from the late tail.
• Feedback loop — An unstable signal path where a microphone input is routed back to an output that feeds it; prevented by the application.
• Freeze / Hold — An optional delay mode that holds the current delay content.
• Gain and trim — The input-stage level controls on a microphone channel.
• High-pass filter — A filter that attenuates low frequencies below its cutoff on a microphone channel.
• Hot-plug — Connecting or disconnecting an audio device while the application is running.
• JUCE — A C++ framework for audio applications, used for the audio engine and interface.
• Latency — The delay between input and output, determined by buffer size and sample rate.

• Loopback — A WASAPI capture mode that records the audio being played to an output device.
• Master bus — The final mix output that channels can be routed to.
• Noise gate / expander — An optional processor that attenuates signal below a threshold on a microphone channel.
• Note division — A musical timing value (1/1, 1/2, 1/4, 1/8, 1/16, dotted 1/8, triplet 1/8) used to synchronize delay time to tempo.
• Peak hold — The meter behavior that retains the highest recent level before decaying.
• Phase inversion — Reversing the polarity of a channel's signal.
• Ping-pong delay — A stereo delay mode where repeats alternate between left and right.
• Pre-delay — The time between the dry signal and the onset of reverb.
• Q-factor / bandwidth — The width of an EQ band's effect around its center frequency.
• Routing matrix — The signal-flow diagram that assigns each channel to an output or recording/streaming destination.
• Sample rate — The number of samples per second the engine processes, such as 44.1 kHz or 48 kHz.
• Solo — Isolating a channel for monitoring while other channels are muted.
• Stereo width — The perceived spread of a stereo signal; the MUSIC channel provides safe stereo-width controls.
• Tap tempo — Deriving BPM by tapping a button repeatedly in time with the music.
• Tempo Sync — Locking delay time to the detected BPM and a selected note division.
• WASAPI — Windows Audio Session API; the Windows audio driver interface used for device access and loopback capture.