FreeRDP: [websockets] Microphone inoperative or freezes connection when using RD Gateway
Describe the bug Using default “/microphone” option creates a Remote Audio device on the server, but no audio shows up on the meter, nor does any remote application do any recording (i.e. Microsoft Teams). Using “/mic:sys:pulse,format:1” allows connection to the server, but almost always freezes before the remote login process completes. Connecting to the same remote server via Windows does work properly and I have no issues using the microphone.
The first part (using the default /microphone option) also fails to record sound on a local Windows 11 machine. The second part (using /mic:sys:pulse,format:1) doesn’t freeze a local Windows 11 machine, and the audio records properly.
To Reproduce Steps to reproduce the behavior:
- Sign into RD Gateway machine with the “/mic:sys:pulse,format:1” option enabled.
- See login screen on the screen then the connection freezes.
Expected behavior Signing in with the “/mic:sys:pulse,format:1” option should allow successful login and proper microphone redirection.
Screenshots If applicable, add screenshots to help explain your problem.
Application details
- FreeRDP version (
xfreerdp /version):This is FreeRDP version 2.8.0 (2.8.0) - Command line used:
/usr/bin/xfreerdp /cert:ignore /log-level:DEBUG /sound /mic:sys:pulse,format:1 /f /floatbar /multimon /monitors:1,2 /g:portal.contoso.com /load-balance-info:"tsv://MS Terminal Services Plugin.1.Tech_Desktop" /v:contoso-dc-rdscb01.contoso.local /u:me@contoso.com /p:mypassword 2>&1 | tee freerdp.log - Output of
xfreerdp /buildconfig:
Build configuration: BUILD_TESTING=OFF BUILTIN_CHANNELS=ON HAVE_AIO_H=1 HAVE_EXECINFO_H=1 HAVE_FCNTL_H=1 HAVE_GETLOGIN_R=1 HAVE_GETPWUID_R=1 HAVE_INTTYPES_H=1 HAVE_JOURNALD_H=TRUE HAVE_MATH_C99_LONG_DOUBLE=1 HAVE_POLL_H=1 HAVE_PTHREAD_MUTEX_TIMEDLOCK=ON HAVE_PTHREAD_MUTEX_TIMEDLOCK_LIBS= HAVE_PTHREAD_MUTEX_TIMEDLOCK_SYMBOL=1 HAVE_SYSLOG_H=1 HAVE_SYS_EVENTFD_H=1 HAVE_SYS_FILIO_H= HAVE_SYS_MODEM_H= HAVE_SYS_SELECT_H=1 HAVE_SYS_SOCKIO_H= HAVE_SYS_STRTIO_H= HAVE_SYS_TIMERFD_H=1 HAVE_TM_GMTOFF=1 HAVE_UNISTD_H=1 HAVE_XI_TOUCH_CLASS=1 WITH_ALSA=ON WITH_CAIRO=OFF WITH_CCACHE=ON WITH_CHANNELS=ON WITH_CLANG_FORMAT=ON WITH_CLIENT=ON WITH_CLIENT_AVAILABLE=1 WITH_CLIENT_CHANNELS=ON WITH_CLIENT_CHANNELS_AVAILABLE=1 WITH_CLIENT_COMMON=ON WITH_CLIENT_INTERFACE=OFF WITH_CUPS=ON WITH_DEBUG_ALL=OFF WITH_DEBUG_CAPABILITIES=OFF WITH_DEBUG_CERTIFICATE=OFF WITH_DEBUG_CHANNELS=OFF WITH_DEBUG_CLIPRDR=OFF WITH_DEBUG_DVC=OFF WITH_DEBUG_KBD=OFF WITH_DEBUG_LICENSE=OFF WITH_DEBUG_MUTEX=OFF WITH_DEBUG_NEGO=OFF WITH_DEBUG_NLA=OFF WITH_DEBUG_NTLM=OFF WITH_DEBUG_RAIL=OFF WITH_DEBUG_RDP=OFF WITH_DEBUG_RDPDR=OFF WITH_DEBUG_RDPEI=OFF WITH_DEBUG_RDPGFX=OFF WITH_DEBUG_REDIR=OFF WITH_DEBUG_RFX=OFF WITH_DEBUG_RINGBUFFER=OFF WITH_DEBUG_SCARD=OFF WITH_DEBUG_SND=OFF WITH_DEBUG_SVC=OFF WITH_DEBUG_SYMBOLS=OFF WITH_DEBUG_THREADS=OFF WITH_DEBUG_TIMEZONE=OFF WITH_DEBUG_TRANSPORT=OFF WITH_DEBUG_TSG=OFF WITH_DEBUG_TSMF=OFF WITH_DEBUG_TSMF=OFF WITH_DEBUG_TSMF_AVAILABLE=0 WITH_DEBUG_URBDRC=OFF WITH_DEBUG_WND=OFF WITH_DEBUG_X11=OFF WITH_DEBUG_X11_CLIPRDR=OFF WITH_DEBUG_X11_LOCAL_MOVESIZE=OFF WITH_DEBUG_XV=OFF WITH_DSP_EXPERIMENTAL=OFF WITH_DSP_FFMPEG=ON WITH_EVENTFD_READ_WRITE=1 WITH_FAAC=OFF WITH_FAAD2=OFF WITH_FFMPEG=TRUE WITH_FFMPEG=TRUE WITH_GFX_H264=ON WITH_GPROF=OFF WITH_GSM=OFF WITH_GSSAPI=OFF WITH_ICU=ON WITH_IPP=OFF WITH_JPEG=ON WITH_LAME=OFF WITH_LIBRARY_VERSIONING=ON WITH_LIBSYSTEMD=ON WITH_MACAUDIO=OFF WITH_MACAUDIO=OFF WITH_MACAUDIO_AVAILABLE=0 WITH_MANPAGES=ON WITH_MBEDTLS=OFF WITH_OPENCL=OFF WITH_OPENH264=OFF WITH_OPENSLES=OFF WITH_OPENSSL=ON WITH_OSS=ON WITH_PAM=ON WITH_PCSC=ON WITH_PROFILER=OFF WITH_PROXY=ON WITH_PROXY_MODULES=OFF WITH_PULSE=ON WITH_SAMPLE=OFF WITH_SANITIZE_ADDRESS=OFF WITH_SANITIZE_ADDRESS_AVAILABLE=1 WITH_SANITIZE_MEMORY=OFF WITH_SANITIZE_MEMORY_AVAILABLE=1 WITH_SANITIZE_THREAD=OFF WITH_SANITIZE_THREAD_AVAILABLE=1 WITH_SERVER=ON WITH_SERVER_CHANNELS=ON WITH_SERVER_INTERFACE=ON WITH_SHADOW=ON WITH_SMARTCARD_INSPECT=OFF WITH_SOXR=OFF WITH_SSE2=ON WITH_SWSCALE=ON WITH_THIRD_PARTY=OFF WITH_VAAPI=OFF WITH_VALGRIND_MEMCHECK=OFF WITH_VALGRIND_MEMCHECK_AVAILABLE=1 WITH_VERBOSE_WINPR_ASSERT=ON WITH_WAYLAND=ON WITH_WINPR_TOOLS=ON WITH_X11=ON WITH_XCURSOR=ON WITH_XDAMAGE=ON WITH_XEXT=ON WITH_XFIXES=ON WITH_XI=ON WITH_XINERAMA=ON WITH_XKBFILE=ON WITH_XRANDR=ON WITH_XRENDER=ON WITH_XSHM=ON WITH_XTEST=ON WITH_XV=ON WITH_ZLIB=ON
Build type: None
CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -flto=auto -fPIC -Wall -Wno-unused-result -Wno-unused-but-set-variable -Wno-deprecated-declarations -fvisibility=hidden -Wimplicit-function-declaration -Wredundant-decls -g -fno-omit-frame-pointer -DWINPR_DLL
Compiler: GNU, 12.1.0
Target architecture: x64
- OS version connecting to (server side): Windows Server 2016 Datacenter, 1607 / 14393.5356)
- If available the log output from a run with
/log-level:trace 2>&1 | tee log.txt: Attached freerdp-standard-sound-mic.log freerdp-pulse-format.log - If you built it yourself add some notes which tag/commit/branch you have used, also your cmake parameters and compiler can help: N/A
Environment (please complete the following information):
- OS: Linux
- Version/Distribution: Arch Linux (up-to-date as of 10/11/2022)
- Architecture: amd64
- Audio Server (if relevant): PipeWire 0.3.59 including pipewire-pulse
Additional context I have tried this with both the built-in laptop microphone and a Logitech H390 USB headset/microphone. The same issue occurs with both devices. I’ve also edited the log files to change the name of the user, domain and public IP address. No other changes were made. The microphones work properly in all local applications and any RDP connection that doesn’t use a RD gateway.
I decided to post this after seeing #8180 as it seems possible that the gateway code may be a common thing between the two issues.
About this issue
- Original URL
- State: open
- Created 2 years ago
- Comments: 36 (24 by maintainers)
ok, now I tested with a windows server 2022 rdg. Just one comment: what a mess.
websocket “upload” is very slow mstsc also “blocks” when uploading a file, although the close button works connection are on a 1Gbit LAN, the most I got was 9MB/s upload over non websocket (with freerdp), about 1MB/s over websocket (with both mstsc and freerdp).
so this is seems to be a rdg issue. Probably the reason why this issue is not so apparent with windows is indeed that mstsc does not use pcm audio upload ans so remains below a specific treshold
@niv71 definitely unexpected, but need to investigate what happens there 😮
So far so good using 2.8.1 from Arch with the /gt:http,no-websockets option. The connection seems faster as well. Not sure if that’s an expected result.
@niv71 ok, I was finally able to reproduce the issue. You´ll laugh, but it has nothing to do with
soundormicrophone, it is a gateway only thing. Try/gt:http,no-websocketsand it will work. There seems to be an issue with websocket transport (currently no idea if client or server side is at fault)