New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix flickering OSD and refactor logic for volume slider. #152
Conversation
if !isAlreadySet { | ||
guard self.ddc?.write(command: .audioSpeakerVolume, value: volumeDDCValue) == true else { | ||
return | ||
DispatchQueue.global(qos: .userInitiated).async { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will undo the performance improvements for repeated and held-down media key volume commands made by executing the set volume DDC command on the main thread (per my initial analysis in #134).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you saying we should be using DispatchQueue.main
instead of DispatchQueue.global(qos: .userInitiated)
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The DDC write command is already being run on the main thread, so you shouldn't need to enclose this in a DispatchQueue
block at all, unless you're running the setVolume
method from a background thread.
I'm happy to test out this PR and tinker with it as well to see if there's any regression in performance from this change though - my monitor at work has an OSD that behaves in a similar way to yours, but my home one doesn't, so I only have limited opportunities to test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you shouldn't need to enclose this
Doesn't hurt to be explicit, especially since in this case it is critical where it is run.
I'm happy to test out this PR
Please do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can confirm this returns the Osd hiding on my display back to previous behaviour.
One problem I noticed during testing:
When I mute and then unmute, volume is not being restored to the previous value (before muting) with these changes.
You're right, same for me. I'll look into it. |
Should be fixed. |
Also, @ScorpionDev, I just tried switching from |
Was there any development on this PR? Currently facing the same issue. |
Closing this as it looks pretty abandoned, feel free to reopen :) |
This fixes the flickering/hiding of the display's OSD by readding
errorRecoveryWaitTime: self.hideOsd ? 0 : nil
which was removed.Also, the volume slider now behaves the same way as the native macOS volume slider: It will only change the volume after a mouse-up event and it will also play the volume-changed sound.