starred/mumble-mumble-voip

Fork 0

mirror of https://github.com/mumble-voip/mumble.git synced 2026-03-03 00:46:56 -05:00

Default audio settings can be non-functional #2941

New issue

Open

opened 2026-02-20 22:15:22 -05:00 by deekerman · 2 comments

deekerman commented

2026-02-20 22:15:22 -05:00

Owner

Originally created by @Krzmbrzl on GitHub (Jan 11, 2025).

Description

When freshly installing Mumble, Mumble somehow selects an audio backend to use and also an input and an output device that it will try to use.
However, the defaults chosen for this are by no means guaranteed to work.

Steps to reproduce

Freshly install Mumble or delete the settings file (and backup) so Mumble needs to initialize its settings from scratch (including audio backend and audio input/output devices).

Mumble version

All

Mumble component

Client

OS

Other

Reproducible?

Yes

Additional information

Ideally, we should have some sort of check in place to see whether the currently selected devices and backends can be used at all.

For the audio backend this could be as simple as checking whether initializing that backend as even succesful.

For audio devices, this is likely more tricky. The correct thing to do would likely be to interface with the OS in some way to query the default input and default output device that it is currently using. Ideally, just using whatever is configured in the OS would be its own option (that works and keeps in sync with the OS).

Related issues:

#6545
#6630

Relevant log output

No response

Screenshots

No response

Originally created by @Krzmbrzl on GitHub (Jan 11, 2025). ### Description When freshly installing Mumble, Mumble somehow selects an audio backend to use and also an input and an output device that it will try to use. However, the defaults chosen for this are by no means guaranteed to work. ### Steps to reproduce Freshly install Mumble or delete the settings file (and backup) so Mumble needs to initialize its settings from scratch (including audio backend and audio input/output devices). ### Mumble version All ### Mumble component Client ### OS Other ### Reproducible? Yes ### Additional information Ideally, we should have some sort of check in place to see whether the currently selected devices and backends can be used at all. For the audio backend this could be as simple as checking whether initializing that backend as even succesful. For audio devices, this is likely more tricky. The correct thing to do would likely be to interface with the OS in some way to query the default input and default output device that it is currently using. Ideally, just using whatever is configured in the OS would be its own option (that works and keeps in sync with the OS). Related issues: - #6545 - #6630 ### Relevant log output _No response_ ### Screenshots _No response_

deekerman added the

labels

2026-02-20 22:15:22 -05:00

deekerman commented

2026-02-20 22:15:24 -05:00

Author

Owner

@mevemo commented on GitHub (Apr 23, 2025):

I am having the same issues.

The Mac client crashes or loses audio routing when AirPods are connected or disconnected

Description:
When using the Mumble Mac client (tested on macOS 15.4), connecting or disconnecting AirPods causes serious audio issues. In some cases, the application becomes unresponsive or crashes entirely.

Steps to reproduce:

Start Mumble with internal speakers or other output device active.
Connect AirPods (automatic handover by macOS).
Observe:
- Either only other Mac users can be heard or nobody at all.
- Audio routing breaks.
- In some cases, the client crashes or freezes.
Manually opening Mumble's settings and reapplying them often resolves the issue — temporarily.
When AirPods move out of range, the issue occurs again, sometimes crashing the client.

Expected behavior:
The Mumble client should handle output device changes (especially wireless ones like AirPods) gracefully without crashing or losing audio routing.

Additional notes:
It might be related to how macOS handles Bluetooth audio devices that switch between "music" and "call" modes.

@mevemo commented on GitHub (Apr 23, 2025): I am having the same issues. The Mac client crashes or loses audio routing when AirPods are connected or disconnected **Description:** When using the Mumble Mac client (tested on macOS 15.4), connecting or disconnecting AirPods causes serious audio issues. In some cases, the application becomes unresponsive or crashes entirely. **Steps to reproduce:** 1. Start Mumble with internal speakers or other output device active. 2. Connect AirPods (automatic handover by macOS). 3. Observe: - Either only other Mac users can be heard or nobody at all. - Audio routing breaks. - In some cases, the client crashes or freezes. 4. Manually opening Mumble's settings and reapplying them often resolves the issue — temporarily. 5. When AirPods move out of range, the issue occurs again, sometimes crashing the client. **Expected behavior:** The Mumble client should handle output device changes (especially wireless ones like AirPods) gracefully without crashing or losing audio routing. **Additional notes:** It might be related to how macOS handles Bluetooth audio devices that switch between "music" and "call" modes.

deekerman commented

2026-02-20 22:15:25 -05:00

Author

Owner

@victorlapshev commented on GitHub (Sep 7, 2025):

Same here, unusable on Mac with AirPods

@victorlapshev commented on GitHub (Sep 7, 2025): Same here, unusable on Mac with AirPods