Frequently Asked

What is Vox Machina?

Vox Machina is a USB audio engine for Android, built for listeners whose libraries are kept, not streamed. Its obligation is singular: deliver your signal to your DAC intact, and prove it arrived intact. There is no listening to flatter, no taste to predict, no behavior to study. There is the signal, the wire, and the witness. The Engine answers to you and to nothing else.

Why does a serious listener need a dedicated DAC at all?

A DAC — a digital-to-analog converter — is the device that turns the binary truth of an audio file into the analog voltage your headphones and speakers can sing. Every playback device has one somewhere in the chain; the question is only how good it is, and how clean the path that reaches it. A phone carries a modest internal DAC, constrained by the system audio path it sits inside, by power budget, and by physical proximity to electrical noise from the radios and the screen. For listeners whose reliquaries carry detail beyond what an internal converter can resolve, including high bit depths, native DSD, and the careful dynamic range of well-mastered recordings, a dedicated USB DAC — whether a dongle, a desktop converter, or a USB headphone, IEM, or headset with its own DAC silicon — is the difference between hearing what was recorded and hearing what the phone permits.

But my phone has a great Cirrus Logic / ESS Sabre / other DAC chip — isn't that good enough?

The silicon is worthy, but the path to it is barred. A Cirrus Logic CS43130 or an ESS Sabre 9038Q2M inside a phone is a capable converter, measurably excellent on its own terms. The problem is not the chip; it is what Android does before the signal reaches it. The system audio path runs every stream through the AudioFlinger mixer: resampled to a fixed system rate, mixed with notification chimes and other applications' audio, processed at headroom margins the listener cannot override, and constrained by power budgets that prefer battery life to dynamic range. The good chip is fed a signal that has already been bent. Even setting the audio path aside, the phone's interior is electrically hostile — radios, screen drivers, processor activity all inject noise into the analog stage that a dedicated DAC, in its own housing, does not face. A USB DAC is the only output Android exposes that the Engine can hand the unbent signal to. The chip in your phone is fine; the only path to it is not.

Doesn't Android already support bit-perfect?

Supposedly, maybe, and sometimes. AAudio's exclusive mode, introduced in Android 8.0, claims to bypass the system mixer and deliver audio without resampling. The reality is fragmented: support depends on the device, the OEM, the firmware version, the audio API the application chose, the source format, the route the system selected, and a handful of conditions the listener cannot inspect from outside. A phone may claim bit-perfect in marketing material while AudioFlinger silently rate-adjusts the signal under conditions the documentation does not list. Even when the path is genuinely bit-perfect for some condition, there is no surface that proves it to the listener at runtime. The Engine does not rely on the platform's claim. It carries its own pipeline through USB, where the path is witnessed end to end, and surfaces the verdict live in the Pipeline Card.

Why does Vox Machina need a DAC to work?

The Engine can only guarantee the integrity of a pipeline it can witness. Android's internal audio output — even AAudio exclusive mode, the modern low-latency path — is unwitnessed: the signal may be resampled, mixed with other applications' audio, or processed by the system mixer without the Engine's authority and without the listener's knowledge. The Engine refuses that path. A USB DAC is the only audio output Android exposes that the Engine can control end to end — from the decoder's last byte to the moment the sample reaches the wire — and prove its integrity along the way. Without a USB DAC, there is no pipeline the Engine can vouch for, and the Engine does not make claims it cannot keep.

So the Engine won't output through my phone's speakers or headphone jack?

Correct. The Engine refuses every audio output path it cannot witness end to end. The phone's speakers, the phone's 3.5mm headphone jack (where present), and Bluetooth all route through Android's audio surface: the system mixer, the audio policy, the platform's volume curve, none of which the Engine has authority over. The USB DAC is the only output Android exposes that the Engine can command directly, from decoder to wire, and prove the result. For music played through any of the other surfaces, any conventional Android player will do; the Engine commands the USB DAC and nothing else.

My LG G7/G8 or Sony Xperia has a famously good internal DAC. Can I route through it with the Engine?

Not through the Engine, and the reason is more than software refusal. LG's quad ESS Sabre DAC and Sony's S-Master HX are real audio engineering: purpose-built silicon paired with proprietary signal paths (LG's Hi-Fi Quad DAC Direct route; Sony's DSEE and ClearAudio layer behind a private allowlisted API) that Android's public surfaces neither expose nor let a third-party application cleanly bypass. The Forge respects the work; the architecture simply does not give an external USB engine a standing seat at that table. Beyond that, both DACs are physically wired to the phone's 3.5mm headphone jack, not to the USB host port the Engine drives; they are different output paths on different conductors. To hear those internal converters, the phone's own audio surfaces are the way, and any conventional Android player will reach them. The Engine commands the USB path, and the USB path leads to the USB DAC the listener pairs.

Can I use other apps while the Engine is playing? Will I hear system notifications?

No — and that is by design. The Engine takes exclusive command of the USB DAC during playback, which means no other application's audio — not notification chimes, not video, not system sounds, not other music — can reach the connected DAC while the Engine holds it. Those sounds still play, but they emerge from the phone's internal output rather than through the headphones or speakers attached to the DAC. You may freely use other applications while the Engine plays (scroll, message, browse) without disturbing the path; you simply will not hear those applications' audio through the DAC. A phone call pauses the Engine, as Android requires of any well-behaved audio application; the Engine resumes when the call ends. Anything else passes alongside the Engine without crossing its pipeline.

What makes Vox Machina different from other USB audio players for Android?

The Engine is built on a single principle: complete transparency between the file and the wire. Every transformation the Engine performs is named, every cost is declared, and every byte that reaches the DAC can be observed by the listener at runtime. Two surfaces make this concrete. The Pipeline Card renders the live state — which decoder rendered the source, which container delivered it, which transport carries it to the wire, the fidelity tier currently held, and the Sealed Witness verdict per chunk under Bit Perfect. Advanced Diagnostics opens the full ledger beneath: the USB descriptor parse the Engine performed on your DAC, the regime it selected and the principle by which it ranked the candidates, the alt setting negotiated, the rate accepted, the reservoir fill, the silence accounting, the integrity hashes: every field the Engine knows, exposed for inspection or export. Other players ask for trust. The Engine builds the proof and shows it to you. That commitment, not a feature list, is the distinction.

Why “the Engine,” “the Forge,” “rites”? Is this a joke?

It is not a joke, and it is not costume. The ceremonial register is a considered choice: the language that builds around a piece of software shapes how that software is thought about, built, and held accountable. “The Engine” is not the app icon. It is the obligation: the thing that must perform the rite correctly, must not let a byte slip, must name every transformation. “The Forge” is the entity that built it and stands behind it. When a rite is sealed, it means the work is committed and must not regress. The vocabulary is load-bearing; it insists on a seriousness of purpose that utility-language cannot quite enforce.

Which doctrine should I use?

The listeners are divided. Those who require absolute purity hold to Bit Perfect dearly: integer PCM unaltered from the decoder to the wire, no float conversion, no DSP, no headroom adjustment, the Sealed Witness becoming their daily companion as it names the verdict per chunk. DSD sources route natively where the DAC supports it. Others who strive for truly lossless audio with the flexibility of DSP plant their banners on Source Matching: the Engine selects the DAC alt that matches the source format exactly, a 16-bit / 44.1 kHz source onto a 16-bit / 44.1 kHz subslot, with clean fallbacks where no native match exists and every chamber of DSP available if the listener calls upon them. Wide is the most permissive of the three: every track plays, every transition seamless, every transformation declared. Most listeners begin with Source Matching, and choose their banner from there.

Wide vs Source Matching vs Bit Perfect — what's the practical difference?

The three fidelity policies govern what the Engine does between your file and your DAC; they differ in what they prioritize and what they refuse. Wide surveys every alt setting the DAC exposes and chooses the widest available: highest bit depth first, then most bandwidth-efficient subslot. Take a 16-bit / 44.1 kHz FLAC played to a DAC such as the JadeAudio JA11, which exposes 16-, 24-, and 32-bit alt settings across rates from 44.1 to 384 kHz. Wide selects the 32-bit alt at the source rate of 44.1 kHz, zero-pads the 16-bit sample MSB-justified into the 32-bit container, and sends the result intact. Sample value is preserved; the transport is simply wider than it strictly needs to be. If the chosen alt cannot accept the source rate, the Iron Furnace resampler engages and the transformation is declared. Source Matching chooses the alt that matches the source format exactly: the same 16/44.1 FLAC routes through the 16-bit / 44.1 kHz alt setting, same bit depth, same sample rate, no padding, no resampling. Where the DAC exposes no exact match, the Engine falls back to the nearest workable option and declares the divergence. Bit Perfect refuses any transformation: integer PCM goes to the wire as it left the decoder, with no float conversion, no DSP, no headroom adjustment, no resampling. It selects the same 16-bit / 44.1 kHz alt as Source Matching, but adds a refusal — if no native match exists, Bit Perfect declines to play the track rather than alter it. For DSD sources, the Engine routes natively where the DAC supports it. The Sealed Witness stands only under this policy.

Can I use the equalizer or convolver under Bit Perfect?

No, and the reason runs deeper than policy. Applying an equalizer, convolver, crossfeed, or any DSP rite requires arithmetic against samples that Bit Perfect does not permit. The bare integer PCM the policy insists upon cannot be filtered without first being widened to floating point — filter kernels require multi-bit precision that integers in their raw form cannot represent. DSD is worse still: a one-bit stream encoded as oversampled noise-shaped pulses, on which no sample-domain filter has a coherent meaning at all. The Engine could pretend otherwise — convert quietly in the background, name the path Bit Perfect anyway — but to do so would turn the Engine into an oathbreaker. The Engine does not lie. Under Wide or Source Matching the full chain of chambers is available, and the Engine declares every transformation along the way.

My MP3, AAC, or other lossy files won't play under Bit Perfect. Why?

Lossy codecs have already been transformed: at the moment of encode, the source waveform was perceptually modeled, discarded in part, and reconstructed approximately. To declare the perfect rendition of an already-imperfect source is an empty ritual; there is no original to be perfect against. Bit Perfect refuses the ritual. The policy is defined by the absence of transformation inside the Engine's pipeline, not by the absence of transformation anywhere upstream; once a source has been lossily encoded, the Engine has nothing left to preserve perfectly. Lossy formats (MP3, AAC, OGG, Opus) play freely under Wide and Source Matching, where the Engine's chambers can do meaningful work and the result is fairly named.

How does DSD interact with the fidelity policies?

Across all three policies, DSD is rendered natively whenever the connected DAC declares native DSD support — the Engine carries the one-bit stream untouched through its DSD pipeline directly to the wire. If native DSD is unavailable, the Engine falls back to DoP (DSD over PCM), where the DSD bits are encapsulated in PCM transport, used only when the DAC accepts it. If neither path is open, the Engine decimates the DSD to PCM at an appropriate rate. One exception applies across every policy: if digital volume control or any DSP chamber is engaged, DSD must be decimated to PCM first; sample-domain operations cannot be performed on one-bit transport without first crossing into PCM. The decimation is named in the Pipeline Card and recorded in Advanced Diagnostics; nothing is silent.

Does the Engine consider DoP Bit Perfect?

No. The Engine's doctrine of Bit Perfect — codified in the Codex Machina at Entry XVIII, On Losslessness — holds that every byte submitted to USB must equal the byte the decoder produced, save for a narrow set of truly lossless, deterministic transforms, and that bytes carrying information the source did not contain fail the doctrine regardless of whether the audible signal survives. DoP fails on the marker. The mechanism packs two bytes of the one-bit DSD stream into the lower 16 bits of each 24-bit PCM sample and stamps a marker byte (alternating 0x05/0xFA) into the upper 8 bits to signal to the DAC that the frame carries DSD, not audio PCM. That marker byte was invented at the encapsulation step; the source did not contain it. The audible signal is preserved — the DSD bytes inside the container survive bit-for-bit — but the wire-level byte stream is no longer the byte stream the decoder produced. Under Bit Perfect, only native DSD transport qualifies: the DAC declares DSD as a first-class alt setting and the Engine writes the one-bit stream directly to the wire, with at most the lawful bit-reversal and channel-transpose Entry XVIII permits. Under Source Matching, DoP is admissible where the DAC declares it, and the transformation is declared as it occurs.

My DAC's marketing says it supports DSD128 (or 256, or 512). Why won't it play DSD under Bit Perfect?

Marketing copy is not the ground truth; the USB descriptor is. Many DACs advertise DSD support in headline material while implementing it only through DoP (DSD over PCM transport), or carrying native DSD only on Windows drivers that have no Android equivalent. The JadeAudio JA11 is a useful case. Its public listing says “supports decoding of PCM384kHz/32bit and DSD128,” yet the device descriptor visible in the Engine's Advanced Diagnostics declares only PCM alt settings at 16-, 24-, and 32-bit; no native DSD alt is present at all.

A separate spec sheet, buried, names the actual mechanism: “DSD: DOP 128.” Under Bit Perfect, the Engine refuses to translate DSD into DoP and refuses to claim a path it cannot prove; the track will not play. Under Source Matching, the same DAC will accept DSD content along whichever transport its descriptor actually supports — DoP where the descriptor declares it (the JA11's case at DoP128), or PCM decimation where neither native DSD nor DoP is available — with the transformation declared.

The inverse case is just as instructive. The JCALLY JM98MAX is ostensibly a DSD256 device by its marketing; in practice, a listener brought one to the Forge and the Engine drove it natively at DSD512, descriptor and all. Bit Perfect, native DSD, Sealed Witness reconciled.

On many such DACs the USB receiver and the analog conversion stage are separate silicon. The receiver transmits whatever rate the descriptor declares; what the analog stage chooses to do with it past the wire — accept it raw, internally decimate to its rated ceiling, oversample, or simply tolerate it — is a confession the chip makes only to itself. Whether that headroom is a firmware oversight, an undeclared alt setting, or simply unwritten generosity, the descriptor says what it says and the Engine listens to it. The Machine has its mysteries; the descriptor is how it tells the truth about them.

What does the Sealed Witness verify, and what do the verdicts mean?

The Sealed Witness computes a CRC32 hash at two points in the pipeline: the moment a chunk leaves the decoder, and the moment that same chunk reaches USB submission. The two hashes are compared in real time, per chunk, every block of audio. Four verdicts are possible. VERIFIED means the signal crossed the Engine untouched. ALTERED is an expected divergence, typically the result of digital volume control engaged by the listener. MISMATCH is a fault, meaning the signal was changed by something the Engine did not intend. UNVERIFIABLE means the pipeline is operating under conditions where verification cannot be performed. The Witness only stands under Bit Perfect; under the other doctrines, which admit transformation, it withholds judgment.

Is resampling harmful, and can I hear it?

Resampling is not bad; imprecise resampling is bad, and the Engine does not employ it. The Iron Furnace — the Engine's 8,192-tap polyphase windowed-sinc converter, built from first principles in native C++ with ARM NEON double-precision accumulation — places its stopband well below the noise floor of any real equipment. The result is perceptually transparent. The Codex Machina classifies the Iron Furnace as Lossless Processing, not Bit Perfect, because the mathematics discard bandwidth above the new Nyquist by necessity; that is the correct accounting, not a confession of harm. If you hold to Bit Perfect, the Engine refuses to resample at all and declines the track when no native rate match exists. If you hold to Source Matching or Wide, the Iron Furnace takes the path, and the transformation is declared.

Which resampler filter should I choose?

Four filter modes are available, each reflecting a different philosophy of the trade-off between phase behavior and passband shape. Mathematical uses a linear-phase Blackman-Harris window, which distributes any ringing symmetrically before and after a transient; it is the most neutral and the right default. Minimum Phase concentrates all ringing to the causal side, eliminating pre-echo, which benefits percussive material and listeners who find linear-phase pre-ringing audible. Apodizing relaxes the passband slightly for a gentler high-frequency rolloff; it trades a small amount of treble extension for a softer cutoff character. Brickwall applies a Kaiser window at β=14, achieving stopband rejection of approximately 136 dB at the cost of the most aggressive cutoff slope. For most reliquaries and most listeners, Mathematical is the correct starting point; Minimum Phase is the informed second choice for heavily percussive or live material.

Does my USB DAC work with Vox Machina?

With high confidence, yes. Listeners have already brought the Engine to DACs and amplifiers of every shape: pocket dongles, USB-C adapters, USB headphones / IEMs / headsets with integrated DAC silicon, portable amps, full desktop converters, integrated DAC-amp combinations from the field's full range of manufacturers. So long as the device recognizes a USB input and declares itself as USB Audio Class 1 or 2 — which the overwhelming majority of USB-capable DACs do — the Engine communes with it. The Engine performs its own full descriptor parse on the connected device, reading what your DAC actually accepts rather than what Android guesses it accepts. Advanced Diagnostics inside the Engine shows the negotiated path for any DAC you connect; for certainty on a specific device before purchase, the forge channel at forge@voxmachina.audio carries a quiet log of confirmed hardware.

+ See the full Concordance +

Does the Engine work with USB headphones, IEMs, or headsets that have a built-in DAC?

It does, and the Engine commands them no differently than any dongle. Any USB-connected headphone, IEM, earbud, or headset with integrated DAC silicon — Type-C, Type-A through an OTG adapter, or any other USB connector — is, from the host's perspective, a USB DAC. It enumerates as USB Audio Class, publishes its descriptor at handshake, and declares its sample rates, bit depths, and formats just as a separately-housed converter does. The silicon happens to sit at the end of the cable, inside the earpiece, or in the headset's controller boom rather than in a discrete brick; the protocol is identical. Apple's USB-C EarPods, chi-fi IEMs (Moondrop, Tin HiFi, 7Hz, Truthear), USB streaming and monitoring headphones (Audio-Technica's ATH-M50x-STS), USB gaming headsets (HyperX Cloud, Razer, Corsair, Logitech G-series, SteelSeries Arctis USB variants) — the Engine sees all of them as standard USB Audio devices, and the same Bit Perfect contract applies. The Witnessed Devices list above and the Concordance at /dossiers/ cover all shapes.

What's UAC1 vs UAC2, and which does my DAC need?

USB Audio Class is the protocol by which a DAC announces its capabilities to the host. UAC1 is the older standard, universally supported but limited to 24/96 as its practical ceiling; it does not carry DSD natively. UAC2 is the modern standard, supporting higher sample rates and DSD transport. Your DAC implements one of these; it does not choose. The Engine supports both. If you have a UAC1 device and your reliquary peaks at 24/96, nothing is lost. If your material runs higher or carries DSD, you need a UAC2-capable DAC.

Does it work with USB hubs, dongles, digital audio players?

The Engine identifies DACs concealed behind powered USB hubs: the hardware handshake is read through the hub, and the device is found. Simple passive hubs and OTG dongles work in the common case; if an unpowered multi-device hub proves unstable, a powered hub is the remedy. DAPs that expose a UAC-class USB output also function. If the device presents as USB Audio Class to Android, the Engine will negotiate with it.

Will the Engine work with my DAP's internal DAC?

Not the internal DAC. Some DAPs ship modded Android builds that claim a sanctified path to the internal converter; others do not. What is uniform across them is that the internal pipeline is opaque to the Engine: it relies either on Android's standard AudioFlinger surface or on a closed manufacturer SDK to which the Forge has no access. The Engine refuses to make claims about a path it cannot witness end to end. Even if the Forge were granted access to a particular DAP's internal pipeline, the doctrinal path would still require building a sanctified route per manufacturer and per firmware revision, with the same descriptor scrutiny and integrity verification the USB path receives. That is not feasible work for a one-person Forge to commit to. The DAP's USB output (where it exposes one) remains the supported path; through that surface the Engine commands whatever USB DAC the listener pairs.

What's the maximum DSD rate supported, and what determines it?

The Engine's pipeline handles DSD up to DSD2048 in code. In field use, DSD512 is the highest rate that has been verified across known hardware. What determines your ceiling is not the Engine but the combination of your DAC's declared DSD capabilities (read from its USB descriptor) and your Android device's USB subsystem throughput. The Engine reads what your DAC announces and routes accordingly; it does not oversell the path. The Advanced Diagnostics surface shows the exact rate envelope the Engine negotiated with your connected hardware.

Does it work with Topping / Schiit / FiiO / Hiby / Snowsky / etc?

If the manufacturer has implemented USB Audio Class correctly (UAC1 or UAC2), the Engine will find the device and negotiate with it. Brand is not the variable; protocol conformance is. The Forge cannot exhaustively certify every device that exists, but the Engine's descriptor parsing is bespoke and reads what the hardware actually exposes rather than relying on Android's interpretation. If your DAC does not work, the forge channel at forge@voxmachina.audio is where to bring the report — the Engine's hardware support has been extended many times through exactly that path.

What audio formats are supported?

The Engine speaks natively across a broad range of formats: FLAC, WAV, AIFF, ALAC, MP3, AAC, OGG, Opus, APE, WavPack (including DSD-in-WavPack, routed directly through the DSD pipeline), DSF, and DFF (including DFF containers bearing DST-compressed streams, decoded natively from first principles). CUE sidecars are read for folder-level rips, recovering artist, title, album, and date where no embedded tag exists. The Engine also recovers folder-level album artwork. If a format is not listed here, it is not currently supported.

Will it play my CUE-based rip collection?

Yes, with a clear picture of where the Engine currently stands. The Engine reads CUE sidecars placed alongside their audio files and recovers identity metadata (artist, title, album, date) from them, surfacing physical rips correctly in the library where embedded tags are absent. Folder-level artwork is likewise recovered. Virtual track decomposition from single-file rips (the slicing of one large file into its individual tracks by CUE offset) is its own separate crusade, presently under deliberation rather than scheduled. If your collection consists of single-file-plus-CUE rips, the tracks appear as the underlying file in the current release; the offset-based decomposition is not yet on the calendar.

What about MQA? SACD ISO?

MQA is not decoded. MQA files are typically FLAC containers carrying an encoded watermark; the Engine plays the underlying PCM data normally, but the MQA watermark is not unfolded — what you hear is the base PCM layer. SACD ISO is not in the Engine's scope. An SACD ISO is a disc image, not a codec; it is a container that carries audio files. The Engine is an audio engine, not a file manager, and disc-image extraction is not work the Forge has chosen to take on. Decompress the ISO into its constituent DSF or DFF tracks with the tool of your preference, and the Engine will play those natively, including DFF containers bearing DST compression.

My library consists of tens of thousands of files. Can the Engine handle that?

Yes, comfortably so. Listeners routinely feed the Engine reliquaries in the tens of thousands; collections of fifty thousand tracks and beyond are common and well within the Engine's stride. The architecture is what makes this possible. Most audio players reach for a single general-purpose tag-reading library (TagLib is the de facto choice across the field), which serves every format through one generic surface. It works at small scale; at the listener's scale, the surface itself becomes the bottleneck. The Engine takes the opposite path. Ten bespoke per-format Witnesses read the native tag structures of their assigned format in the Engine's own hand, dispatching the work format-by-format with no shared bottleneck. In the field, the architectural distinction is the difference between a five-minute scan and a two-hour scan on the same reliquary. The first scan does the heavy work; everything thereafter is incremental and effectively free.

Why is the first library scan slower than subsequent ones?

The Engine builds its library by walking the directories the listener has granted it through the Scoped Access Framework, Android's covenant-bound traversal. On the first scan, every file is opened and its identity read directly from the file's native tag structures. Subsequent scans are incremental: the Engine checks what has changed and pays only for what is new. A stable reliquary at second scan costs almost nothing; first-scan depth is the price of directness.

If I connect a thumb drive, SSD, or HDD through a USB hub, will the Engine scan it?

Yes. The Engine reads the reliquary from whatever directories the listener has granted it through the Scoped Access Framework: if Android mounts your external storage as a volume, you grant the Engine access to the relevant folders the same way you would any internal directory. A powered USB hub lets you keep the DAC and the storage device connected at the same time, with the Engine commanding the DAC over the same connection through which it reads the files. The Engine walks the granted volume on first scan and inscribes it into the local library; from there it is treated as any other granted root.

Why doesn't a specific file show up in my library?

The most common cause is that the file's folder has not been granted to the Engine through the Scoped Access Framework. The Engine walks only those directories the listener has permitted; if the folder was not included when access was granted, the file is invisible by design. Check Settings, find the library root management surface, and confirm the relevant folder is in the granted covenant. If the folder is already granted, the file's format may be outside the Engine's current supported set, or the container may be malformed in a way the Engine cannot resolve.

Does Vox Machina collect data about me or my music?

It does not. There are no accounts, no telemetry, no analytics, no advertisements, no third-party SDKs. The Engine runs on the listener's device and reports to nothing beyond it. The reliquary, the listening record, the DAC interactions: all remain where they were made. The Engine does maintain a local listening record for the sake of the Auguries — the surfaces it composes from your own patterns of return — but that record is the listener's alone and does not depart the device under any circumstance the Engine controls.

Does it phone home?

The Engine does not reach the network under ordinary operation. There are no telemetry calls, no analytics pings, no crash reporting services, no third-party SDKs in the chain. The sole circumstance in which the Engine touches the network is the Outward Cadence — optional Last.fm and ListenBrainz scrobbling — and only when the listener has enabled it by their own hand with their own credentials. The Internet permission exists for that path and for outbound links the listener explicitly taps in the UI. Nothing else crosses the wire.

What is the Outward Cadence?

The Outward Cadence is the Engine's name for its optional scrobbling feature — the dispatch of your listening record to Last.fm or ListenBrainz, two open listening-history services. It is configured under Settings → Scrobbling with credentials the listener provides. It is silent by default and must be activated by the listener's hand. Once active, it dispatches a record of each played track to the configured service. It may be revoked at any moment from the same surface; once revoked, no further dispatch occurs. No other outward channel exists in the Engine.

Is there a subscription, trial, or free version?

The Engine is paid once on the Google Play Store. There is no subscription, no in-app purchase, no further toll of any kind. There is no trial or free edition in the current release. The commerce model is uncomplicated by design: you pay once, and the Engine is yours. The Play Store listing carries the current price; no other transaction is ever asked.

Why does the Engine cost what it costs?

The Forge has chosen the simplest commercial shape available — a single payment in exchange for the work done — and refuses the shapes that extract ongoing revenue from listeners. No subscription. No telemetry routed elsewhere to fund development. No advertising surface. No upsell sequence. The Engine is paid once and yours.

The number itself is a working number. It sits a little below the incumbents in the space, enough to be taken seriously without claiming a premium it has not yet earned. What it actually reflects is months of nights and days spent litigating minutiae that will never surface in any form a listener can name — three weeks chasing a phantom half-second audio lag on track skip that turned out, after three full audits of the playback engine, to live in the tail of a UI animation; a stretch in which every DSD file on a listener's device was being silently decoded as 705-kilohertz PCM because a filename check three layers down had been handed the song title instead of the filename, breaking DSD-over-PCM transport and the equalizer and track transitions all at once under a symptom that looked like ten different things; three iterations of a new format-detection routine drafted from scratch before discovering the field it was meant to recover had been available in the engine since an earlier revision, unread — so that what does surface is a player without friction at any surface the listener touches, contrary to what audiophiles have been conditioned to expect from this category.

The number is what the work costs.

What Android permissions does it ask for, and why?

The Engine requests four categories of permission. Storage and media access, to read the reliquary: the directories the listener grants through the Scoped Access Framework. USB device access, to commune directly with the connected DAC. Foreground service permission, to keep the rite of playback active when the screen sleeps. Internet permission, employed only for the Outward Cadence if the listener enables it, and for outbound links to the Forge and its channels tapped explicitly in the UI. No permission exists to observe the listener, contact external services, or write to the reliquary. The Engine reads; it does not write.

Where can I join the community?

The Forge maintains two gathering places. The Discord server is the most active: the place for real-time conversation, hardware reports, and the kinds of questions that benefit from discussion rather than a single answer. The Facebook community carries the same conversation at a different cadence, and the Facebook page carries announcements. Links to all channels are available from within the Engine under Settings → About, and from the Dispatches page at voxmachina.audio.

I found a bug — where do I report it?

Address the Forge directly: forge@voxmachina.audio. Include the device model, Android version, and a description of what the Engine did against what you expected it to do. If the issue is playback-related, the Advanced Diagnostics export from within the Engine is the most useful artifact you can attach; it speaks every field aloud, null values included, so nothing is ambiguous in the report. The Discord server is also a valid path for bugs; the Forge is present there and acts on reports that originate there.

I have a feature request — where do I send it?

The same channel: forge@voxmachina.audio, or the Discord server. The Forge reads every message that arrives there. Not every request becomes a rite (the Engine's scope is deliberate and bounded), but requests that recur across multiple listeners, or that fall cleanly within the Engine's existing doctrine, are real inputs into what the Forge contemplates for the next cycle. The Dispatches page carries the Forge's own accounting of what is in active contemplation, so a check there first may save a message that has already been heard.

I have a DAC that doesn't work — what should I do?

Bring the report to forge@voxmachina.audio with the DAC make and model, Android device and version, and the Advanced Diagnostics export from the Engine. The export carries the full descriptor parse the Engine performed on your hardware: what it found, what it negotiated, and where the path failed. The Engine's hardware support has been extended repeatedly through field reports of exactly this kind; UAC1 support, hub-concealed device identification, and per-OEM probe hardening all arrived through listener reports. The Forge cannot act without the evidence the Advanced Diagnostics export carries.

Is the source code available?

The Engine itself is closed source. The Forge acknowledges its dependencies openly: FFmpeg, libFLAC, AndroidX, and the Kotlin standard library are all recognized at voxmachina.audio/legal, with their respective license terms. The decision to keep the Engine closed is the Forge's alone and is not a claim on the libraries it carries; those acknowledgments are kept current. If you have a question about a specific dependency or its license terms, the legal page is the place to begin, and forge@voxmachina.audio is the address for anything it does not answer.

Why did you build the Engine in the first place?

Because the existing options would not do. Audio players on Android were content to claim bit-perfect without proving it, to handle the listener's reliquary at MediaStore's depth rather than the file's, to treat the system mixer's interposition as acceptable. The Forge wanted a USB audio engine that proved its claims at runtime, walked the files directly, refused the system path, and named every transformation it allowed itself. No such Engine existed, so the Forge built one — first for itself, then for the listeners who would recognize the same gap and the same answer. The vocabulary is ceremonial because the work is serious. The surfaces are restrained because the music does not need flattery. The Forge tends one Engine, and the Engine carries one signal. That is enough.