starred/mumble-mumble-voip

Fork 0

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

macOS client not receiving “shouts” into channel (works on Windows + iOS) #3084

New issue

Open

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

deekerman commented

2026-02-20 22:17:50 -05:00

Owner

Originally created by @wilki2208 on GitHub (Dec 29, 2025).

Description

Mumble version: 1.5.857
macOS version: 15.7.3

Description:
On macOS (15.7.3) using Mumble 1.5.857, shouts into my channel cannot be heard at all. This happens on both of my Macs.

If I’m sitting in a main channel and someone in a sub-channel uses shout, nothing comes through. No audio, no activity, it’s like they never spoke.

The exact same setup works fine on my Windows machines

So this looks specific to the macOS Mumble client rather than the server, channel layout, or user.

Expected behaviour:
When someone uses shout from another channel, their audio should be heard in the target channel, same as Windows and iOS.

Actual behaviour:
On macOS, shouts are completely silent. Normal talking inside the same channel works fine.

Steps to reproduce:

Join a main channel on macOS using Mumble 1.5.857

Have another user join a sub-channel

That user uses “shout”

macOS client hears nothing, while Windows and iOS clients hear it correctly

Extra info:

Reproducible on two different Macs

Same server, same users, same channels

Works everywhere else

Only macOS breaks

Steps to reproduce

Join a main channel on macOS using Mumble 1.5.857

Have another user join a sub-channel

That user uses “shout”

macOS client hears nothing, while Windows and iOS clients hear it correctly

Mumble version

1.5.857

Mumble component

Client

OS

macOS

Reproducible?

Yes

Additional information

No response

Relevant log output

Screenshots

No response

Originally created by @wilki2208 on GitHub (Dec 29, 2025). ### Description Mumble version: 1.5.857 macOS version: 15.7.3 Description: On macOS (15.7.3) using Mumble 1.5.857, shouts into my channel cannot be heard at all. This happens on both of my Macs. If I’m sitting in a main channel and someone in a sub-channel uses shout, nothing comes through. No audio, no activity, it’s like they never spoke. The exact same setup works fine on my Windows machines So this looks specific to the macOS Mumble client rather than the server, channel layout, or user. Expected behaviour: When someone uses shout from another channel, their audio should be heard in the target channel, same as Windows and iOS. Actual behaviour: On macOS, shouts are completely silent. Normal talking inside the same channel works fine. Steps to reproduce: Join a main channel on macOS using Mumble 1.5.857 Have another user join a sub-channel That user uses “shout” macOS client hears nothing, while Windows and iOS clients hear it correctly Extra info: Reproducible on two different Macs Same server, same users, same channels Works everywhere else Only macOS breaks ### Steps to reproduce Join a main channel on macOS using Mumble 1.5.857 Have another user join a sub-channel That user uses “shout” macOS client hears nothing, while Windows and iOS clients hear it correctly ### Mumble version 1.5.857 ### Mumble component Client ### OS macOS ### Reproducible? Yes ### Additional information _No response_ ### Relevant log output ```shell ``` ### Screenshots _No response_

deekerman added the

needs-more-input

bug

triage

labels

2026-02-20 22:17:50 -05:00

deekerman commented

2026-02-20 22:17:52 -05:00

Author

Owner

@Krzmbrzl commented on GitHub (Dec 29, 2025):

But regular conversations cam be heard normally? What OS is the shouting person using? And just to be sure: the shouting person is always shouting to the main channel in which your test client resides in?

Have you tried having e.g. a Windows and a macOS client in the main channel at the same time to verify that the Windows client hears the shout while simultaneously the macOS client doesn't?

@Krzmbrzl commented on GitHub (Dec 29, 2025): But regular conversations cam be heard normally? What OS is the shouting person using? And just to be sure: the shouting person is always shouting _to the main channel_ in which your test client resides in? Have you tried having e.g. a Windows and a macOS client in the main channel _at the same time_ to verify that the Windows client hears the shout while _simultaneously_ the macOS client doesn't?

deekerman commented

2026-02-20 22:17:52 -05:00

Author

Owner

@wilki2208 commented on GitHub (Dec 29, 2025):

But regular conversations cam be heard normally? What OS is the shouting person using? And just to be sure: the shouting person is always shouting to the main channel in which your test client resides in?

Have you tried having e.g. a Windows and a macOS client in the main channel at the same time to verify that the Windows client hears the shout while simultaneously the macOS client doesn't?

Hey! Sorry I have done it on a W11 device doing the shouting. To confirm, yes I have joined the same channel on both devices and I can hear him on W11 and not Mac.

@wilki2208 commented on GitHub (Dec 29, 2025): > But regular conversations cam be heard normally? What OS is the shouting person using? And just to be sure: the shouting person is always shouting _to the main channel_ in which your test client resides in? > > Have you tried having e.g. a Windows and a macOS client in the main channel _at the same time_ to verify that the Windows client hears the shout while _simultaneously_ the macOS client doesn't? Hey! Sorry I have done it on a W11 device doing the shouting. To confirm, yes I have joined the same channel on both devices and I can hear him on W11 and not Mac.

deekerman commented

2026-02-20 22:17:52 -05:00

Author

Owner

@wilki2208 commented on GitHub (Dec 29, 2025):

Yes also regular conversations are fine

@wilki2208 commented on GitHub (Dec 29, 2025): Yes also regular conversations are fine

deekerman commented

2026-02-20 22:17:52 -05:00

Author

Owner

@Hartmnt commented on GitHub (Dec 29, 2025):

@wilki2208 Just to be extra sure, the non-working macOS user is the exact same user (same certificate, same permissions) as the working user, right?

We have to make sure that the permissions/ACLs are exactly the same here

@Hartmnt commented on GitHub (Dec 29, 2025): @wilki2208 Just to be extra sure, the non-working macOS user is the exact same user (same certificate, same permissions) as the working user, right? We have to make sure that the permissions/ACLs are exactly the same here

deekerman commented

2026-02-20 22:17:52 -05:00

Author

Owner

@wilki2208 commented on GitHub (Dec 30, 2025):

@wilki2208 Just to be extra sure, the non-working macOS user is the exact same user (same certificate, same permissions) as the working user, right?

We have to make sure that the permissions/ACLs are exactly the same here

Yes, 100%.

I have a join button by the server im in, so I know its setup the exact same and same user.

@wilki2208 commented on GitHub (Dec 30, 2025): > [@wilki2208](https://github.com/wilki2208) Just to be extra sure, the non-working macOS user is the exact same user (same certificate, same permissions) as the working user, right? > > We have to make sure that the permissions/ACLs are exactly the same here Yes, 100%. I have a join button by the server im in, so I know its setup the exact same and same user.

deekerman commented

2026-02-20 22:17:52 -05:00

Author

Owner

@Krzmbrzl commented on GitHub (Dec 30, 2025):

I don't see any way how this could happen. Audio routing is done entirely server-side and the client only does the playback. If the user is the same, then the context for the server must be the same and hence the routing is the same. This would mean that the macOS client had to specifically refuse to play back audio received via shouts... such functionality doesn't even exist and this being a bug would be very, very weird.

Can this issue be reproduced on a different Mumble server?

@Krzmbrzl commented on GitHub (Dec 30, 2025): I don't see any way how this could happen. Audio routing is done entirely server-side and the client only does the playback. If the user is the same, then the context for the server must be the same and hence the routing is the same. This would mean that the macOS client had to specifically refuse to play back audio received via shouts... such functionality doesn't even exist and this being a bug would be very, very weird. Can this issue be reproduced on a different Mumble server?

deekerman commented

2026-02-20 22:17:52 -05:00

Author

Owner

@wilki2208 commented on GitHub (Dec 30, 2025):

I don't see any way how this could happen. Audio routing is done entirely server-side and the client only does the playback. If the user is the same, then the context for the server must be the same and hence the routing is the same. This would mean that the macOS client had to specifically refuse to play back audio received via shouts... such functionality doesn't even exist and this being a bug would be very, very weird.

Can this issue be reproduced on a different Mumble server?

I will get this tested tonight as we do have a test mumble server.

Although, I am not the only person reporting this in our Discord, we currently have 5 people who are all reporting the same error in a chain.

@wilki2208 commented on GitHub (Dec 30, 2025): > I don't see any way how this could happen. Audio routing is done entirely server-side and the client only does the playback. If the user is the same, then the context for the server must be the same and hence the routing is the same. This would mean that the macOS client had to specifically refuse to play back audio received via shouts... such functionality doesn't even exist and this being a bug would be very, very weird. > > Can this issue be reproduced on a different Mumble server? Hi I will get this tested tonight as we do have a test mumble server. Although, I am not the only person reporting this in our Discord, we currently have 5 people who are all reporting the same error in a chain.

deekerman commented

2026-02-20 22:17:52 -05:00

Author

Owner

@Krzmbrzl commented on GitHub (Dec 30, 2025):

I will get this tested tonight as we do have a test mumble server.

Thanks 👍

we currently have 5 people who are all reporting the same error in a chain.

all on the same server? or across different servers?

@Krzmbrzl commented on GitHub (Dec 30, 2025): > I will get this tested tonight as we do have a test mumble server. Thanks 👍 > we currently have 5 people who are all reporting the same error in a chain. all on the same server? or across different servers?

deekerman commented

2026-02-20 22:17:52 -05:00

Author

Owner

@soratidus999 commented on GitHub (Dec 31, 2025):

Hey team, some of the user reporting this issue are ours, we've reached the limit of our troubleshooting here as my understanding was that mux-ing and routing was done server side.

We have three mumble servers i am getting these users to test this across, the main server is 500-1000 users, linked channels and shouts that i can 100% confirm work properly across Windows Linux iOS

@soratidus999 commented on GitHub (Dec 31, 2025): Hey team, some of the user reporting this issue are ours, we've reached the limit of our troubleshooting here as my understanding was that mux-ing and routing was done server side. We have three mumble servers i am getting these users to test this across, the main server is 500-1000 users, linked channels and shouts that i can 100% confirm work properly across Windows Linux iOS

deekerman commented

2026-02-20 22:17:52 -05:00

Author

Owner

@Krzmbrzl commented on GitHub (Jan 1, 2026):

We have three mumble servers i am getting these users to test this across

Let's see what the results of those tests are. Do all of those servers share this more complex setup (linked channels, presumably ACLs, etc.) or do you also have servers that are relatively plain in terms of configuration (simply two channels so that shouts can be tested).

@Krzmbrzl commented on GitHub (Jan 1, 2026): > We have three mumble servers i am getting these users to test this across Let's see what the results of those tests are. Do all of those servers share this more complex setup (linked channels, presumably ACLs, etc.) or do you also have servers that are relatively plain in terms of configuration (simply two channels so that shouts can be tested).

deekerman commented

2026-02-20 22:17:52 -05:00

Author

Owner

@wilki2208 commented on GitHub (Jan 15, 2026):

We have three mumble servers i am getting these users to test this across

Let's see what the results of those tests are. Do all of those servers share this more complex setup (linked channels, presumably ACLs, etc.) or do you also have servers that are relatively plain in terms of configuration (simply two channels so that shouts can be tested).

I am able to replicate it every time on different servers.

Is there anything I can do as a user of a server? I am having to move to Windows to use Mumble.

@wilki2208 commented on GitHub (Jan 15, 2026): > > We have three mumble servers i am getting these users to test this across > > Let's see what the results of those tests are. Do all of those servers share this more complex setup (linked channels, presumably ACLs, etc.) or do you also have servers that are relatively plain in terms of configuration (simply two channels so that shouts can be tested). I am able to replicate it every time on different servers. Is there anything I can do as a user of a server? I am having to move to Windows to use Mumble.

deekerman commented

2026-02-20 22:17:52 -05:00

Author

Owner

@Krzmbrzl commented on GitHub (Jan 16, 2026):

Do all of those servers share this more complex setup (linked channels, presumably ACLs, etc.) or do you also have servers that are relatively plain in terms of configuration (simply two channels so that shouts can be tested).

@Krzmbrzl commented on GitHub (Jan 16, 2026): > Do all of those servers share this more complex setup (linked channels, presumably ACLs, etc.) or do you also have servers that are relatively plain in terms of configuration (simply two channels so that shouts can be tested). ^

deekerman commented

2026-02-20 22:17:52 -05:00

Author

Owner

@github-actions[bot] commented on GitHub (Jan 30, 2026):

This issue has been marked as stale, because our request for more information has thus far not been fulfilled.

If no further action occurs, this issue will be closed within 7 days.

@github-actions[bot] commented on GitHub (Jan 30, 2026): This issue has been marked as stale, because our request for more information has thus far not been fulfilled. If no further action occurs, this issue will be closed within 7 days.

deekerman commented

2026-02-20 22:17:53 -05:00

Author

Owner

@wilki2208 commented on GitHub (Feb 4, 2026):

Reopening as I have a bit more info.

So on my mac, if I have my bluetooth headphones connected (3 different types) I can't hear shouts.

If I plug my headphones in with 3.5mm, restart Mumble, I can hear shouts.

@wilki2208 commented on GitHub (Feb 4, 2026): Reopening as I have a bit more info. So on my mac, if I have my bluetooth headphones connected (3 different types) I can't hear shouts. If I plug my headphones in with 3.5mm, restart Mumble, I can hear shouts.

deekerman commented

2026-02-20 22:17:53 -05:00

Author

Owner

@Krzmbrzl commented on GitHub (Feb 19, 2026):

If I plug my headphones in with 3.5mm, restart Mumble, I can hear shouts.

Does this work consistently? And also in the other direction (unplugging the headphones and using BT to get into the non-functional state again?)

@Krzmbrzl commented on GitHub (Feb 19, 2026): > If I plug my headphones in with 3.5mm, restart Mumble, I can hear shouts. Does this work consistently? And also in the other direction (unplugging the headphones and using BT to get into the non-functional state again?)