Start here: three questions
There is no single correct audio configuration, because the correct one depends on what you are trying to do. Work through these three questions in order; the table further down turns your answers into two short columns, what to set in VoxisLive and what to set in the other app.
- Are you on Windows or on Linux?
- Which direction do you need — I want to hear them, they should hear me, or both?
- Is a virtual microphone installed on this machine?
If you already know all three answers, the table is what you came for. If you are not sure what any of the terms mean, read the questions first — they are short, and getting question two wrong is the reason most setups end up silent in one direction.
Question 1 — Windows or Linux
On Windows 10 and 11, VoxisLive reads what your sound card is already playing through WASAPI loopback. Nothing has to be installed for that, and no driver has to be chosen: the app captures the system mix directly and plays the translated voice back to a device you pick.
On Linux, VoxisLive is installed from the Snap Store and captures through PipeWire instead. The setup questions below are the same, but a freshly installed snap may still need its audio permission granted before it can hear anything — that is covered on the Linux install page, not here.
If you are on Linux and the app is running but the level meters never move, treat it as a permission problem before treating it as an audio-routing problem. A denied capture permission looks identical to a wrong device from inside the app.
Question 2 — which direction do you need
This is the question that decides the scenario, and it is worth being precise about. There are two genuinely different jobs, and they do not share a setup.
“I want to hear them” — one direction
You are watching a video, playing a game, following a stream, or sitting in a call where you do not need to be understood in another language. Sound goes from the other side to you, and that is all. Pick the Video / Game scenario. Nothing needs to be installed, nothing needs to be selected as a microphone anywhere, and the app you are listening to does not need to be touched at all — it keeps playing sound the way it already does.
“They should hear me”, or both directions
You are in a live conversation and the other side needs to hear your words in their language. That is the Meeting scenario, and it runs two translations at the same time: the incoming one you hear in your headphones, and the outgoing one that is spoken into the call for you. The outgoing half is the half that needs a virtual microphone — which is question three.
Before you plan a Meeting setup: the free tier does not cover Meeting mode. Meeting sessions need a paid plan or a prepaid minute pack — see pricing. If you only need the one-way direction, the free tier is the right place to start.
Question 3 — is a virtual microphone installed
A virtual microphone is a small free driver, for example VB-CABLE, that appears in Windows as both a playback device and a recording device. VoxisLive speaks your translated words into it, and your conferencing app records from it — that is how the other participants hear a voice saying your words in their language, without anything joining the call.
It matters for one direction and one direction only. Incoming translation never needs it. Meeting mode pins its capture to the driverless path, so what you hear is captured the same way it is in Video / Game mode, and a virtual cable is required purely for sending your own translated voice outward. If no virtual microphone is installed, Meeting mode still runs — you hear the other side in your language, and the outgoing direction simply stays off.
What to set, side by side
Find the row that matches your three answers. The left column is set once inside VoxisLive before you press start; the right column is set in the meeting app, player or browser you are listening to.
| Your three answers | Set in VoxisLive | Set in the meeting or player app |
|---|---|---|
| Windows or Linux · hear them only · no virtual microphone | Video / Game scenario. Output device: your headphones. Ducking on, so the original is lowered while the translated voice speaks. | Nothing. Keep playing sound through the device you normally use. |
| Windows · both directions · virtual microphone installed | Meeting scenario. “I hear in”: your language. “They hear in”: theirs. Output device: your headphones. Microphone: the physical one you actually speak into. | Microphone: the virtual cable. Speaker: your headphones — the same device you selected in VoxisLive. |
| Windows · both directions · no virtual microphone | Meeting scenario. Set “I hear in” to your language and start normally; the outgoing direction stays off. | Leave the microphone as it is. The other side hears your untranslated voice, as before. |
| Any system · hear them only · virtual microphone already installed for something else | Video / Game scenario. Output device: your headphones, not the cable. | Nothing — and make sure the app is not already recording from the same cable. |
The one-sentence version of the second row: the other side hears a natural voice speaking your words in their language, a few seconds behind you, with no extra participant in the call.
One cable cannot do both jobs
This is a common way a Meeting setup goes wrong, and it does not announce itself as a setup error — it announces itself as a strange third voice. If the same virtual cable is set as both the place VoxisLive sends the translated voice and the place it captures from, the translated audio comes back in as if it were new speech from the meeting. The app then translates its own output, and what everyone hears is a phantom third participant talking over both of you. The fix is the separation in the table above: the cable carries the outgoing direction, your headphones carry the incoming one.
If a virtual cable that you configured yourself is being used while a session is running, VoxisLive tells you with a card in the app rather than leaving you to work it out from the sound. Read that card before changing anything else — it names what is on the cable.
Open speakers, and why headphones are the recommendation
Headphones are the recommended setup for any two-way session, for a plain acoustic reason rather than a preference: if the translated voice comes out of open speakers, your microphone picks it up along with your own voice, and the outgoing direction ends up carrying audio it was never meant to carry.
VoxisLive detects when it looks like you are running on open speakers and raises that at the start of a session. It is a warning, not a block — the session starts either way, and there are rooms and hardware setups where speakers are genuinely fine. You are told what the app sees; the decision stays yours.
Check the audio path before you blame the translation
If nothing is happening, it is worth separating “the app cannot hear” from “the app cannot be heard” from “the translation is not arriving”. VoxisLive carries independent audio diagnostics for exactly that, and the important word is independent: each one runs on its own, so a pass on one tells you nothing about the others, and a failure on one does not mean the rest are broken.
- Test tone — plays a sound through the output device you selected. If you do not hear it, the problem is the output device, not the translation.
- System level meter — shows whether the app is actually hearing what your machine is playing. A flat meter while a video plays means capture, not translation.
- Microphone meter — shows whether the microphone you picked is producing anything. This is the one that matters for the outgoing direction in Meeting mode.
Run the one that matches the direction that is failing. If all three behave and a session still produces nothing, the problem has moved past audio setup — troubleshooting picks up from there, and the app has a built-in problem report that sends a scrubbed log along with your description.
What this checklist is not
- It is not a latency fix. Simultaneous interpretation runs a few seconds behind the speaker by nature, and no audio routing removes that span.
- It is not a list of supported conferencing apps. Capture happens at the system audio layer, so the app you are listening to is not part of the configuration.
- It is not a substitute for the Linux install steps. A snap that has not been granted audio permission cannot be fixed with device selection.
- It does not cover what happens to your audio after capture — that is on how it works and privacy.
If you are setting up for a specific situation rather than in general, the meetings page walks through the two-way case end to end, and features lists what else is in the app once audio is working.