OBS audio routing for translation — the dedicated mic capture pattern

The single most common mistake when adding live translation to an OBS stream is sending the wrong audio into the translation engine. Streamers reach for the simplest option — let Loquira listen to whatever OBS is playing — and the resulting translated track is noticeably worse than it should be. The fix is straightforward but rarely intuitive: feed Loquira a dedicated microphone capture, separated from the OBS desktop audio mix.

This article walks through the routing in detail, with concrete setup recipes for Windows and macOS. It assumes you already use OBS Studio for streaming and that you have a dedicated microphone (USB, XLR, or wireless lavalier). It does not require any audio engineering background.

Why the dedicated mic capture matters

Speech recognition models are tuned to recognise one voice in a relatively clean signal. The model has a finite recognition budget — a quality threshold below which its output degrades. When the input is your voice plus background music plus a stream alert sound plus the game’s footsteps, the model spends recognition budget separating those signals. The voice survives, but with more errors than it would otherwise.

The translation stage cannot recover from STT errors. A misrecognised word in the source language becomes a wrong word in the target language. Listeners experience this as a translated track that sounds like the speaker is constantly making minor word-substitution mistakes — confusing and increasingly fatiguing over a long session.

Feeding Loquira a dedicated mic capture — your voice and only your voice — keeps the recognition engine focused. Game audio, music, and alerts go to the broadcast (where listeners want them) but not to the translation pipeline (where they create errors).

The same principle applies to voice-changers, pitch-shifters, and large reverb effects. The translation engine wants the dry signal. Effects belong downstream of the recognition tap, applied to the broadcast mix only. For VTubers using pitch-shifted character voices, this is non-negotiable — see how VTubers reach international audiences for the specific setup.

The shape of the routing

Conceptually, the routing splits your microphone into two paths immediately after capture:

Microphone
    ├──→ Effects chain → OBS broadcast mix → Twitch / YouTube / etc.
    └──→ Loquira translation engine

Both paths see the same dry mic signal. The broadcast path adds effects, mixes in game audio, applies your usual broadcast processing. The translation path stays clean.

On a phone or tablet running Loquira, the microphone is the device’s own input — no routing needed; just position the mic close to your mouth. The complications start when Loquira runs on the same machine as OBS, or when you want OBS itself to feed Loquira to keep your physical mic dedicated to OBS’s chain.

There are three viable patterns:

Pattern A — Separate device, separate mic. Loquira runs on a phone or tablet with its own built-in or USB microphone, positioned next to your main mic. This is the simplest setup and avoids all routing entirely. The downside is mic redundancy — you’re paying for and managing two mics for one voice. For most solo creators with a single broadcast-quality mic, this pattern is overkill.

Pattern B — Separate device, shared physical mic via splitter. Loquira runs on a phone or tablet. The microphone signal physically splits before reaching either device — a TRRS splitter for a lavalier, a Y-cable for XLR, or a USB hub with audio passthrough. Both devices receive the same clean mic signal. This is the cleanest pattern technically but requires hardware that varies by microphone type. The microphone guide covers compatible hardware combinations.

Pattern C — Same machine, virtual audio routing. OBS and Loquira run on the same machine. A virtual audio device routes the microphone to both OBS and Loquira simultaneously. This is the most flexible pattern and the one most experienced streamers settle on. It requires a virtual audio cable utility — VoiceMeeter on Windows, Loopback or BlackHole on macOS.

The rest of this article focuses on Pattern C, which is the most general-purpose setup and the one with the most setup confusion.

Pattern C on Windows: VoiceMeeter Banana

VoiceMeeter Banana is the standard tool for virtual audio routing on Windows. It’s free, stable, and well-documented. The version you want is the “Banana” tier — Standard is too limited, Potato is overkill.

The high-level setup:

1. Install VoiceMeeter Banana. Download from voicemeeter.com. Restart after install — the virtual audio devices register at boot.
2. Configure your microphone as Hardware Input 1. In VoiceMeeter, click the “Hardware Input 1” dropdown and select your USB microphone or audio interface.
3. Set up two virtual outputs. Hardware Input 1 should route to both the “A1” bus (your physical broadcast monitoring output) and the “B1” virtual output. The A1 path is for OBS monitoring; the B1 path is the virtual cable to Loquira.
4. Configure Loquira to listen to VoiceMeeter B1. When Loquira asks for an audio input device, select “VoiceMeeter Out B1” (the exact label varies slightly by Loquira version).
5. Configure OBS to listen to Hardware Input 1 directly OR to VoiceMeeter B1. Both work; the direct path has lower latency, the VoiceMeeter path lets you apply effects in VoiceMeeter and have both OBS and the broadcast pick up the effected version while still leaving B1 clean if you have it on a separate bus.

The critical detail: keep the bus that goes to Loquira clean. No effects, no auxiliary inputs, just the dry mic signal. Effects belong on a separate VoiceMeeter bus that feeds OBS only.

If you’re new to VoiceMeeter, the interface looks intimidating — a board with lots of knobs and routing switches. The 3-strip layout is actually simple once you know what each strip is: Hardware Input 1, 2, 3 are physical inputs; Virtual Inputs 1, 2 are software audio (e.g. Discord, Spotify); the buses A1, A2, A3 are physical outputs; B1, B2 are virtual outputs. Routing is checkbox-based: click the “B1” indicator on Hardware Input 1 to send your mic to the B1 virtual output. That’s the whole concept.

Pattern C on macOS: Loopback or BlackHole

macOS has two main options. Loopback (Rogue Amoeba) is paid (~$120 one-time) and more capable. BlackHole is free, open-source, and adequate for the dedicated-capture pattern. Either works.

Loopback setup:

1. Install and launch Loopback. Create a new virtual device — call it “Loquira Mic Route”.
2. Add your microphone as the source. Click the ”+” next to “Sources” and pick your physical microphone or audio interface.
3. Confirm the channels are mono or stereo as your mic provides. Most mics are mono; let Loopback route mono in, mono out.
4. Loopback is now visible system-wide as a virtual audio device. In Loquira, select “Loquira Mic Route” as the audio input. In OBS, continue listening directly to your physical microphone — there’s no need to route OBS through Loopback unless you also want to apply effects in Loopback’s processing chain.

BlackHole setup:

BlackHole is more primitive — it creates a single virtual audio device that any app can read from and write to, but it doesn’t have Loopback’s routing UI. The standard pattern is:

1. Install BlackHole 2ch. Download from existential.audio/blackhole. Restart after install.
2. Create a Multi-Output Device in Audio MIDI Setup. Open /Applications/Utilities/Audio MIDI Setup.app, click the ”+” in the bottom-left, choose “Create Multi-Output Device”. Add both your physical mic and BlackHole 2ch to the device.
3. Wait — BlackHole 2ch is an output, not an input. The Multi-Output approach works for the reverse case (sending one app’s output to multiple destinations). For the input-splitting case you want, you need an “Aggregate Device” instead, or you can route differently: have OBS listen to the mic directly, and have Loquira listen to BlackHole 2ch with a small utility (or just Audio Hijack from Rogue Amoeba) sending the mic into BlackHole.

In practice, on macOS, Loopback is worth the $120 for streamers who want a clean Pattern C setup. BlackHole is fine if you’re handy with Core Audio and don’t mind a more manual setup.

OBS-side configuration

Inside OBS, your sources should look like this:

• Mic source 1: physical microphone (direct). This is what the broadcast hears. Apply effects (compression, noise gate, EQ) on this source.
• Audio Monitoring (in OBS settings → Audio). Use this only if you need to hear yourself in your headphones. Don’t enable Monitor Only on the mic source — that disconnects it from the broadcast.

You do not need a separate OBS source for the Loquira-bound audio. Loquira reads from the virtual audio device directly, outside of OBS. OBS doesn’t need to know Loquira exists.

A common mistake: adding a “Loquira” audio source in OBS to “make sure the translation is in the broadcast.” This is wrong on two counts. First, Loquira’s translated audio is delivered to listeners through the Loquira app or join link, not through the broadcast — there is no translated audio to capture from Loquira back into OBS. Second, the original-language audio is already in OBS via your microphone source; adding a second copy creates an echo.

Verifying the routing

After setup, run a short test session before going live. The audio path you want to verify:

1. Start a Loquira session. Open the Loquira app or web interface on the streaming machine.
2. Confirm the input device. It should be the virtual audio device (VoiceMeeter B1 on Windows, Loopback / BlackHole on macOS), not the physical microphone.
3. Speak for ~30 seconds at normal volume. Watch the recognition transcript. It should pick up your words cleanly.
4. Play game audio or music in the background. The recognition transcript should not show transcription of the game audio. If it does, your routing is wrong — Loquira is picking up the desktop mix instead of just your mic.
5. Compare to OBS. OBS should be picking up your voice plus the game audio (or whatever your normal stream mix is). Both paths are receiving what they should.

If step 4 fails, the most common cause on Windows is that VoiceMeeter is routing too much to B1 — check the B1 indicator on every input strip and make sure only Hardware Input 1 (your mic) is enabled, not Virtual Input 1 (which captures desktop audio).

Latency considerations

The dedicated-capture routing does not add meaningful latency to the translation pipeline. VoiceMeeter and Loopback both run with ~5–15ms internal latency; the translation pipeline itself adds 350–1000ms depending on the language pair. The routing is a rounding error compared to the pipeline.

This matters for two specific cases:

• Streamers who lipsync to music. If your broadcast monitoring runs through the virtual cable instead of direct, you’ll hear yourself slightly delayed in your headphones. Keep monitoring on the direct mic path, not through the virtual cable.
• Competitive game voice callouts. The translation latency is 0.5–1.0 seconds regardless of routing. For competitive contexts this is too high — see latency budget for live-streaming translation for the longer discussion.

What about phone-based Loquira and OBS together?

If you prefer to keep Loquira on a phone or tablet (Pattern A or B) and OBS on the streaming PC, the routing question simplifies dramatically. The phone has its own microphone (Pattern A) or splits the physical mic with a TRRS / XLR / USB-audio splitter (Pattern B). No virtual audio cables needed.

This is the setup many new streamers start with, and it’s perfectly fine. The reasons creators move to Pattern C over time are usually: wanting OBS-side audio effects to apply to the broadcast without applying to translation (Pattern C cleanly separates them), wanting one less device on the desk, or wanting easier portability between rigs.

What about OBS’s own audio filters?

OBS has built-in audio filters — noise gate, compressor, EQ. Should you apply them to the mic source before sending audio to Loquira?

The answer is: do not apply them on the path to Loquira. Apply them on the broadcast path only. Loquira’s recognition engine has its own noise suppression tuned for speech recognition; the OBS noise gate can clip word beginnings if set too aggressively, hurting recognition. Compression can flatten dynamics in ways that don’t help recognition. EQ is fine in moderation but should not boost frequencies above 8kHz heavily (recognition tunes for the 100Hz–6kHz vocal range).

With Pattern C and a separate virtual cable bus, this is automatic: OBS’s filters apply to the OBS source (the broadcast path) and the Loquira cable bus is untouched.

The summary recipe

For most OBS streamers with a dedicated microphone:

1. Install a virtual audio cable utility (VoiceMeeter Banana on Windows, Loopback on macOS).
2. Configure the utility to mirror your mic to a virtual output that Loquira can read from.
3. Set Loquira’s input device to that virtual output. Confirm Loquira hears only your voice, not desktop audio.
4. Leave OBS’s mic source on the physical microphone directly. Apply broadcast effects (gate, compression, EQ) on this source.
5. Run a 30-second test session with game audio playing in the background. Confirm Loquira’s transcript shows only your voice.

That’s the entire setup. Once configured, it persists between streams — you don’t reconfigure each session. The OBS Studio platform integration guide covers the specific Loquira app side of the configuration; this article covers the audio routing side.

Combined, they’re the cleanest way to add live translation to an OBS-based stream without compromising broadcast or translation quality.

---

Want to try it? Start a free session — speak in any of 49 languages, your audience hears in 225. No setup, no credit card.