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.)
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.
I don't know why I put them in the Preferences menu initially. This is
more convenient.
Closes#170.
Also:
- Update the output device menu items as needed instead of when the
user opens the menu. This saves a bit of CPU time and means if the
user has the menu open, changes are made when they're needed instead
of the next time the user opens the menu.
- Fix BGMAppUITests::testCycleOutputDevices for the latest Xcode/macOS.
There's still some code left that should be moved into the new class,
BGMBackgroundMusicDevice, but I think this is most of it.
This also helps reduce/contain the code that has to be aware of the
second instance of BGMDevice, which handles UI-related audio.
BGMApp now disables BGMDevice's volume and/or mute controls if the
output device selected in BGMApp doesn't have matching controls. This
prevents the controls from being presented to the user when they don't
do anything.
In BGMPlayThrough, wait much longer for our IOProcs to stop themselves
before assuming something's gone wrong. In testing, rapidly changing
between output devices with and without controls while playing audio
would occasionally cause one of the IOProcs to take too long to stop
itself.
Also adds some basic scriptability, mainly so UI tests can use
AppleScript to check BGMApp's state that would be complicated to check
otherwise. (In this case, to check which output device is selected.)
Fixes#101.
Skipping them by overriding runTest didn't work and this is the only other way
I can think of. xcodebuild's -skip-testing option would work, but only with
recent versions of Xcode.
The UI tests run with clean user defaults, but BGMDevice and Scripting Bridge
still need to be mocked/stubbed out. That also means that the UI tests can only
run if BGMDriver is installed and that changes to BGMDriver's state made during
the tests will persist.
And other reliability improvements. Mostly in BGMPlayThrough and the
classes that use it. Trying to catch C++ exceptions as early as possible
in the Objective-C++ code and, if necessary, convert them to NSErrors.
More errors are logged in release builds now, which will hopefully help
with debugging issues the developers can't reproduce themselves.
- Destroy the Scripting Bridge application object for a music player
when that music player isn't running.
- Move the UI code for the auto-pause menu item into its own class.
- Add a User Defaults class to BGMApp.
- Enable some more warnings for the BGMApp project.
The BGMApp project now builds an XPC service bundle called BGMXPCHelper,
which vends a Mach service that BGMApp and BGMDriver can use to
communicate. This will hopefully be useful for some of the tasks HAL
notifications aren't suited to.
In this commit, BGMDriver uses the XPC helper when starting IO, to wait
until BGMApp is ready for playthrough. BGMApp can only start playthrough
when the output hardware is ready for IO. BGMDriver can now tell the HAL
when we're ready for IO, which means we don't have to keep the output
hardware running all the time (or drop frames or increase latency).
The end result is that playthrough doesn't waste CPU time while idle any
more. This also means that now playthrough won't prevent the system from
sleeping when idle.
