PAD Settings app crashes on every first run (runs normally on second) - Mojave 10.14.6

[carlosfilhoadm]

Thank you so very much for this. This solves a very old annoyance in macOS that Apple refuses to address: the inability to use the built-in volume controls with external devices connected through HDMI and DisplayPort.

In my tests, I noticed a persistent bug in the PAD Settings app: it crashes on every first attempt of running it (after turning on, or rebooting, the computer). The system then displays a window containing a warning about the crash and the following crash log:

---

Exception Name: NSInvalidArgumentException
Description: *** -[__NSArrayM insertObject:atIndex:]: object cannot be nil
User Info: (null)

0 CoreFoundation 0x00007fff419602fd __exceptionPreprocess + 256
1 libobjc.A.dylib 0x00007fff6c02da17 objc_exception_throw + 48
2 CoreFoundation 0x00007fff4199f2f4 -[CFPrefsConfigurationFileSource initWithConfigurationPropertyList:containingPreferences:] + 0
3 CoreFoundation 0x00007fff4189b93c -[__NSArrayM insertObject:atIndex:] + 1216
4 AppKit 0x00007fff3f424e58 -[NSComboBoxCell insertItemWithObjectValue:atIndex:] + 105
5 Proxy Audio Device Settings 0x00000001073aa1ae Proxy Audio Device Settings + 8622
6 Proxy Audio Device Settings 0x00000001073a9bfc Proxy Audio Device Settings + 7164
7 CoreFoundation 0x00007fff41910a87 -[NSSet makeObjectsPerformSelector:] + 236
8 AppKit 0x00007fff3ee97c20 -[NSIBObjectData nibInstantiateWithOwner:options:topLevelObjects:] + 1597
9 AppKit 0x00007fff3ee95a80 loadNib + 401
10 AppKit 0x00007fff3ee94f60 +[NSBundle(NSNibLoading) _loadNibFile:nameTable:options:withZone:ownerBundle:] + 696
11 AppKit 0x00007fff3ee94ba5 -[NSBundle(NSNibLoading) loadNibNamed:owner:topLevelObjects:] + 204
12 AppKit 0x00007fff3ee94967 +[NSBundle(NSNibLoading) loadNibNamed:owner:] + 446
13 AppKit 0x00007fff3ee889d5 NSApplicationMain + 502
14 libdyld.dylib 0x00007fff6d7fb3d5 start + 1

After that first failed attempt, the app runs normally on the second one.

Please look into this bug, and please don't abandon this project. This is so useful for so many users. Unlike other solutions that may suffer with instability or high cpu consumption, this works really well.

Thank you again for the time invested into this.

[briankendall]

Thanks for the detailed crash report. I'll see if I can fix this.

[carlosfilhoadm]

OK. I really appreciate it.

[briankendall]

@carlosfilhoadm This should be fixed now in v1.0.4. Can you let me know if the fix works for you?

[carlosfilhoadm]

I'll test it and report the results.

Thanks.

[carlosfilhoadm]

@briankendall

I finally got a chance to test the latest release, and here are the results (tests were performed on Mojave 10.14.6; no other apps were running during them):

1. PAD Settings app works fine; it didn't crash at all. Thank you.

2. PAD HAL driver, however, prevents the screensaver from launching automatically (i.e. after a period of inactivity) and both display and computer from sleeping automatically.

Before copying driver and rebooting:

$> pmset -g assertions

Assertion status system-wide:
PreventUserIdleDisplaySleep 0
PreventSystemSleep 0
PreventUserIdleSystemSleep 0
Listed by owning process:
(...)

After copying driver and rebooting:

$> pmset -g assertions

Assertion status system-wide:
PreventUserIdleDisplaySleep 1
PreventSystemSleep 0
PreventUserIdleSystemSleep 1
Listed by owning process:
pid 126(coreaudiod): [0x000002250001803f] 00:09:50 PreventUserIdleSystemSleep named: "com.apple.audio.AppleHDAEngineOutputDP:3,0,1,0:0:{6D1E-59F2-01010101}.context.preventuseridlesleep"
Created for PID: 126.
pid 126(coreaudiod): [0x0000022500058040] 00:09:50 PreventUserIdleDisplaySleep named: "com.apple.audio.AppleHDAEngineOutputDP:3,0,1,0:0:{6D1E-59F2-01010101}.context.preventuseridledisplaysleep"
Created for PID: 126.
(...)

After removing the driver and rebooting again, the system acts normally.

Thank you again for working on this release.

[briankendall]

@carlosfilhoadm Sorry for taking a while to get back to you about this. This is a tricky bug to solve. It seems that as long as a process has active audio IO, it will prevent the system from sleeping. I'm investigating ways of telling CoreAudio that it shouldn't prevent the system from sleeping but haven't found anything so far.

An alternative approach is to have the proxy audio device stop engaging in audio IO when the proxied device has stopped outputting audio. The reason I don't have it do that is because there is a gap of time between when an audio device will start outputting audio and when the proxy device can receive it, causing the first 1/8th of a second or so of audio to be cut off anytime the proxied device starts outputting audio.

Alternatively I could have it stop its audio IO while the user is idle. That would fix the issue with the audio getting cut off and still allow the system to sleep, except in cases where the proxied device outputs audio while the user is idle. (e.g. the sound that plays when receiving an email or a text message).

I'm curious what you think of a solution like that.

[carlosfilhoadm]

@briankendall Thank you for trying to squash this bug; I understand you invest your free time to work on this project, so I really appreciate it.

I presume the second alternative (stop while user is idle) is easier to deal with, since I try to keep notifications to a minimum on my computer.

I still use Mojave. I wonder if Catalina would behave the same way regarding CoreAudio preventing the system to sleep?

I'm sorry I can't help more, it's just that I don't know the first thing about developing virtual device drivers.

Thank you again.

[briankendall]

@carlosfilhoadm Would you give v1.0.5 a try and let me know if it fixes the issue with your system not being able to sleep? You can choose from the proxy device will be active in the settings app.

Link: https://github.com/briankendall/proxy-audio-device/releases/tag/v1.0.5

[carlosfilhoadm]

@briankendall I'll test it and report the results.

Thanks.