DJ2LS
[Bug]: audio loss when dis/connecting via RDP (Windows)
FreeDATA Version
0.16.1.alpha
What operating system are you using?
Windows
Operating System Version
Windows 10
Architecture
x86
Area of problem
Server - Message System
Describe the bug
When connecting to my Windows test machine with a running FreeDATA server via RDP, the waterfall freezes because the audio device reports an "input overflow". Also happens when disconnecting the RDP session: image.png I suspect that this is a (new) RDP bug; perhaps the audio device is briefly "touched" when disconnecting or connecting and thus snatched from the server. Maybe there is a chance to find a workaround for this and make FD a bit more resilient against this issue?! (Btw.: VARA seems to have the same issue, and shows up “frozen” after a connect, but recovers after a short time)
To Reproduce
Connect via RDP to Windows instance
Expected behavior
Audio crash
Screenshots
Log Files
No response
Additional context
No response
Yes, it´s still existing with 0.16.8:
2024-11-10 13:50:51 [warning ] [AUDIO STATUS] frames=4800 status=<sounddevice.CallbackFlags: input overflow> time=<cdata 'struct PaStreamCallbackTimeInfo *' 0x000000AF0A9DF6A8>
As ist seems to a Windows/RDP related issue to me, you may close this report. If you want to work around this issue, maybe a kind of watchdog which restarts the audiodevices may do the trick when an input overflow occurs.
I experience this is as well, and believe it's related to audio forwarding. If it't enabled it'll stop working for me. When disabled there's no issues. Don't think this is something that can be addressed by us.
Error still occurs with 0.16.11 on Windows 11 with the same warning message (see Nov 10 entry in this issue). It´s for sure a Windows-thing, but maybe there´s a way to work around this, as VARA seems to suffer from this issue as well. Watchdog -> restart audio part?
Only option would be a “healing mechanism”. Means if audio stops we could try restarting it somehow. Not sure if this is really needed. Otherwise we should write a wiki entry and closing this issue Von meinem iPhone gesendetAm 11.03.2025 um 07:17 schrieb Stefan DK5SM @.>: Error still occurs with 0.16.11 on Windows 11 with the same warning message (see Nov 10 entry in this issue). It´s for sure a Windows-thing, but maybe there´s a way to work around this, as VARA seems to suffer from this issue as well. Watchdog -> restart audio part?—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.>
dk5sm left a comment (DJ2LS/FreeDATA#773) Error still occurs with 0.16.11 on Windows 11 with the same warning message (see Nov 10 entry in this issue). It´s for sure a Windows-thing, but maybe there´s a way to work around this, as VARA seems to suffer from this issue as well. Watchdog -> restart audio part?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>
modem.py, line 291
if status:
self.log.warning("[AUDIO STATUS]", status=status, time=time, frames=frames)
# FIXME on windows input overflows crashing the rx audio stream. Lets restart the server then
#if status.input_overflow:
# self.service_queue.put("restart")
return
That's the input audio callback code. We already have some code there, but we disabled it. @Mashintime you are running on windows from source, right? Could you do me the favor, and disabled the "return" statement, so we can see what happens in this case of buffer overflow? Restarting the server every time on buffer overflow doesn't make sense as it might result into a bad restarting loop. So maybe we just inform about the overflow, but don't care about it.