Questions the Forge has been asked, answered in full.
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; the path to it is the whole question. A Cirrus Logic CS43130 or an ESS Sabre 9038Q2M inside a phone is a capable converter, measurably excellent on its own terms — but there is no true, direct path to it. A USB DAC the Engine communes with directly: it reads the descriptor the hardware itself publishes and learns exactly what the device will accept. An internal DAC is never reached so plainly. It sits behind a Hardware Abstraction Layer — the HAL, the OEM's driver stratum that mediates every conversation with the silicon — and the HAL is a warden. Even where the converter can run 384 kHz at 32-bit, the warden may declare far less — 48 kHz and no further — and that declaration binds every path that runs through Android, the Engine's wayward roads among them. The chip's true ceiling is the warden's to disclose or to censor, and censor it often does.
Past what the warden hides, there is what Android does to the signal in flight. 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. And even setting path and warden 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.
On the wired internal output the Engine can now contest the mixer through the Penitent path: it petitions Android for an exclusive, unmixed delivery — never for more than the warden will declare — and states plainly whether the petition was honored, bent to fit, or refused. Where the door opens, the bits can reach that internal chip intact. But the petition is the platform's to grant or withhold, never the Engine's to command — and while the Penitent path declares its outcome, it cannot seal it; the end-to-end witness that proves the USB path has no place to stand there. A USB DAC remains the only output the Engine can hand the unbent signal to with indisputable reliability and full auditability: unbent every time, and provably so. The chip in your phone is fine; the path to it is no longer barred, only conditional — and the noise around it is the part no path can fix.
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 the HAL — the same warden that guards the internal output — quietly declares a reduced format and AudioFlinger rate-adjusts the signal under conditions the documentation does not list. And even when the path is genuinely bit-perfect for some condition, there is no surface that proves it to the listener at runtime. The platform makes the claim and never shows its work.
The Engine now travels that exclusive path itself — it is the Penitent path — but it refuses to inherit the platform's silent claim. Where Android stays quiet, the Penitent path speaks: it states plainly whether the exclusive delivery was honored, bent to fit, or refused, and names the moment of any divergence. That is the surface the platform never built — and yet it is still a surface of words. The Penitent path discloses what it did, honestly, then asks you to trust the telling; it cannot place the evidence in your hand, for no witness can stand on that path. The witnessed USB path asks for no such trust. The Sealed Witness takes the signal's hash as it leaves the decoder and again as it reaches the wire, reconciles the two, and surfaces the verdict live in the Pipeline Card — proof you can read at runtime and export at will, not a word you must believe. Android claims bit-perfect and hides its work; the Penitent path discloses its work and asks for trust; the wire brings forth proof and asks for nothing.
If the Engine can play through my phone now, why use a USB DAC at all?
Because playing and proving are not the same thing, and the Engine was built for the second. It can now make sound without a DAC: the Heretical path hands the signal to the phone's own outputs — speakers, headphone jack, even Bluetooth — through the system mixer, where it may be resampled or mixed with other audio without the Engine's authority. The Penitent path does better on the wired outputs, petitioning Android for an unmixed, exclusive delivery — but the petition is the warden's to grant or refuse, and even when granted, no witness can stand on that path to prove the bits held. The Penitent declares what became of the signal; the Heretical makes no such claim at all. They are second class by nature, not by neglect: there is no witness to be had on a path the Engine does not command end to end.
A USB DAC is the only audio output Android exposes that the Engine controls from the decoder's last byte to the moment the sample reaches the wire — and proves its integrity along the way, per chunk, in the Pipeline Card. It is the one path where the Engine's central promise is kept rather than merely asserted. Without a USB DAC the Engine will still play, and play honestly, telling you exactly what it could and could not guarantee. With one, it does not have to tell you — it shows you. The Engine does not make claims it cannot keep; the wire is where it can keep them.
So the Engine won't output through my phone's speakers or headphone jack?
It does now — by two roads, both newer than the wire and both plainly lesser than it. The Heretical path hands the signal to the phone's own audio surface: the speakers, the 3.5mm headphone jack where one is present, and Bluetooth. It plays through the system mixer and the platform's volume curve like any ordinary application, and claims no fidelity it cannot stand behind — the signal may be resampled or mixed, and the Engine says so rather than hiding it. The Penitent path is the more careful of the two: on the wired outputs it petitions Android for an exclusive, unmixed delivery and tells you plainly whether the petition was honored, bent to fit, or refused. It will not knock at the wireless door — Bluetooth cannot keep the bits no matter who is asked, and the Penitent path refuses to pretend otherwise.
Neither road is witnessed. The Penitent path discloses what it did and asks you to trust the telling; the Heretical path does not claim even that. Both are chosen in the app, under Settings, where the Engine sets out in full what each path can and cannot keep. If these surfaces are your habit, any conventional Android player serves them as well; the Engine offers them only so that, when the wire is absent, what plays is still honest about itself.
The USB DAC remains the only output the Engine commands from decoder to wire and proves along the way — the witnessed home of everything the Engine was built to promise. The wayward paths exist for the listener who, in some moment, has no DAC at hand and wants the music anyway; they are offered without apology and without disguise. The wire is the vocation; these are the concession.
My LG G7/G8 or Sony Xperia has a famously good internal DAC. Can I route through it with the Engine?
More fully than you might expect, and the principle is the same on every such phone. These celebrated converters — LG's Hi-Fi Quad DAC, Sony's S-Master HX, and their kin — are not gated behind a private interface reserved to the maker's own player. They belong to the system: the converter sits behind the phone's wired output and engages by the phone's own settings for whatever audio reaches it. Through the wayward paths the Engine now reaches that output, which on these handsets is the 3.5mm jack the famous silicon sits behind. So the Engine hands its signal to the system path, and the celebrated DAC renders the signal exactly as it would for any application. You hear it. The famous silicon was never closed to the Engine after all — only the USB-only path could not turn toward it.
But hearing it and commanding it are different things, and here the wayward paths stay wayward. The Engine hands off the audio, and from there the phone does as it will — its filters, its presets, its volume curve, whatever the warden permits through — under the phone's authority and the phone's settings, never the Engine's, and wholly outside the Engine's witness. The Engine can neither shape what happens past the handoff nor prove what came of it. So yes, you can route to your famous internal DAC through the Engine now, and it will sound as it always has — but it remains the phone's rite, governed by the phone's toggles, bearing no witness mark. For the Engine's full authority over the signal, and for the proof, the USB DAC is still the only road.
Can I use other apps while the Engine is playing? Will I hear system notifications?
It depends on the road. On the witnessed USB path, the answer is the original one, by design: the Engine takes exclusive command of the USB DAC, so no other application's audio — not notification chimes, not video, not system sounds, not other music — can reach it while the Engine holds it. Those sounds still play, but they emerge from the phone's own output rather than through the headphones or speakers attached to your DAC. The DAC is a separate destination, and the Engine alone speaks to it.
On the wayward paths the Engine is no longer on a separate destination — it is on the phone's own output, the same surface the rest of the system uses, and the isolation changes accordingly. The Heretical path plays through the system mixer like any ordinary application, so notification chimes and other audio may mix into what you hear; that is simply what the shared surface does, and the Engine makes no pretense of holding them apart. The Penitent path petitions an exclusive hold and keeps the path the cleaner of the two where Android grants it, but it still lives on the output the phone shares. If an uninterrupted field is what you seek, the USB DAC is the road that gives it without condition.
Two things hold on every road. You may freely use other applications while the Engine plays — scroll, message, browse — without disturbing the music; their use was never what crossed the path, only their audio. A phone call pauses the Engine, as Android requires of any well-behaved audio application, and it resumes when the call ends. All else passes alongside the Engine, never through it.
During navigation, my map app's spoken directions go silent while the Engine plays over USB. Why — and can I fix it?
This is a matter of how Android routes audio, not a fault in the Engine or in your map application. On the witnessed USB path the Engine takes direct command of the DAC through its own transport — yet the connected DAC also stays registered with Android's ordinary audio routing, which favors a USB audio device over the phone's speaker for system sounds. So when a navigation app such as Waze or Google Maps speaks a direction, Android dutifully sends that prompt toward the USB device — the very device the Engine holds exclusively. The prompt has nowhere to land: Android's audio system counts it as played, and nothing emerges. It is a silent gap, a phantom destination, and while the Engine holds the wire it can swallow spoken directions, notification chimes, and other system audio Android routes that way. On many phones such sounds simply come from the phone's own speaker instead; but Android's routing is not uniform, and where it prefers the connected USB device, spoken navigation is the sound most often lost.
The remedy lives in Android's own settings. Open Developer Options, find “Disable USB audio routing,” and turn it on. This instructs Android to stop routing system audio to USB audio devices — spoken directions and notifications fall back to the phone's speaker or your Bluetooth car link, which is where you want them while driving. The Engine's own playback is untouched: it commands the DAC through its private transport, outside the routing this toggle governs, so the music continues to the wire exactly as before. Nothing in the audio path changes; only Android's handling of everything else does.
One caution. This remedy belongs to the witnessed USB path, where the Engine commands the wire directly and asks nothing of Android's routing. On the wayward paths — Heretical and Penitent — the Engine instead leans on the system's own routing to reach the output, and on some devices that route passes through the very USB machinery this toggle disables; there, enabling it could silence the Engine itself. Turn it on for listening over your USB DAC, and off again when you rely on a wayward path.
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.
Does the Engine level volume between tracks, or read ReplayGain?
It does both, by the listener's choice, and neither by default. Two roads to a consistent loudness are offered, and they are mutually exclusive — you elect one, or none. The first is the Received Word: where your files already carry ReplayGain tags, the Engine honors them — the mastering house's own number, taken as testimony — in track or album mode as you prefer. The second is the Witnessed Measure, which does not depend on a tag: it walks your reliquary and computes each track's own integrated loudness by the ITU-R BS.1770 standard, to a common target, and once it has, that measure governs — written to its own ledger, never to your files. For a track it has not yet reached, it leans on the file's own tag rather than guess, until its own measure supersedes it. Neither road runs unbidden; the measure is taken only when you ask.
What sets either apart from an ordinary player's leveling is where the correction lands. Carried on the DAC's own hardware volume, the samples are never touched: the native bitstream reaches the wire exactly as it left the decoder, and the Sealed Witness still reads VERIFIED — loudness matched and bit-perfect kept, both at once. Applied instead as digital volume, the Engine declares the change plainly: the Witness reads ALTERED, the expected mark of a gain you asked for, never a fault. On a DAC that exposes no hardware volume of its own, the Engine says so when the device connects, and the control is not shown in Output settings — it does not reach for the digital volume in its place.
And DSD is the hard case — where loudness and native playback ordinarily cannot be had at once. Loudness cannot be leveled on a one-bit stream directly, and the prevailing standard is to surrender native playback: decimate the DSD to PCM so a gain can be applied, and lose the very thing that made it DSD. The Engine refuses the trade. It takes its measure beforehand, from a decimated reading set quietly to one side and played to nothing; the true one-bit stream is never touched by it. At playback the correction rides the hardware volume, never the samples — and a native DSD stream, bit-for-bit as the file holds it, reaches the wire loudness-matched and witnessed at once, leveled without being lessened.
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.
Consulting the Forge…
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?
The internal converter, yes — now, by the same wayward roads that reach any phone's. A digital audio player is, to the Engine, an Android device with an unusually capable DAC inside it, and the wayward paths reach it no differently: the Heretical path hands the signal to the player's standard output, and the Penitent path petitions an exclusive delivery there where the platform allows. Where the DAP exposes its internal converter on the ordinary Android surface, that signal reaches it, and you hear it. What is not yet open is the proprietary route some makers reserve to their own player — a closed internal pipeline the Engine cannot enter today. Not by refusal: that door is the maker's to open, and were one to open it, the Forge would gladly walk through. The ordinary path is open now; the private one waits only on an invitation.
Should that invitation come, a witnessed internal route — one earning the descriptor scrutiny and integrity verification the USB path receives — would still be real work, raised per manufacturer and per firmware revision. The Forge does not pretend the cost is small; it would simply bear it gladly, were a maker to open the door. Until then, the witnessed path on a DAP is the one it always was: the player's USB output, where it exposes one, driving whatever external USB DAC the listener pairs. The internal converter you may now hear through the Engine; the proven signal still travels the wire.
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.