Music Hardware Boundary

In plain words: Riffmaw: audio hardware routes

Designed 2 min read 1 glossary terms 3 connected pages
The short version written for the Snayu team

How Riffmaw admits an exact audio input route (interface, channel, clock, latency, monitoring) for a take, keeping the dry instrument signal separate from the processed sound you hear.

Why read it: Read when dealing with Linux audio devices, PipeWire routes or instrument and vocal capture.
  1. 1Opening a DAW or plugging in an instrument does not arm recording; explicit arming does.
  2. 2Speech on the same interface goes to Voice or Language Edition, not Riffmaw.
  3. 3No device gets a compatibility presumption; each route must pass its own test.

Words on this page, decoded click one for its card

The original text Underlined words open their plain-English card.

The guitar's dry signal and the amp sound heard in the headphones are related, but they are not the same recording. Riffmaw admits the musical reason to arm an exact route and preserves those separate sources for later production.

Audio Hardware and Host Routes owns replaceable Linux/device candidates and setup evidence. Audio owns capture, custody, transport, interruption, and uncertain playback. ALSA, PipeWire, interfaces, drivers, and workstation hardware do not become Riffmaw records.

Admit a musical route

riffmaw.capture_take@2 begins after visible operator arming. Pin device/channel, driver/graph revisions, sample format/rate, clock epoch, latency/monitor path, dry/processed split, performer authority, retention, stop/cancel behavior, and byte/duration ceilings. Opening a DAW, attaching an instrument, or pairing a transmitter does not supply that admission.

Channels sharing an interface can retain different owners. Speech intended for dialogue/transcription enters EchoVoice and, for timed editions, Language Edition. Instrumental, sung, rapped, or musical-spoken-word material may enter Riffmaw. Simultaneous PCM capture merges none of their consent, custody, session, or acceptance.

Instrument and vocal tracking

Build the admitted profile from exact device instructions and host measurements. For each microphone/instrument channel, identify its electrical input mode, power requirements, gain/clip behavior, and monitoring route. Connector shape and vendor claims cannot prove Linux compatibility.

Explicitly map direct monitoring and any processed Guitarix or other effect path so dry/processed doubles are intentional. Retain dry DI separately from the amp/cabinet print; the monitored sound must not obscure which signal was recorded.

Bluetooth/TWS, passive-instrument inputs, and anonymous microphone kits receive no special compatibility presumption. Every route must pass the exact format, latency, stability, reconnect, and failure bake. Device settings belong to the qualified host route rather than universal instructions inferred from a musical role.

Records and proof

PerformanceTake@1 retains immutable audio/MIDI with device, clock, channel, consent, discontinuities, and transforms. Several routes/takes may later join MusicalPerformanceSession@1; a single take cannot silently become a jam.

The hardware proof records dry guitar/bass and musical vocals through a real desktop PipeWire session with networking disabled. Exercise channel swap, clipping, xrun, removal, clock change, processed-monitor failure, cancellation, crash reconciliation, and deterministic export. The receipt proves only that exact musical host route, not generic speech, timed editions, live Jam, cloning, or other hardware.