Crash after several hours

[Timmmm]

This is a really great workaround for the lack of volume support for HDMI audio. But unfortunately it seems like it is a bit buggy for me. After several hours it crashes and seems to take down lots of the audio system with it. Usually it starts crackling and then when I switch to the non-proxied HDMI audio it crashes and all of the audio devices except the Macbook built in speaker disappear or are greyed out.

Very difficult to fix I would imagine. I'm really just wondering if anyone else has the same issue?

[meejahor]

When it starts crackling or loses sync, open up the settings and change the buffer size, then change it back to whatever you want. This stops the crackling and re-syncs, without needing to close the program.

[Timmmm]

I don't it quicker just to switch audio outputs in the menu bar and then switch back, but I wish I didn't have to.

[uloco]

This happens to me several times a day. I already tried different buffer settings etc, but at some point always the music stops playing and I have to do as @meejahor pointed out: switch between buffer size to make it work again.

This is really frustrating. 😞

When I opened up this app the first time after install I thought it is not working at all because of this issue. You also have to switch the buffer size initially otherwise audio will not work.

[draxx31]

I encounter the same issue than @uloco. I am running on mbp 2023 M2 and mbp 2018 intel. Both have the same behavior.

If @briankendall needs some more information, I will be happy to share them to identify a fix.

[briankendall]

I'm pretty sure this is the same issue as #19. I haven't had much time to work on Proxy Audio Device lately, but every now and then I take a stab at trying to fix this since it's the one big flaw with the software. The problem stems from a ring buffer that's used to take audio sent into the proxy device and play it on the proxied device. For some reason the proxied and proxy devices don't read / write to the buffer at precisely the same speed, and it eventually goes too far out of sync and runs out of audio to play on the proxied device. I still haven't figured out why, though! It's inconsistent, too. It happens on some of my systems but not all, and if it happens it usually it takes hours to occur.

[Hubcapp]

I've been using proxy audio device for a few months now, with my 2020 Mac M1 mini.

Since Proxy Audio Device is the only way for me to use my hardware combination without buying new speakers that have a remote volume control, which wouldn't be as good as being able to use they keyboard controls anyway, I have tolerated this unfortunate bug. I have been using the workaround uloco posted, of just switching the buffer size as needed.

I switch from 1024 to 2048 & vice versa, whenever I come back to the mac from being afk & sometimes it's needed if it has been like 5 hours. It is a habit for me to do this even if audio is playing, because there is usually like 1 or 2 second lag on the audio, desyncing from video, even if audio hasn't completely crapped out.

I figured it's been a few months, maybe there's a software update by now, and yeah, the timing on the status update above was a surprising coincidence.

I don't have the skill to fix this bug properly, but I think a more-acceptable workaround for me will be to compile my own version that just reinitializes the buffer periodically automatically. It's not the correct fix since it will, once every 3 hours or so, cause the audio to cut out briefly & possibly correcting a desync which would result in missing a second or so of audio, but doing it automatically is better than having to manually detect that there is an issue and manually correcting it by bringing up the Proxy Audio Device Settings.

You should maybe consider deploying this crude workaround in 1.0.7 if it's not possible to fix the issue properly soon, as an opt-in toggle "🔳 Periodically refresh audio buffer".

[danVnest]

I've recently set this up to control sound from my Macbook and external display simultaneously. It works well until the sound cuts out suddenly. As stated above I expect this is the same as issue https://github.com/briankendall/proxy-audio-device/issues/19. Perhaps unrelated but I also experience the popping issue: https://github.com/briankendall/proxy-audio-device/issues/39.

I figured I'd add my notes here in case it helps. Sound usually cuts out every few minutes, but sometimes lasts for hours without issue. This doesn't seem to correlate with system usage or anything else I could notice. Once the sound cuts out, it doesn't come back unless I try one (or more, it's not consistent!) of the following:

• pause music or other source for 1-10 seconds then play again
• switch to a different output device in system settings - sound, then back again
• switch buffer size

Because this happens so frequently I've been able to capture several console logs. The following seems to be the key component that occurs every time the sound stops:

log

``` default 13:59:37.038255+1100 com.apple.audio.Core-Audio-Driver-Service HALC_ProxyIOContext.cpp:3011 HALC_IOContext_PauseIO(885) default 13:59:37.038335+1100 com.apple.audio.Core-Audio-Driver-Service HALC_ProxyIOContext.cpp:3045 HALC_IOContext_ResumeIO(885) default 13:59:37.038345+1100 com.apple.audio.Core-Audio-Driver-Service HALC_ProxyIOContext.cpp:955 HALC_ProxyIOContext::PauseIO: -> 0 0 0, id:885 called from default 13:59:37.038399+1100 com.apple.audio.Core-Audio-Driver-Service HALC_ProxyIOContext.cpp:968 HALC_ProxyIOContext::PauseIO: <- 0 1 1, id:885 called from default 13:59:37.038464+1100 com.apple.audio.Core-Audio-Driver-Service HALC_ProxyIOContext.cpp:1002 HALC_ProxyIOContext::ResumeIO: -> 0 1 1 id:885 called from default 13:59:37.038511+1100 com.apple.audio.Core-Audio-Driver-Service HALC_ProxyIOContext.cpp:1018 HALC_ProxyIOContext::ResumeIO: <- 0 0 0 id:885 called from default 13:59:37.050586+1100 com.apple.audio.Core-Audio-Driver-Service ProxyAudio: devicesListenerProc current devices changed default 13:59:37.050654+1100 com.apple.audio.Core-Audio-Driver-Service ProxyAudio: setupTargetOutputDevice default 13:59:37.050730+1100 com.apple.audio.Core-Audio-Driver-Service ProxyAudio: findTargetOutputAudioDevice default 13:59:37.050796+1100 com.apple.audio.Core-Audio-Driver-Service ProxyAudio: findTargetOutputAudioDevice target UID: ~:AMS2_StackedOutput:0 default 13:59:37.050873+1100 com.apple.audio.Core-Audio-Driver-Service ProxyAudio: findTargetOutputAudioDevice finished, found output device default 13:59:37.052156+1100 com.apple.audio.Core-Audio-Driver-Service ProxyAudio: setupTargetOutputDevice newOutputDevice: 56 default 13:59:37.053634+1100 com.apple.audio.Core-Audio-Driver-Service ProxyAudio: setupTargetOutputDevice no change in device default 13:59:37.066224+1100 com.apple.audio.Core-Audio-Driver-Service ProxyAudio: received signal, will return data on next call to box name: 1 default 13:59:37.896534+1100 com.apple.audio.Core-Audio-Driver-Service [0x7fd5af107d50] activating connection: mach=true listener=false peer=false name=com.apple.tccd default 13:59:37.897066+1100 com.apple.audio.Core-Audio-Driver-Service [0x7fd5af107d50] failed to do a bootstrap look-up: xpc_error=[3: No such process] default 13:59:37.897192+1100 com.apple.audio.Core-Audio-Driver-Service [0x7fd5af107d50] invalidated after a failed init default 13:59:37.897716+1100 com.apple.audio.Core-Audio-Driver-Service HALC_ProxyIOContext.cpp:3011 HALC_IOContext_PauseIO(604) default 13:59:38.127863+1100 runningboardd Process: [xpcservice:30658])(202)>:30696:30696] has changes in inheritances: (null) default 13:59:38.128458+1100 runningboardd [xpcservice:30658])(202)>:30696:30696] Ignoring jetsam update because this process is not memory-managed default 13:59:38.130152+1100 runningboardd [xpcservice:30658])(202)>:30696:30696] Ignoring suspend because this process is not lifecycle managed default 13:59:38.130219+1100 runningboardd [xpcservice:30658])(202)>:30696:30696] Ignoring role changes because this process is not role managed default 13:59:38.130307+1100 runningboardd Acquiring assertion targeting [xpcservice:30658])(202)>:30696:30696] from originator [xpcservice:30658])(202)>:30696:30696] with description ]> default 13:59:38.130748+1100 runningboardd [xpcservice:30658])(202)>:30696:30696] Ignoring GPU update because this process is not GPU managed default 13:59:38.133481+1100 runningboardd Assertion 194-30696-49451 (target:[xpcservice:30658])(202)>:30696:30696]) will be created as active default 13:59:38.164108+1100 runningboardd Acquiring assertion targeting [xpcservice:30658])(202)>:30696:30696] from originator [osservice:122] with description , ]> ```

Happy to provide more info (e.g. system specs, config, etc.) if you think it will help.

I would also be curious to see if Hubcapp's solution above prevents this issue.

[Hubcapp]

Hey @danVnest, I don't have the same behaviour as you, it always stays good for several hours, and switching the buffer size always fixes it.

I did make good on my threat to implement a crude work-around locally, and I can say these things:

1. Refreshing the buffer does not introduce an audible "cut-out", it's just fine, and even when I had it spamming buffer changes continuously (more than once per second), it was not perceptible, so it should probably just be done by default without a tickbox being necessary.
2. Although performing the action of changing buffer size manually does fix the problem for me, for some reason it has no effect when I implemented it as an automatic action. It still breaks after a few hours, even though I had console output & could see my code running the "switch buffer size" function.

I think I would have to get into the actual driver code instead of just the frontend in order to make any more progress, but haven't had time to dig into it. For now, I am still coping the same as everyone else following this issue, by just manually changing buffer size after any long break using the computer.