[GH-ISSUE #176] Control volume of selected output device regardless of focussed display #128

New issue

Closed

opened 2026-05-05 05:13:03 -06:00 by gitea-mirror · 5 comments

gitea-mirror commented

2026-05-05 05:13:03 -06:00

Owner

Originally created by @tbrodbeck on GitHub (Feb 2, 2020).
Original GitHub issue: https://github.com/MonitorControl/MonitorControl/issues/176

Hey, as an feature request, it would be awesome to be able to only have one output device that can be controlled when focussing any screen.
Usually you do not use your monitor and your local speaker both at the same time, right?

Originally created by @tbrodbeck on GitHub (Feb 2, 2020). Original GitHub issue: https://github.com/MonitorControl/MonitorControl/issues/176 Hey, as an feature request, it would be awesome to be able to only have one output device that can be controlled when focussing any screen. Usually you do not use your monitor and your local speaker both at the same time, right?

gitea-mirror closed this issue

2026-05-05 05:13:05 -06:00

gitea-mirror commented

2026-05-05 05:13:12 -06:00

Author

Owner

@JoniVR commented on GitHub (Apr 3, 2020):

You mean that it tries to control the volume of the internal display when it's in focus even though the output is set to the external one? I agree in that case!

@JoniVR commented on GitHub (Apr 3, 2020): You mean that it tries to control the volume of the internal display when it's in focus even though the output is set to the external one? I agree in that case!

gitea-mirror commented

2026-05-05 05:13:16 -06:00

Author

Owner

@mischkl commented on GitHub (Apr 8, 2020):

You mean that it tries to control the volume of the internal display when it's in focus even though the output is set to the external one? I agree in that case!

@JoniVR Are you saying you agree that this behavior is wrong, or you think it should behave this way? If you're saying it's correct that it attempts to adjust internal volume when the internal screen is focused, I don't think that's what the issue author meant.

Normally there is just one sound output at a given time, and that's by design - if I connect my Mac to an external device that supports audio, and switch my output device in the Mac audio menulet to that external device, then it means I want all audio routed through that device.

As an example, I have external speakers hooked up to my monitor, so I can just plug in my Mac with a single cable and audio is routed to the external speakers. If I play a YouTube video on my internal screen, I still want the audio to be routed to the external speakers. And I want to be able to set the volume on the external speakers via the volume keys, regardless of the fact that the internal screen is currently focused.

I just got a new monitor and set it up this way, and this app seems like a godsend at first glance - however this particular "feature/bug" keeps it from acting the way I want and expect. IMHO it should get a much higher priority.

@mischkl commented on GitHub (Apr 8, 2020): > You mean that it tries to control the volume of the internal display when it's in focus even though the output is set to the external one? I agree in that case! @JoniVR Are you saying you agree that this behavior is wrong, or you think it should behave this way? If you're saying it's correct that it attempts to adjust internal volume when the internal screen is focused, I don't think that's what the issue author meant. Normally there is just one sound output at a given time, and that's by design - if I connect my Mac to an external device that supports audio, and switch my output device in the Mac audio menulet to that external device, then it means I want all audio routed through that device. As an example, I have external speakers hooked up to my monitor, so I can just plug in my Mac with a single cable and audio is routed to the external speakers. If I play a YouTube video on my internal screen, I still want the audio to be routed to the external speakers. And I want to be able to set the volume on the external speakers via the volume keys, regardless of the fact that the internal screen is currently focused. I just got a new monitor and set it up this way, and this app seems like a godsend at first glance - however this particular "feature/bug" keeps it from acting the way I want and expect. IMHO it should get a much higher priority.

gitea-mirror commented

2026-05-05 05:13:24 -06:00

Author

Owner

@JoniVR commented on GitHub (Apr 8, 2020):

I think I understand what you mean and that's what I meant too.

Currently, when you select your internal display it ignores the selected output because the internal display is "focussed". I think this is pretty easily fixed though, I just need to find some time to look into it (and a whole range of other stuff in this project lol)

@JoniVR commented on GitHub (Apr 8, 2020): I think I understand what you mean and that's what I meant too. Currently, when you select your internal display it ignores the selected output because the internal display is "focussed". I think this is pretty easily fixed though, I just need to find some time to look into it (and a whole range of other stuff in this project lol)

gitea-mirror commented

2026-05-05 05:13:27 -06:00

Author

Owner

@mischkl commented on GitHub (Jun 9, 2020):

Any chance this will make it into the next release?

@mischkl commented on GitHub (Jun 9, 2020): Any chance this will make it into the next release?

gitea-mirror commented

2026-05-05 05:13:30 -06:00

Author

Owner

@JoniVR commented on GitHub (Jun 9, 2020):

There’s a similar issue that’s probably related to this. I haven’t had the time to look into it and I can’t promise you a timeline either. Anyone is free to implement it though. If not I’ll try to get around it eventually.

@JoniVR commented on GitHub (Jun 9, 2020): There’s a similar issue that’s probably related to this. I haven’t had the time to look into it and I can’t promise you a timeline either. Anyone is free to implement it though. If not I’ll try to get around it eventually.