mirror of
https://github.com/MonitorControl/MonitorControl.git
synced 2026-05-15 22:01:08 -06:00
[GH-ISSUE #48] Listening for volume doesn't work with non monitor output #48
Labels
No labels
Status: Abandoned
arm64
beta
beta
bug
done
duplicate
enhancement
feedback needed from reporter
in progress
invalid
investigating
known Issue
monitor Issue
pull-request
translation
unable to reproduce
unreleased
x86
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/MonitorControl#48
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @renox92 on GitHub (Sep 3, 2018).
Original GitHub issue: https://github.com/MonitorControl/MonitorControl/issues/48
Originally assigned to: @the0neyouseek on GitHub.
If I have "listen for volume" activated I can't use media keys to adjust volume of laptop's internal speakers or wireless headphones. I can still use default macos volume slider to do that. Would be great if for audio the app could check which output device is selected and then decide whether to override volume commands or not.
@gxfxyz commented on GitHub (Oct 7, 2018):
+1. It would be really helpful.
@the0neyouseek commented on GitHub (Jan 10, 2019):
Hi. Sorry I haven't been able to maintain this as much as I wanted to with work getting in the way.
Anyway, I was planning on adding support for this but if @JoniVR got it working, maybe you can make a pull request ?
I'll work on this project this week-end and probably publish a new version.
@JoniVR commented on GitHub (Jan 10, 2019):
I can do a separate PR for that if you want to, however, there were some compiling errors that require updates to those third party frameworks (was either MediaKeyTap or MASPreferences).
Anyways, I implemented it on my fork by using the
AMCoreAudioframework, if you can update the dependencies some time soonish I'll do a PR and implement this feature for you. Also, don't update the ddcctl dependency as it's current version causes a kernel freeze on macs with integrated graphics chips. I think they're working on a fix but might be useful to know not to update that dependency. (see discussion: https://github.com/kfix/ddcctl/pull/42)@JoniVR commented on GitHub (Jan 10, 2019):
Also, now that I have your attention, my guess is that #37 is related to #21, in commit 9f4e5fb an (in my opinion) unnecessary loop was introduced which slows the program down a lot (especially since ddcctl internally loops over that part of the code 10 times already), I managed to speed everything up and make it stable in my fork by simply removing that loop. The application was pretty unusable for me with it.
@the0neyouseek commented on GitHub (Jan 10, 2019):
Hi @JoniVR and thanks for all the great work and infos.
Yeah I'm pretty sure that's where the problem's coming from too. I thought being in a background thread it wouldn't be that bad when I merged it but I'll reverse it this week-end.
@JoniVR commented on GitHub (Jan 10, 2019):
Yeah, or if you could just update those peer dependencies (except for ddcctl) you forked (MAS and MediaKeyTap), that would be fine by me too, I'll do a PR with some other stuff I improved on my fork including an updated README with more screenshots (if you're up for that). It will probably also be for the weekend or afterwards as I'm currently studying for exams.
@the0neyouseek commented on GitHub (Jan 10, 2019):
I'll do just that then, thanks @JoniVR . I'll be waiting for your PR then.
Good luck with your exams 💪
@JoniVR commented on GitHub (Jan 10, 2019):
Thanks! I've written it down but please do remind me if I haven't submitted a PR by the end of next week because I might forget 😄.
@reitermarkus commented on GitHub (May 7, 2019):
This should be fixed now.