From 864e51a0b424ff7a98628f7aa8005b525290fc3a Mon Sep 17 00:00:00 2001 From: Daniel Roggen Date: Sat, 18 Jul 2026 19:44:21 +0100 Subject: [PATCH] Fix stdout binary mode reset on Windows before streaming starts Running rx_fm piped to sox or ffplay on Windows 11 leads to broken audio: crackling, no sound coming out. The issue is a text/binary mode problem in piping the output of rx_fm, where Windows resets the binary/text mode rather than preserving it. On Windows, suppress_stdout_stop() calls dup2() to restore the original stdout file descriptor after device enumeration/setup logging is redirected away. Windows' dup2() resets the destination descriptor to text mode as part of this restore, silently undoing the earlier _setmode(..., _O_BINARY) call made when output.file was set to stdout in main(). This caused every 0x0A byte in the raw audio/IQ sample stream written to stdout to be corrupted by CRLF translation when rx_fm/ rx_sdr output was piped to another process (e.g. sox, ffplay, direwolf) on Windows. Writing directly to a file was unaffected, since that code path does not go through suppress_stdout_stop(). Fix: re-apply _setmode(..., _O_BINARY) immediately after suppress_stdout_stop() in dongle_thread_fn, the last place stdout's mode is touched before the write loop begins. Verified by measuring 0x0D 0x0A byte-pair density in captured pipe output: ~0.7-1.3% before the fix vs ~0.002-0.005% baseline for clean random PCM data; ~0.004% after the fix, matching baseline. --- src/rtl_fm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/rtl_fm.c b/src/rtl_fm.c index 0093007..ee1e64f 100644 --- a/src/rtl_fm.c +++ b/src/rtl_fm.c @@ -879,6 +879,9 @@ static void *dongle_thread_fn(void *arg) suppress_stdout_stop(tmp_stdout); +#ifdef _WIN32 + _setmode(_fileno(output.file), _O_BINARY); +#endif if (output.wav_format) { generate_header(&demod, &output); }