Open SCdF opened 7 years ago
+1
Would love to see this fixed as well. I switched from using an AppleScript that does the same thing to using this program because it is so much faster.
Another workaround using Applescript (more like a replacement, sadly, requires 'Show volume in menu bar' to be enabled):
tell application "System Events"
tell process "SystemUIServer"
click (menu bar item 1 of menu bar 1 whose description contains "volume")
click menu item "Your Device Name" of menu 1 of result
end tell
end tell
Another workaround using Applescript (more like a replacement, sadly, requires 'Show volume in menu bar' to be enabled):
tell application "System Events" tell process "SystemUIServer" click (menu bar item 1 of menu bar 1 whose description contains "volume") click menu item "Your Device Name" of menu 1 of result end tell end tell
wow excellent. i am able to use it together with switchaudio-osx to get what i want. But there is a small problem. After running your script, the volume menu dialog stays open, showing all the output sources. How do I close it using the apple script? I tried clicking the menu bar again but it doesn't work.
Any ideas? Thank you so much.
@jumban It shouldn't stay open as the script does the exact same thing as a user clicking on the UI. Did you change it to your desired device name to suit your usage?
@jumban It shouldn't stay open as the script does the exact same thing as a user clicking on the UI. Did you change it to your desired device name to suit your usage?
I chained it to the end of the switchaudio-osx workflow, replacing the desired device name with Alfred's "{query}". I think I found the reason why the dialog box stays open. It seems that the script did not successfully select the output device, and I'm not sure why.
I see this issue got closed, but I'm still seeing the behavior originally described. Any chance for a fix? I'm actually using the first apple script workaround suggested (in an alfred workflow), but would love to remove that dependency. Thanks for a useful utility!
I see in https://github.com/deweller/switchaudio-osx/issues/39#issuecomment-1485446061 that this issue remains.
It is definitely unexpected behavior that changing the output device changes the system device. And for me, it is fairly random as to what it switches to.
I'm relatively certain this is not caused by the SwithAudio code - but rather this is a quirk of Apple's CoreAudio APIs that I don't fully understand.
The only fix I can think of is to remember what the system output was set to - and then re-set it after changing the output device.
I'll have to check if the CoreAudio APIs even have the capability to set to "selected sound output device". It does feel like a hack but it might be the only way.
@jumban Thanks for posting the script, but on Monterey, I get "System Events got an error: Can’t get menu bar item 1 of menu bar 1 of process "SystemUIServer" whose description contains "volume". Invalid index." when running it.
Do I need to change something for more recent versions of macOS?
I think this is a bug in SwitchAudioSource
I came up with the following AppleScript for macOS Sonoma (14). You would just need to change the labels to your OS language.
tell application "System Settings"
# You can comment the following line if you don't want the app to show up, however,
# the menu selection will still show up even when the app is not being shown
activate
reveal pane id "com.apple.Sound-Settings.extension"
end tell
delay 1
tell application "System Events"
tell process "System Settings"
set target to pop up button "Reproducir efectos a través de" of group 1 of scroll area 1 of group 1 of group 2 of splitter group 1 of group 1 of window 1
click target
click menu item "Dispositivo de salida de sonido elegido" of menu 1 of target
end tell
end tell
quit application "System Settings"
The Dell monitor being DisplayPort.
This only happens if you have it set to follow audio devices. If play sound effects is set to a specific output device it will never move.