Skip to content
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

SystemAudioVolume not working in Yosemite #517

Open
OmeGak opened this issue Mar 26, 2015 · 7 comments

Comments

@OmeGak
Copy link

commented Mar 26, 2015

Disabling the startup chime has stopped working with Yosemite, I'm afraid. Or at least I can't make it work.

Running sudo nvram SystemAudioVolume=" " works as expected since the new value is reflected in sudo nvram -p. However, upon reboot, the startup chime comes to greet me as usual.

Running sudo nvram -p afterwards shows that the value has gone back to the default L, so it would seem as if Yosemite resets the value to its default on reboot and before the chime, so the change is never made effective.

I've found this question in AskDifferent, but they haven't concluded anything. Maybe somebody here faced the same problem with better luck?

@xinput

This comment has been minimized.

Copy link

commented Mar 27, 2015

try to use sudo nvram SystemAudioVolume=%00 instead.

this worked for me.

@Tatsh

This comment has been minimized.

Copy link

commented Mar 27, 2015

Maybe you already know this: ultimately this sound is supposed to be a better alternative to the old 'successful POST' beep that PCs would make (I still have a system that does that when the speaker is plugged in to the motherboard). It represents a successful startup.

I agree it is very annoying, especially out in public when your system blasts it based on the last volume you had enabled, and not even headphones stop it.

I don't know why but I feel like this could be model specific and not necessarily a hard set value for all machines, or there just is not a way. So if some are saying that some value works, ask exactly what kind of Mac they have. I have a Mac Pro 2014 and 2 MacBook Pros (one 2012, one 2014), and the value being a single space has not worked consistently. %00 not sure yet (used to use this with a 2012 MacBook Air and it seemed to work). And like the post you linked to, many of the existing packages like StartNinja have not worked for me especially since Yosemite.

@OmeGak

This comment has been minimized.

Copy link
Author

commented Mar 28, 2015

sudo nvram SystemAudioVolume=%00 did finally work for me, but only the first time I reboot after running it. Then, the value is restored back to [ and the chime comes back thereafter. My laptop is MacBook Pro 2012.

@xinput

This comment has been minimized.

Copy link

commented Mar 28, 2015

@OmeGak another idea would be to write a .plist and store it in /Library/LaunchDaemons which runs the command on every Boot.

it should look like this:
<plist version="1.0"> <dict> <key>ProgramArguments</key> <array> <string>/usr/sbin/nvram</string> <string>SystemAudioVolume</string> <string>%00</string> </array> <key>RunAtLoad</key> <true/> </dict> </plist>

i'm not sure if this will work, you have to test it.

@sirkkalap

This comment has been minimized.

Copy link

commented Apr 8, 2015

In many cases I have set up my boot up volume manually by:

  1. Unplug all external soundcards and headphones.
  2. Log out to login screen.
  3. Adjust the volume to your liking. That volume will be your boot up volume.

Just to clarify that setting the volume is by no means a quirck, it is there by design.

@mirfilip

This comment has been minimized.

Copy link

commented May 17, 2015

While distilling my own dotfiles I also stumbled upon this problem. As I base mine on @mathiasbynens's, I will share the result of my research here.

  • @xinput Unfortunately, adding plist with such settings does not solve the problem, even if I add <string>SystemAudioVolumeDB</string> <string>%00</string> to array of options. Of course, tried with different options: " ", %00, %80, %01 and couple of more.
  • doing sudo nvram SystemAudioVolumeDB="<option_here>", where <option_here> are the values used in point above, returns success, I can verify it by running sudo nvram -p | grep SystemAudioVolume
  • Setting both SystemAudioVolume and SystemAudioVolumeDB with any of the value does not mute the chime

My MBP is MacBook Pro i7, MBP112.0138.B14, currently Yosemite OS X 10.10.3 (14D136) but it didn't work with Mavericks too.

There is a less-than-perfect option to use some "auto mute" 3rd party software that would automatically mute the sound before logout / restart / shutdown event. Yeah, you still need to enable the sound after booting but it's better than annoying everyone if the office.

Edit: One more tip. After using AuteMute software, after reboot I can see it set the following values:

sudo nvram -p | grep SystemAudioVolume
SystemAudioVolumeDB 0
SystemAudioVolume   %dd

When I disable AutoMute and set such values myself, it doesn't work. After restart it's overwritten:

sudo nvram -p | grep SystemAudioVolume
SystemAudioVolumeDB %f5
SystemAudioVolume   ]

My conclusion is, it's not the matter of values, there is some mechanism that overwrites the settings.

@rs38

This comment has been minimized.

Copy link

commented Apr 21, 2016

any updates on this?

dndhm pushed a commit to dndhm/dotfiles that referenced this issue Nov 26, 2017

Don't rely on Bash in post-up hook
In 16219a3 we implemented a post-up
hook that checked for a problematic `/etc/zshenv` file. OSX/macOS has
changed the file responsible for executing `path_helper` and loading the
system paths multiple times, and this script change issued a warning to
users if `path_helper` might be called in such a way that their paths
could be unexpectedly reordered.

The script used colored output to highlight this problem for the user,
and relied on Bash's script path introspection (through `$BASH_SOURCE`)
to print the location of the `post-up` hook to assist the user in
troubleshooting and understanding where our warning came from.

This change removes the hook's reliance on GNU Bash in favor of `sh`. It
uses the POSIX-compliant `$0` to determine the hook location (this
method is less robust than Bash's `$BASH_SOURCE`, but is available in
all POSIX shells) and removes colored output in the warning to be
compatible with shells that don't support colored output.

Fix mathiasbynens#517.

veySky pushed a commit to veySky/dotfiles that referenced this issue Feb 18, 2019

Don't rely on Bash in post-up hook
In 16219a3 we implemented a post-up
hook that checked for a problematic `/etc/zshenv` file. OSX/macOS has
changed the file responsible for executing `path_helper` and loading the
system paths multiple times, and this script change issued a warning to
users if `path_helper` might be called in such a way that their paths
could be unexpectedly reordered.

The script used colored output to highlight this problem for the user,
and relied on Bash's script path introspection (through `$BASH_SOURCE`)
to print the location of the `post-up` hook to assist the user in
troubleshooting and understanding where our warning came from.

This change removes the hook's reliance on GNU Bash in favor of `sh`. It
uses the POSIX-compliant `$0` to determine the hook location (this
method is less robust than Bash's `$BASH_SOURCE`, but is available in
all POSIX shells) and removes colored output in the warning to be
compatible with shells that don't support colored output.

Fix mathiasbynens#517.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.