How to Put an AI That Actually Talks in a Discord Voice Channel
· Laurentiu Dobra · 10 min read · Community Management
Most "voice" Discord bots read a written reply aloud. A speech-to-speech model is a different thing: it hears you, answers out loud, and stops when you interrupt. Here is how it works, what it costs, and the two problems nobody warns you about.
Table of Contents
- Short answer
- Text-to-speech is not the same thing
- How the audio actually moves
- Problem one: who is allowed to talk
- Problem two: it hears itself
- What it costs, and why that is the real design constraint
- Setting it up in Wallu
- When voice is worse than text
- FAQ
Short answer
A voice AI in Discord is a bot that joins a voice channel, listens to whoever is
speaking, and answers out loud. The useful version uses a speech-to-speech
model: audio goes in, audio comes out, with no written step in between. That is
what makes it fast enough to interrupt and be interrupted like a person.
The parts that decide whether it is any good are not the model. They are turn
taking, echo, and cost control. Most guides skip all three.
Text-to-speech is not the same thing
Nearly everything sold as a "voice Discord bot" is one of these:
- A soundboard. It plays clips on command. No understanding at all.
- Text-to-speech. It takes a written answer and reads it aloud. The pipeline is
speech recognition, then a text model, then a voice. Three hops, each adding
delay, and the whole reply is generated before a single word is spoken.
- Speech to speech. One model takes audio and emits audio. It can start
answering before you have finished, and it can stop mid-word when you cut in.
The difference is obvious the moment you interrupt one. A text-to-speech bot
finishes its sentence because the sentence already exists. A speech-to-speech bot
stops, because nothing has been written yet.
If you only need the bot to announce events or read out rules, text-to-speech is
cheaper and perfectly adequate. If you want members to ask it things, the gap
between the two is the entire product.
How the audio actually moves
Worth knowing, because every sample rate in the chain is different and mismatches
are where the sound goes wrong.
- Discord sends and expects 48 kHz stereo Opus. Not raw audio, and not mono.
- Speech-to-speech models typically want 16 kHz mono in. Ours does.
- They usually return a different rate again. Ours returns 24 kHz mono.
So the bot decodes Opus to PCM, downsamples 48 kHz stereo to 16 kHz mono on the way
in, and upsamples 24 kHz mono back to 48 kHz stereo on the way out. Both are exact
integer ratios, 3:1 and 1:2, which is a small mercy: no resampling library is
needed and nothing drifts out of sync.
One detail that matters more than it sounds: **Discord gives you a separate audio
stream per speaker.** A microphone in a meeting room gives you one mixed stream and
you have to work out who said what. Discord has already done that for you. It also
means the bot never receives its own audio, which is relevant in a moment.
Problem one: who is allowed to talk
A web chat widget has one user with one microphone. A voice channel has ten people,
background music, mechanical keyboards and someone's dog.
You cannot mix them all into one stream and send it to the model. It arrives as
noise and the answers get correspondingly strange. So you need a rule for who holds
the floor. Ours is deliberately blunt: **the first person to start speaking holds
it until they stop**, and everyone else is ignored for that turn. It is not clever,
but it is predictable, which is worth more.
The harder question is when the bot should stop talking. The obvious approach is
to cut the audio the moment Discord reports somebody speaking. That turns out to be
badly wrong, and it is worth saying why, because it is the single most common way
these bots feel broken.
Discord flags a user as "speaking" as soon as their client transmits packets. A
cough does it. A keystroke does it. A dog does it. If you stop the bot on that
signal, the bot cuts itself off every few seconds and the conversation is unusable.
The right signal comes from the model, which is receiving the actual audio and can
tell speech from a chair creaking. It reports an interruption; the bot stops then,
and only then.
Problem two: it hears itself
This one confuses everybody, including us, so it is worth being precise.
The bot does not receive its own audio. It subscribes to specific users, and
Discord does not loop a bot's own transmission back to it.
But if a listener is on speakers rather than headphones, the bot's voice comes
out of those speakers, goes into that person's microphone, and arrives back at the
bot labelled as that person talking. The model then hears itself, decides a
human has started speaking, and politely stops. From the outside it looks exactly
like the bot interrupting itself for no reason.
There is no clever fix inside the bot. The audio genuinely is coming from that
user's microphone and is indistinguishable from them speaking. Acoustic echo
cancellation lives in the sending client, which is why Discord has it, and why it
helps but does not fully solve the case where the bot's output is loud.
Headphones remove the problem completely. If you are testing a voice bot and it
keeps cutting itself off, check that before you check anything else.
What it costs, and why that is the real design constraint
Speech-to-speech models bill per minute of audio, in both directions. That single
fact shapes the whole feature.
A text bot costs money per answer. If nobody asks anything, it costs nothing. A
voice bot sitting in a channel with its microphone open costs money per minute,
whether or not anyone speaks. Somebody wanders into the channel at midnight, walks
away from their desk, and the bot bills until morning.
So a voice feature needs cost controls that a text feature never does:
- Explicit activation. The bot joins on an event you choose, not permanently.
- An idle timeout. Ours leaves after two minutes with nobody speaking.
- Leave when the room empties. The moment the last human leaves.
- A hard allowance, checked while the call is running. Not at the end.
That last one is the one people get wrong. It is tempting to add up the minutes when
the call finishes, which is fine for a three-minute web call. A bot in a voice
channel can sit there for hours. Bill at the end and you discover someone spent 180
minutes of a 45-minute allowance, after the fact. The meter has to run during
the call and hang up when it hits the limit.
We also gate who can summon it. Bringing the bot into a channel requires the
Manage Server permission. Voice minutes are a paid resource, and without that
check any member of the server could spend the month's allowance on a dare.
Setting it up in Wallu
The Discord AI chatbot answers in text out of the box.
Voice is a switch on the same integration:
- Open Integrations - Discord and turn on Voice AI.
- Choose a voice channel. The bot joins when someone enters it.
- Leave the channel blank if you would rather summon it by hand.
A moderator with Manage Server can call it into any channel with /voice join and
dismiss it with /voice leave.
It answers from the same knowledge base as text. There is no separate voice
training step, and no second set of answers to keep in sync. Every call is recorded
and transcribed into your inbox as a normal conversation, so you can read back what
was asked, which is usually more useful than listening to the audio.
Voice minutes are one monthly pool shared across every surface. Minutes spent
talking to the widget on your website are minutes Discord does not have. We think
this is the honest way to meter it, and it is worth checking whether a tool you are
comparing does the same or quietly counts each channel separately. Voice is included
from the Starter plan upwards; the pricing page has the minutes for each
plan. Full setup detail is in the Discord bot docs.
When voice is worse than text
Voice is not a straight upgrade, and pretending otherwise wastes your allowance.
Voice is better for onboarding walkthroughs, anything where the member is
already in a call, quick back-and-forth troubleshooting, and communities where
people hang around in voice anyway.
Text is better for anything with a link, a code snippet, an order number, or a
step list. Nobody wants a URL read out to them. Text is also searchable, quotable
and free to re-read, and it costs per answer instead of per minute.
The sensible default is text everywhere, voice in one channel where people already
gather.
FAQ
Can a Discord bot really hold a conversation, or is it just reading text aloud?
Both exist. A speech-to-speech model hears audio and produces audio directly, which
is what allows it to be interrupted mid-sentence. Text-to-speech bots read a
finished written answer and cannot.
Does the bot hear everyone in the channel at once?
Discord provides a separate stream per speaker, so it can tell people apart. Ours
deliberately listens to one person at a time: whoever starts speaking holds the
floor until they stop, because mixing several speakers into one stream degrades the
answers.
Why does the bot keep interrupting itself?
Almost always speakers instead of headphones. Its own voice returns through the
listener's microphone and the model hears it as a person starting to talk. Switch to
headphones and it stops.
How much does voice cost compared with text?
Text bills per answer; voice bills per minute of audio in both directions. A voice
bot idling in a channel costs money even in silence, which is why it should leave
when the room empties rather than waiting there.
Do voice minutes come out of the same allowance as my website chat?
In Wallu, yes, deliberately: one monthly pool across every surface. Check this
before comparing plans, because a tool advertising a separate voice allowance per
channel is not necessarily giving you more.
What permissions does it need?
Connect and Speak in the voice channel. Summoning it requires Manage Server, so an
ordinary member cannot spend your monthly minutes.
