Remote API serves stale data while reporting active: true — meters and spectrum stop updating until restart (v1.5.2, Windows)

[coaxk]

On v1.5.2 (Windows 11), OSM intermittently stops updating its measurement data while the remote API on port 49007 continues to answer normally and reports active: true. There is no error, no status change, and no way to detect it from a single request. Only an application restart clears it.

What we observe

requestChanged returns bit-identical level and referenceLevel across repeated reads, minutes apart:

level            -68.29955291748047     unchanged across dozens of reads
referenceLevel  -156.5355987548828      unchanged
active           true                   throughout
error            (no error reported)

level did not move through a source switch between two different signals, which is what first showed this was the instrument rather than the signal path.

It is not only the meters — the spectrum is stale too

This is the part that matters most for anyone consuming the API. In one affected session we took 9 successive requestData reads and compared the returned coherence value in each FFT bin across those reads:

affected session    100.0% of 4101 bins returned BIT-IDENTICAL values across all 9 reads
healthy sessions      0.0% of 8192 bins, across 13 separate runs — not one repeat

A working instance never repeats a float. An affected one repeats every float. So the API is serving a cached frame rather than a live measurement, and the response is indistinguishable from a real one unless you compare successive reads.

Why it is hard to notice

An automated consumer polling the API sees active: true, a well-formed response, and plausible numbers. Every downstream statistic computes normally and is meaningless. In our case a coherence estimate ran against a dead reference and produced values spanning 0.001 to 1.000 that looked like data.

Reproduction

We cannot reproduce it on demand — that is part of the report. What we can say about when it happened:

2026-09-07   froze after >=2 hours of an active measurement session
2026-09-08   froze within ~18 hours with the application COMPLETELY IDLE —
             no measurement running, no generator, no signal present

So it does not require measurement activity. Both instances cleared on an application restart, with nothing else changed.

What the log shows

%LOCALAPPDATA%\OpenSoundMeter\OpenSoundMeter\log.txt (8423 lines) ends in a repeating cycle that is completely absent from the first half of the file:

wasapi.cpp(403): "GetNextPacketSize" -7776fffc "Unknown error 0x88890004" "AUDCLNT_E_DEVICE_INVALIDATED"
wasapi.cpp(403): "GetBuffer"         -7776fffc "Unknown error 0x88890004" "AUDCLNT_E_DEVICE_INVALIDATED"
wasapi.cpp(403): "stop client" 1 "Incorrect function." "unknown"
generatorthread.cpp(80): audio device not present  "Dante Via (x64)"
asioplugin.cpp(103): "Realtek ASIO" ASIOInit

59 AUDCLNT_E_DEVICE_INVALIDATED lines in three clusters, at 53%, 97% and 99% through the file, and none in the first half. The log ends mid-cycle and goes silent once the application is restarted.

The WASAPI capture client is being invalidated, and stop client then fails with Incorrect function. We are not claiming to have diagnosed this — it is simply the only error class present, it is on the capture path, and a capture client that stops delivering while the source object retains its last values would produce the behaviour above. Happy to attach the full log if useful.

One honest caveat: the log carries no timestamps, so we cannot tie those clusters to the moment of the freeze, only to the same broad period. The operator had also changed the generator's audio device earlier in the same log, which may account for the first cluster.

Environment

OSM            v1.5.2 (latest release)
OS             Windows 11 Pro
Audio device   Dante Via, native (non-ASIO) receive endpoint
Access         remote API, port 49007
Recurrence     at least twice in 24 hours

What would help

Even without a fix, a way to distinguish stale data from live data would remove this whole class of silent corruption — a frame counter or a timestamp on the data returned by requestData, or a status field that goes false when the processing thread stops delivering. At present active: true is returned in both states, so a consumer has no way to tell them apart from a single request.

A timestamp in log.txt would also make this kind of report much easier to substantiate. (For what it's worth, QT_MESSAGE_PATTERN does not help here — the binary installs its own message handler and formats the prefix itself.)

Our own workaround, in case it helps anyone else hitting this: poll requestChanged six times and refuse to trust the instrument if level is bit-identical across all six and above the silence floor. It has caught it twice.

[coaxk]

It happened again a few hours after filing, and this time I captured the full API state at the moment of the freeze rather than reconstructing it afterwards. Two things are worth adding.

It is not only the meters and the spectrum — the whole source object is frozen

I polled requestChanged six times over ~4 seconds while the instrument was stuck. Every one of the 29 fields was bit-identical across all six reads — not one moved:

active           True                 <- still reports healthy
error            False                <- still reports no error
level            -70.19357299804688
referenceLevel   -156.54013061523438
measurementPeak  -57.74271011352539   <- mid-scale, not a noise floor
referencePeak    -156.5355987548828
estimated        -30784
delay            0

spectrum_also_stale was confirmed in the same capture: two successive requestData reads returned bit-identical ftdata. In my original report that was inferred from an archived capture; here it is measured directly at the moment of refusal.

A line-count bracket ties the WASAPI errors to the freeze window

My first report noted that log.txt has no timestamps, so the AUDCLNT_E_DEVICE_INVALIDATED clusters could not be tied to the freeze. I worked around that by recording the log's line count whenever the instrument is verified healthy, and again when the freeze is detected:

11:46   log at 8423 lines   OSM verified healthy — six probes, all levels distinct,
                            a normal measurement taken
14:08   log at 8426 lines   log's last write
14:10   frozen, detected

The only three lines the log gained between a verified-healthy instrument and a frozen one:

wasapi.cpp(403): "GetNextPacketSize" -7776fffc "AUDCLNT_E_DEVICE_INVALIDATED"
wasapi.cpp(403): "GetBuffer"         -7776fffc "AUDCLNT_E_DEVICE_INVALIDATED"
wasapi.cpp(403): "stop client" 1 "Incorrect function." "unknown"

To be precise about what that is and is not: it bounds the window to three log lines, it does not prove causation. But it removes the ambiguity I flagged originally, where the clusters could have come from the operator changing audio devices earlier in the same file.

Timing

Three occurrences now, and the two I can time agree:

2026-09-07   healthy -> frozen in >=2 hours        during an active measurement session
2026-09-08   healthy 11:47 -> frozen 14:08         ~2h20m, machine completely idle
2026-09-08   a third, later the same day

The idle case is the informative one: no measurement was running, no generator, no signal present. Whatever accumulates does not need the application to be doing anything.

Environment unchanged

v1.5.2 on Windows 11, Dante Via native (non-ASIO) receive endpoint, remote API on 49007. Restarting the application clears it every time; nothing else is changed.

Happy to attach the full JSON capture or the log if either would be useful.

[coaxk]

Correction: the trigger is a Windows session transition, and I can reproduce it on demand

My earlier comments framed this as something that accumulates with uptime ("~2h20m, machine completely idle"). That framing was wrong. I went back to the Windows event logs and every freeze I have bracketed sits on a Remote Desktop session disconnect/reconnect (TerminalServices-LocalSessionManager events 24/25), including the overnight one:

2026-09-08 02:20:01   RDP disconnect (network timeout), reconnect 11 s later   -> found frozen in the morning
2026-09-08 14:08:40   RDP reconnect                                            -> frozen, log write 14:08
2026-09-08 17:20:15   RDP disconnect + reconnect                               -> frozen by 17:25

Then a designed test:

20:25:27   verified healthy: level moving across 4 reads, log at 8442 lines
20:26:09   operator disconnected the RDP session on purpose
20:26:53   level bit-identical across 6 reads, active: true, log at 8449 lines

The seven lines the log gained are the same wasapi.cpp(403) cycle as before: GetNextPacketSize / GetBuffer returning AUDCLNT_E_DEVICE_INVALIDATED three times, then "stop client" 1 "Incorrect function.". 44 seconds from session disconnect to a frozen instrument reporting active: true.

The capture device here is the Dante Via virtual endpoint, not a USB device, so this is not USB selective suspend (it is disabled on this machine, and the machine has no standby state at all). A console session change is enough for Windows to invalidate that endpoint.

So the sharper statement of the bug is: when WASAPI invalidates the endpoint, the capture loop logs the error and exits (stop client fails), but the source stays active: true and the remote API keeps serving the last frame indefinitely. Recovery would presumably mean re-acquiring the device on AUDCLNT_E_DEVICE_INVALIDATED (or at least flipping active/error so a client can tell). The uptime pattern I reported was an artefact of how often this laptop gets an RDP session change.

Repro for anyone on Windows: run a measurement on a WASAPI device, disconnect and reconnect an RDP session (or, I expect, lock the workstation), read requestChanged a few times.

[coaxk]

Correction: a restart is not required — re-selecting the input device recovers it

My report and first comment both say only an application restart clears this. That is wrong, and the workaround is much cheaper. Re-selecting the same input device in the GUI re-acquires the endpoint and the instrument resumes immediately. The channel assignments survive it, and the recovery writes nothing to log.txt — the line count was identical before and after (8455).

A distinguishable intermediate state, if it helps localise the fault

Pressing Reset Averaging on a frozen instance does something visible but does not recover it. Both meters then read a bit-identical:

level, referenceLevel    -3076.53 dB   =  1.5e-154 linear
the real silence floor   -157.19 dB    =  1.4e-08  linear

Eleven orders of magnitude below the noise floor. The reset empties the averaging accumulators and nothing refills them, which seems to confirm the capture thread is dead while the source object is still alive and still reporting active: true. Re-selecting the device from that state restores normal readings.

A fifth occurrence, bracketed to ~25 seconds

17:14:54   instrument verified healthy
17:15:19   TerminalServices event 40, session disconnected, reason code 5
17:15:23   event 25, reconnection succeeded — 4 seconds later
19:32      frozen, active: true, spectrum stale across two reads

Worth noting for anyone trying to reproduce it: this disconnect was a 4-second network blip that the operator did not notice at all. I initially recorded this occurrence as having no session transition, on the operator's report, and the event log corrected me. A deliberate disconnect is not required — a brief network interruption to the RDP session is enough.

[psmokotnin]

Hm, will check waspi implementation
thanks for the report!

[coaxk]

Narrowed: it is the WASAPI session-disconnect on an RDP transition, capture streams only, and the audio driver's own log shows the event

Three things since the last comment, all measured today.

1. A local lock does NOT trigger it. With no RDP session open anywhere: Win+L, one minute, unlock. Probed at +0, +10, +20 s and again 4 minutes later — level distinct on every read, API answering. That is now 0 of 1 for a local lock against 8 of 8 for an RDP connect or disconnect, so the trigger is specifically the remote-session transition, not "any session change".

2. The virtual audio driver logs the exact event. The input device here is a Dante Via virtual endpoint, and Via's session manager writes a line for each application audio session it holds when Windows delivers the WASAPI session-disconnect notification. At the moment of tonight's RDP connect:

Sep 11 16:40:36 Warning RMApoAudioSessionEvents::OnSessionDisconnected: 2812:  Audio session disconnected(reason : session disconnected)   <- OpenSoundMeter.exe
Sep 11 16:40:36 Warning RMApoAudioSessionEvents::OnSessionDisconnected: 24196: Audio session disconnected(reason : session disconnected)   <- another audio application
Sep 11 16:40:36 Warning RMApoAudioSessionEvents::OnSessionDisconnected: 17504: Audio session disconnected(reason : session disconnected)   <- chrome.exe

"session disconnected" is the driver's rendering of AudioSessionDisconnectReason = DisconnectReasonSessionDisconnected. Every application on the machine gets it at once. Every freeze I have observed — eight of them — has a matching group of these lines at the same minute (Sep 8 02:20, 14:08, 17:20, 20:26; Sep 9 17:15; Sep 10 17:01; Sep 11 14:02, 16:40). The log holds four further groups I was not watching the instrument for, and the local lock at 14:37 today produced none.

3. Capture streams die; render streams survive — across two applications and two endpoint drivers. On the same 16:40 event:

stream	endpoint	outcome
OSM capture	Dante Via receive	frozen — active: true, level bit-identical 6/6
second application, capture	a USB measurement mic (not Via)	that application raised "The soundcard did not provide any input data … please check that it is connected"
second application, render	Dante Via transmit	kept running — proven by a meter on the receiving DSP, not by the application's status flag

So the capture stream is invalidated on the transition and the other application notices and says so; OSM keeps reporting active: true on the dead stream. Re-selecting the input device (previous comment) is the manual form of what the second application is asking the user to do.

If it helps: the recovery that works by hand is a re-open of the capture stream, so handling IAudioSessionEvents::OnSessionDisconnected (or an AUDCLNT_E_DEVICE_INVALIDATED return from GetBuffer) by tearing down and re-initialising the capture client would match what the GUI re-select does. I have not read the capture code, so that is a description of the symptom, not a diagnosis of the code.

[coaxk]

Correction: render streams die too. And a control that reports the state correctly.

My previous comment said capture streams die and render streams survive. That was two applications and the render half does not generalise — I have since tested it properly and it is wrong. Retracting it, and replacing it with a cleaner control.

A minimal third client, run across an RDP disconnect/reconnect: PortAudio in WASAPI shared mode, one capture stream (USB mic) and one render stream (silence, onboard speakers). Neither endpoint is the virtual audio device, both directions in one process, frames and stream state logged once a second.

13:10:00  TerminalServices: session disconnected
13:10:01  capture 44640 -> 0 frames/s, render 42240 -> 0 frames/s
          both streams report inactive
13:11:03  TerminalServices: reconnection succeeded — both still inactive

So the session-disconnect stops every WASAPI shared-mode stream, both directions, on any endpoint, and a reconnect restores nothing. The application I described as surviving had simply re-opened its own render stream. Worth noting the event fires on the disconnect: taking over a console session disconnects it first, which is why connecting also triggers this.

The useful part is what that control does next. Those fifty lines of Python report active = False after the disconnect. On the same machine, on the same event, OSM reports active: true and keeps serving the last data indefinitely.

That separates two different asks:

• re-acquiring the stream is genuinely awkward on Windows, and I am not claiming it is easy
• reporting that the stream has stopped is demonstrably easy, and there is a working counterexample on the same machine

The second is the one that costs a user an entire measurement session, because a frozen instrument that says active: true with a plausible spectrum is indistinguishable from a working one. Re-selecting the input device in the GUI still recovers it, as in my earlier comment.