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

[wilki2208]

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

[Krzmbrzl]

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?

[wilki2208]

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]

Yes also regular conversations are fine

[Hartmnt]

@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

[wilki2208]

@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.

[Krzmbrzl]

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?

[wilki2208]

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.

[Krzmbrzl]

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?

[soratidus999]

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

[Krzmbrzl]

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).

[wilki2208]

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.

[Krzmbrzl]

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).

^