Increase default audio quality and reduce latency (#6936)

[ViniciusMassuda]

This PR updates the default audio settings as discussed in #6936:

• Bitrate: iQuality increased from 40k to 96k.
• Latency: iFramesPerPacket decreased from 2 (20ms) to 1 (10ms).

Fixes #6936

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 02d3d80d-6f1a-4905-90be-6446f49ab597

📥 Commits

Reviewing files that changed from the base of the PR and between 3fede1b and 0b81828.

📒 Files selected for processing (1)

• src/mumble/Settings.h

---

Walkthrough

Audio quality default settings were adjusted in the Settings structure. The iQuality field default value was increased from 40000 to 96000. Simultaneously, the iFramesPerPacket field default value was decreased from 2 to 1. These modifications affect the default audio/TTS-related configuration applied when the application initializes, though the overall structure and functionality remain unchanged.

🚥 Pre-merge checks | ✅ 3 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Linked Issues check	⚠️ Warning	The PR modifies default client-side audio settings but does not implement the server-wide or channel-specific override features requested in issue #6936.	This PR only addresses partial client-side defaults; implement server-wide settings and channel-specific overrides as specified in #6936 requirements.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'Increase default audio quality and reduce latency' clearly and specifically describes the two main changes made to the audio settings in this PR.
Description check	✅ Passed	The PR description provides clear details about the changes made, including specific values and context, though it could reference the template's commit guidelines check.
Out of Scope Changes check	✅ Passed	The PR is narrowly focused on updating two default audio settings in Settings.h with no extraneous changes.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[winex]

omg

• 28% overhead from current (and already pretty high) value of 14%!
• 2x packet rate (sic!)

NO, thanks! it would introduce unnecessary packet loss in periods of higher load (read: prime time) or technical issues on networks

you should fix your audio setup first after making proper measurements! mumble itself is already blazing fast!
FYI: 20ms is already 2/10th of average human reaction, way MORE than enough for SPEECH!

p.s.

i've been using murmur + mumble for the whole 16 years already (since ~2009 or so) and heard many devices in different scenarios, short and long distances (up to 9000km) and can state next:

• 10ms: only for wired LANs, or very specific scenarios like real-time singing or musical instruments
• 20ms: good default, balanced overhead vs packet rate
• 40ms: much better for mobile/radio/Wi-Fi devices or really looong RTT (physical distance) to server

[winex]

agreed

this default could be increased about 2x:

• 40000 with overhead totals: <= 64kbps
• 80000 with overhead totals: <= 96kbps
• server configuration can limit it back -- nothing will break, yay!

please test these values as DEFAULTs and report your findings!
thank you!

[ViniciusMassuda]

Thanks for the technical breakdown @winex!

I've updated the code to 80000 and 2. These default values are ideal because:

Setting iQuality to 80000 hits the "sweet spot" for high-fidelity audio, while staying safely under the 96 kbps server-side limit once network overhead is factored in.

Maintaining iFramesPerPacket = 2 ensures there is no regression in network performance, as this is already the proven stable value for Mumble’s current architecture.