A user-adjustable interface size, for 4K screens. VIEW → Display now has an "Interface size" dropdown - Auto (the default, which follows what Windows reports for the monitor the window is currently on) or a fixed 100/125/150/175/200/250%, plus Ctrl+= / Ctrl+- / Ctrl+0 as shortcuts. It scales fonts and layout together, everywhere in the application including the patch page, and exists for people whose desktop reports the wrong number, or none, for how big FoxSDR's text and controls should be on a high-resolution display.
SDRplay: the radio may have been quietly running at three times the rate you set - FoxSDR now always asks for zero-IF instead. Two field reports from RSP2 owners showed the radio delivering 6 MS/s while FoxSDR had asked for 2 MS/s and built its whole processing chain for that rate: the SDRplay API specification says nothing about what its low-IF front end actually delivers, and there is no RSP here to check it against - those two field logs are the only evidence this was built on. FoxSDR now always asks for zero-IF, which leaves no room for that disagreement, at the cost of the low-IF mode's freedom from a centre spike; the API's own DC correction is switched on for zero-IF (sdrplay_source.cpp), which it exists to suppress, though whether it fully does so is not verified on any radio here. Separately, if the SDRplay session is lost mid-use, FoxSDR now stops trying to close every open SDRplay radio through the dead API service - each teardown used to make that call regardless. Stopping a running SDRplay radio can no longer freeze the application for several seconds: that call (sdrplay_api_Uninit) is now bounded to one second. Closing a radio is not: after the stream stops, its ReleaseDevice and Close calls are made directly, with no such bound, so a service that is slow but not yet dead can still hang the application there. None of this fixes the SDRplay API service's own drop in the first place, whose cause is still unknown. This entire change is untested on real SDRplay hardware - there is none on the development desk - and awaits reports from users who have an RSP.
Audio no longer crackles or clips when you widen the channel filter. Widening a demodulator's channel bandwidth could let occasional samples run past full scale, and the audio path clipped them outright, heard as crackle or distortion. A soft limiter now catches only the rare over-scale peak and brings it back smoothly; anything under about 97% of full scale is completely unaffected; bit-for-bit identical to before.
A per-frame system call removed, that a busy or throttled graphics driver can stall on. FoxSDR was calling into GLFW's mouse-passthrough setting on every single frame regardless of whether it had changed. Nine freeze reports from the 0.99.26 build the Microsoft Store serves were caught inside this exact call while the graphics driver was busy - a contributing cause, not proven to be the whole story. The value is now cached and the underlying call is only made when it actually changes.
Airspy: ADS-B now decodes even if you have raised the radio's decimation. The ADS-B decoder refuses to run below 2 MS/s and asks its preset for 2.4 MS/s; if an Airspy R2 or Mini's decimation had been raised for something else, the radio could be stuck delivering nothing above roughly 1.25 MS/s (R2) or 750 kS/s (Mini) - below the decoder's own floor - because FoxSDR only ever looked for the nearest rate within whatever decimation was already set. A plugin preset, or a rate you pick by hand from the Rate menu, now looks at every native-rate-and-decimation combination the radio offers and picks the nearest one at or above what was asked, dropping the decimation automatically when that is what it takes to get there. A generic rate FoxSDR asks for on its own - opening the radio from the Source list, or a setting restored from a previous session - is unaffected and keeps whatever decimation you last set: an earlier version of this fix searched every decimation there too, which let that generic ask silently walk a deliberately-raised decimation back down the moment the radio was opened.
Beta tester usage reporting, for testers who have been given a code. If you have joined the tester list on foxsdr.com and pasted your tester code into Settings → Beta tester, FoxSDR now sends one report per session - application version, platform, session length, which named beta areas and which installed decoders you actually used (never a frequency, never decoded content, never your position) - so the areas testers said they would cover can be checked against what was actually exercised. This is completely separate from ordinary usage reporting and off for everyone else: with no tester code entered, nothing on that page is ever collected or sent. Remove the code in Settings → Beta tester to switch it off immediately - see PRIVACY.md for the exact field-by-field list of what is sent.
The crash-report cleaner no longer mangles a plugin's own name. The scrubber that removes anything that looks like a frequency from an uploaded log was turning a plugin name like "406 MHz Beacons" into gibberish, because "406 MHz" reads exactly like a tuned frequency. Plugin names that a report already lists by name are now left alone wherever they appear in it.
SHA-256 of foxsdr-setup-0.99.44.exe:
21cf4ace56e6c07c99c0f99b5fa1d0b91d11508b839ff5403544ef72b11ef97e
SHA-256 of FoxSDR-0.99.44-x86_64.AppImage:
b140e5417c077535a2d8a52d3adb56b340c1dc0f2484c11eca8daa77690936a8
SHA-256 of foxsdr-0.99.44-linux-x64.tar.gz:
9aab987f0872613a3ff2fd17a9fba8f89f6d0b65348d55841397011d76b58ff1