This is mostly so BGMApp won't leave BGMDevice as the default if BGMApp
crashes, which would stop audio from playing until the user changed the
default device themselves. Also handles SIGINT, SIGTERM and SIGQUIT.
For crashes where the BGMApp process may be in an unknown state, e.g.
segfaults, BGMXPCHelper handles changing the default device.
Should fix the Travis Xcode 9 build, which is currently failing because
the AppleScript we use to quit BGMApp in .travis.yml gets "user
cancelled" for some reason.
Also makes some minor improvements to the reports generated by
CrashReporter. The way CrashReporter works with Background Music should
otherwise be unchanged.
Specifically, apps with NSApplicationActivationPolicyAccessory. That
includes status bar apps like Background Music, but also includes some
that aren't intended to be shown to users as applications like
SystemUIServer.
I'm not sure how much we can do about that. It would probably help if we
hid apps that BGMDriver isn't able to match to a CoreAudio client.
Resolves#122.
If the bundle ID passed to the function (a CACFString) was wrapping a
null CFStringRef, one of the comparison operator functions of CACFString
would pass null to CFStringCompare.
Similar to the one in macOS's Volume menu extra.
I'm mainly adding it so we can increase the output volume when the user
sets an app volume above 50%. Currently, setting an app volume above 50%
(the default) risks clipping, so it doesn't make sense to do so unless
your main output volume is at its max.
The volume slider added in this commit will make it clear to the user
that their main output volume is also increasing.
The other app volumes won't change, so in the ideal case the user
wouldn't need to be aware that their output device's volume is being
changed. But they might play audio to the device directly and would
expect it to play at the same volume as before they changed the app
volume.
Fix the workaround for apps whose bundle IDs don't match their CoreAudio
clients. BGMBackgroundMusicDevice::ResponsibleBundleIDsOf was always
returning an empty list.
Also fix over-releasing the app's bundle ID CFString in
BGMAVM_VolumeSlider::appVolumeChanged and
BGMAVM_PanSlider::appPanPositionChanged.
Both bugs were introduced two commits ago in
e05acde351.
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.
On macOS, apps are supposed to play UI-related sounds using the "system
default" device. This commit creates a new instance of BGM_Driver, which
BGMApp sets as the system default device. BGMApp ignores audio played to
that device when deciding whether to pause/unpause the user's music
player.
Since UI sounds are short, this helps avoid pausing the music player and
unpausing it shortly after.
Some apps have different bundle IDs to their CoreAudio clients, so
the bundle ID BGMApp sends with the app's volume doesn't match any
client in BGMDriver.
This change hardcodes the bundle IDs used by some popular apps and the
bundle IDs their clients use. We should be able to fix this for all
(almost all?) apps at some point.
It turns out that the HAL will sometimes call BGM_Driver::StartIO before
sending kAudioDevicePropertyDeviceIsRunning to BGMPlayThrough. In that
case, BGMApp would start playthrough and tell BGMDriver to return from
StartIO immediately, which meant we would drop the initial frames while
the output device started up.
So now BGMApp waits for the output device in that case as well.
Fixes#7.
The non-interactive version can be called by a Homebrew Cask formula.
Also, change some AppleScript to reference applications by their IDs
rather than their names, which should make them slightly more robust.
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.
Also add centre tick marks and "L"/"R" (left/right) labels to them.
The idea is to eventually include extra controls like an equalizer, recording
apps, hiding/ignoring apps, routing apps, etc.
Also, remove the left margin from the App Volumes menu items. Even macOS isn't
consistent about including that margin, as far as I can tell.
BGM_Device::StartIO blocks on
BGMAudioDeviceManager::waitForOutputDeviceToStart, which could be blocked by
HAL requests that the HAL wouldn't return until BGM_Device::StartIO returned.
Also:
- Replace BGMPlayThrough's move constructor with a SetDevices function for
simplicity.
- Pause/abort debug builds if an error is logged.
Also, default to only aborting debug builds when they log and swallow an
exception if the exception was unexpected. That is, the developer didn't
realise the code could throw.
This reverts commit a4160d370d.
I've tested the icon bug on a couple of other machines now and haven't been
able to reproduce it. My "fix" did cause the bug on those machines, though,
despite fixing it on mine. Still not sure exactly what's going on, but it seems
to be a problem with my development environment.
We only unpause the music player, after auto-pausing it, if it's been
paused for longer than some minimum length of time. This commit reduces
that time if the music player hasn't been paused for long.
In BGMApp, messages logged with the DebugMsg macro now go to syslog
instead of stdout.
People running standalone BGMApp debug builds (i.e. not in Xcode) should
be able the find the debug logs more easily. Xcode still shows the debug
logs normally when running BGMApp in Xcode.
Also, debug symbols (the .dSYM directory) are now included in the
Background Music.app bundle. (In both debug and release builds.)
CrashReporter is able to find these and use them to symbolicate BGMApp
crash logs.
The names of the data source(s) for a device are generally the names
intended to be shown to the user, since the OS X volume menu, System
Preferences, etc. use them.
A menu item is now added for each data source of each output device,
rather than one per device.
Also adds some macros/functions for casting values to __nonnull.
Resolves#59.
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.
Link to the project website (GitHub) in the About Background Music
window, and move its code into its own class.
Also, update the copyright notices in the UI and README.
- 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.
Instead of disabling the menu item when the music player isn't running,
just make it appear disabled. That way you can always disable auto-pause
without having to open your music player, but the UI still indicates
when it thinks the music player isn't running.
BGM_Device::StartIO was holding the state mutex longer than it needed
to, which meant HasProperty, GetProperty, etc. couldn't return. If
BGMPlayThrough was notified about IO starting after StartIO locked the
mutex, BGMPlayThrough would get stuck trying to get one of BGMDevice's
properties.
Fixes#46.
BGMApp is failing to build for some people with the Clang error message
"Could not read profile: Unsupported profiling format version". See #4.
I think this might be caused by building with an older version of Xcode,
but I'm far from sure about that. BGMApp uses <0.5% CPU, so it's not
worth using an optimization profile if it's causing anyone problems.
BGMXPCHelper's install script now creates a user and group for
BGMXPCHelper to run as. This reduces the risk of BGMXPCHelper being used
for privilege escalation.
The "install" action for BGMXPCHelper now checks the owner/permissions
of the installation directory. It also installs BGMXPCHelper's
launchd.plist and "bootstraps" it.
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.
The listener proc in BGMDeviceControlSync was being triggered during the
initial CopyVolume call. This fix just waits until after the initial
sync to register the listener proc.
