[Bug] Haven Desktop - Per-application audio user aborted request exception

[ohmygdala]

First off, awesome work! I wanted to sincerely thank you for all the effort put into this project.
Recently discovered this issue while testing out haven:

System Info / App Versions

Haven Desktop: 1.1.4 (also reproduced on 1.1.3)
Haven Web-App / Server: 2.7.6 (also reproduced on 2.7.5)
OS: Microsoft Windows 11 Pro
OS Build: 10.0.26200 Build 26200

Summary

When streaming an application window and selecting a per-application audio source in Haven Desktop 1.1.4, a warning pop-up will display with the following message:
"Screen sharing started (no audio - enable it in the browser picker)"

It looks like the info message gets returned here:

Haven/public/js/modules/app-voice.js

Line 215 in 31dc921

this._showToast('Screen sharing started (no audio — enable it in the browser picker)', 'info');

Steps to reproduce

1. On Haven Desktop, join voice channel and start a screen share.
2. Select an application window.
3. Under application audio, choose a source other than system audio.

Screenshots

If / when you get an opportunity, any thoughts? Let me know if there's any more information I can provide.

Note:
Initially opened an issue on the haven-desktop repo:
ancsemi/Haven-Desktop#13

But after some light digging, it seems like the problem is server side and I thought it might make more sense to open an issue here. If not, apologies, let me know and I can close this out / re-open on the desktop repo.

[ancsemi]

Thanks for the detailed report and for digging into the code! Found the root cause: two state variables (_capturedAudioPid and _audioBufferQueue) were never properly declared in the preload script. When the audio pipeline tries to build, it hits a ReferenceError flushing the buffer queue, which gets caught silently. The per-app audio track is never created, so voice.js sees zero audio tracks and shows the "no audio" toast.

Fix is going out soon.

[ohmygdala]

Awesome, thanks for the quick response on this! I can test out the new build whenever available. Planned on testing the fixes introduced in 2.7.8 so I'll let you know how that goes.

[ancsemi]

The fix for the per-app audio issue went out in Desktop v1.1.5 (the _capturedAudioPid and _audioBufferQueue declarations). If you're still seeing problems on 1.1.5, let me know and I'll dig back in. Otherwise I'll close this out once you've had a chance to test.

[ohmygdala]

Ahhh ok, yea I tested with 1.1.5 / 2.7.8 and it looks like we're still seeing the same issue:

Same exception for the audio pipeline:

[ancsemi]

Took another look at this. The previous fix addressed the missing variable declarations, but the real problem is deeper: the AudioWorklet approach fails silently in some Electron BrowserView environments (blob URLs can get blocked), and when it fails there was no fallback path at all. So even with the variables fixed, the pipeline would still break and you'd get silence.

This new fix does a few things:

• Adds a full ScriptProcessorNode fallback if AudioWorklet fails to load
• Explicitly calls AudioContext.resume() since BrowserViews can start with suspended audio context
• Most importantly, if the entire pipeline fails, it now falls back to regular system loopback audio instead of sending nothing

So worst case you'll get system audio rather than dead silence. Should be in the next Desktop build. Let me know how it goes!

[ohmygdala]

Got it, thanks again for the quick response! I'll give it a shot once the new build is out.

[ancsemi]

@ohmygdala any luck?

[ohmygdala]

Tested with server version 2.7.9 and desktop version 1.1.5 but still seeing the same behavior at the moment. Is there a new build available?

[ancsemi]

Ah, that's on me. The fix went into the codebase after 1.1.5 was tagged, so the build you downloaded doesn't have it yet. I need to push a new Desktop release with the fix included. I'll get that out shortly and ping you here when it's up.

[ohmygdala]

Hey @ancsemi, gave the latest builds 2.8.0 and 1.1.6 a shot. It looks like streaming system audio and per-app audio no longer throws a warning, but users report no sound when streaming. I haven't had much of a chance to really dig in yet. When I get an opportunity I'll test a bit more and pass along anything I find.

[ancsemi]

Thanks for the feedback, I'll start digging. Any info helps!

[ohmygdala]

Pulled the console entries from developer tools on the desktop app: