Audio problems

Use a quiet test channel and one other member. Change one setting at a time and repeat the same sentence. Start in More, Settings, Voice on desktop, or Settings, Voice on mobile.

1. Does the client receive your microphone?

1. Turn voice on if the page offers Turn voice on. A connected text session does not by itself mean the audio engine is running.
2. Select the microphone by name in Input device. System default can change when a headset is connected or a Bluetooth device changes profile.
3. Speak while watching the voice-gate meter. Check that Microphone volume is not zero.

Observation	What to test next
No level movement	Check microphone permission and the input device in the OS. Record with another app using the same device. If that also fails, resolve device/permission access first.
The OS recorder works, but Fancy Mumble’s meter does not	Re-select the input. On Windows, disable Exclusive microphone mode and close other apps holding the device. Turn voice off and on after the change. Capture the resulting device error in the client log.
Level responds to speech	Continue to the sample recorder. Increasing gain will not fix a transmission or channel-permission problem.

On Windows, check Settings, Privacy & security, Microphone and access for desktop apps. On Android, check the app’s Microphone permission. On Linux, check the recording stream’s selected source in your PipeWire/PulseAudio mixer; an output monitor records the desktop instead of your microphone.

2. Is the processed signal usable?

Use Hear yourself, Record sample, speak for a few seconds, stop, and play it back. This tests the configured processing locally; it does not establish that another member receives your voice.

Sample result	Next check
No playback, and other members are also inaudible	Select Output device, raise Speaker volume from zero, and check the OS per-app volume. Test another app through the same headphones.
Loud cracks or distortion	Lower the microphone’s OS input level and compare with Auto gain off. If the OS recorder is already distorted, changing the chat bitrate cannot repair the source.
Words become metallic or disappear	Compare the same sentence with noise suppression Off, then with one algorithm enabled. Keep the option that preserves speech; do not combine this test with a gain or network change.
Clear sample	Continue to activation and permissions.

Noise suppression and the activation gate do different jobs: suppression processes sound; the gate decides when transmission is allowed. Continuous activation does not mean processing is disabled.

3. Does activation allow transmission?

Keep the microphone unmuted and headphones undeafened. Check the channel is the one you joined for voice, rather than only the conversation you are viewing.

1. Temporarily select Continuous in the test channel and ask your partner to listen.
2. If Continuous works but Voice activation does not, use Auto calibrate, press Calibrate, and speak naturally for about five seconds.
3. For Manual calibrate, the Open marker must be crossed to begin transmitting. The lower Close marker and hold keep the gate open between syllables. A close threshold nearer the opening threshold makes it easier to close; raising it is not a general fix for cut-off speech.
4. If Continuous works but Push to talk does not, check the assigned shortcut and whether it is detected with the client both focused and in the background. Do not use mute as the push-to-talk switch.
5. Restore your usual activation mode after the test.

If the local sample is clear and Continuous still cannot be heard, ask an administrator to check Speak permission and suppression in that channel. Try a channel where a known working member can speak. Record whether your own speaking indicator appears and whether the other member sees it.

4. Is voice transport the failing part?

Use Force TCP audio in the Transmission section as a comparison. Repeat the same test with it off and on; allow the client time to apply the change.

Result	Interpretation and action
Voice works only with Force TCP audio	UDP reachability or the UDP voice path needs investigation. Report the server address, port, and test result to its owner.
Voice fails over both paths, but local recording works	Check channel permissions, mute/suppression, and both clients’ logs before changing codec settings.
Only one listener fails	Check that listener’s output device, local user mute/volume, and connection.
All members become choppy together	Compare server voice-service logs and host load at the recorded time.

For the maintained Starling Compose deployment, normal Mumble voice needs 64738/UDP, while control needs 64738/TCP. A successful TCP port test does not test UDP. The owner should check the published UDP mapping and both host and cloud firewalls; see Connection problems.

For stutter, make a controlled comparison using lower Quality (for example 32 kb/s) or a different Audio per packet value. A 40 ms packet bundles more audio into fewer packets than 20 ms and adds packetization delay; it is not a packet-loss repair. Note which change actually helped, then restore settings that did not.

Echo and feedback

Mute your microphone during an echo and ask whether the echo stops. If it does, test with headphones and disable any loopback/desktop-monitor input. If it continues, isolate other participants one at a time. This identifies whose capture path contains the returned audio instead of asking everyone to change noise suppression.

Evidence to attach

Include input/output device names, activation mode, sample-recorder result, Continuous result, UDP-versus-TCP result, affected channel and listeners, and a timestamp with timezone. Attach a screenshot of Voice settings and client logs. This lets maintainers distinguish capture, processing, permission, and transport failures.