`brew cask install` appears to be deprecated, and using it gets this warning:
```Warning: Calling brew cask install is deprecated! Use brew install
[--cask] instead.```
So this is a super small change in README to reflect that.
This works similarly to the workaround in the previous commit, but
avoids the short wait while XPC times out. It still allows some initial
frames to be dropped when IO starts.
See #328, #388 and PR #390.
The path to the built BGMXPCHelper bundle was missing from package.sh,
so it wasn't including that bundle in the .pkg it created. Then the .pkg
would fail when you tried to install it.
Add NSSupportsAutomaticGraphicsSwitching to BGMApp's Info.plist in the
hopes that it will use the integrated GPU when possible. BGMApp doesn't
need to use the fastest GPU, so it's better to save battery power.
Untested because I don't have the right hardware. (I actually have an
iMac with a discrete GPU, but the integrated GPU seems to be disabled.)
See #284 and
<https://developer.apple.com/library/archive/qa/qa1734/_index.html>.
A macOS bug was stopping BGMXPCHelper from running, which would stop
BGMDevice from starting IO. It would wait in StartIO until timing out.
I'm not sure why that didn't cause BGMDriver's XPC connection fail. If
it had, BGMDevice would have just started IO without waiting for BGMApp
to be ready. The it would have just dropped some initial frames and
logged an error instead of freezing for 30 seconds.
The fix/workaround is to delete the old version of BGMXPCHelper before
installing the new one.
Issue #276 reported a segfault that occurred while BGMApp was launching.
It was caused by BGM_PlayThrough's output IOProc when it tried to read
from the ring buffer. I haven't been able to reproduce the problem, so I
don't know whether this commit will actually fix it. Hopefully it will
at least make it easier to diagnose.
This commit adds locking around accesses to the buffer so that the
IOProcs will skip the current IO cycle if it isn't safe to use the ring
buffer. That should only happen during launch or when changing the
output device. (And only if something else has gone wrong.)
It takes an expanded Background Music .pkg installer and repackages it
into a new .pkg installer. It's mainly useful for code signing, since
you have to expand the unsigned package, sign each of the bundles,
repackage it and then sign the new package.
Also, fix build_and_install.sh putting the BGMXPCHelper dSYMs in the
wrong archive.
Archiving is the standard way to build a release for distribution using
Xcode. package.sh now uses this option when it creates a release
package.
This change is mainly to keep the Run settings in the Xcode schemes from
affecting the release builds, which means we can commit the schemes with
more sensible settings.
Also, disable AddressSanitizer in the BGMDevice scheme, which was
stopping coreaudiod from launching because its sandbox won't allow the
process to load the AddressSanitizer dylib.
Clicking the status bar icon with the option key held now reveals a
setting that enables debug logging in BGMApp. It's enabled by default in
debug builds.
It doesn't enable debug logging in BGMDriver or BGMXPCHelper yet.
This will hopefully make it easier for people to include logs when they
report bugs that don't occur with most hardware or are otherwise hard to
reproduce.
Enabling debug logging should be unlikely to cause audio glitches, but I
haven't tried to make it completely safe.
Also,
- add some basic unit tests for BGMPlayThrough and expand the mocks for
the CoreAudio HAL API,
- fix the UI tests so you can run them without code signing them, and
- update copyright years.
It was using the copy in the BGMApp project, but for historical reasons
they both have a separate copy of the PublicUtility classes. We haven't
gotten around to combining them yet, so this commit is to keep them
consistent until we do.
Also, some minor clean up in BGMDriver related to #218.
