RE: Peculiar Win/11 Behavior?

I’m guessing by MMIO you mean multimedia I/O (not memory-mapped I/O). What API are you using, exactly? WASAPI? Is it one in which you can try to close and reopen the session within the Lisp process? That might help narrow it down from everything else that process termination might clean up or recycle.

In theory, the driver can request that the priority be boosted of the thread requesting the I/O (https://learn.microsoft.com/en-us/windows-hardware/drivers/wdf/specifying-priority-boosts-when-completing-i-o-requests). Who knows whether that might already be happening or not.

IIRC, any thread priority boosting is considered dynamic boosting, and threads created by it only inherit the base priority.

My money is more on the multimedia stack. It is conceivable there is a reliability bug in an API you are using, or perhaps a resource (Buffer? Non-paged pool?) exhaustion from some long-lived context (and, let’s be honest, grokking unexpected lifetime issues across FFI can be very tricky 😉). It is also still not impossible that it is a device driver issue, since shutting down the stack will likely recycle something in the driver code as well.

- Kurt

From: David McClain <[email protected]>
Sent: Friday, January 17, 2025 11:20 AM
To: Kurt Geisel <[email protected]>
Cc: Paul Werkowski <[email protected]>; Lisp HUG <[email protected]>
Subject: Re: Peculiar Win/11 Behavior?

Down in the Windows MMIO interface (C code) I have a ring of 4 buffers, each 4096 stereo samples long. Once I get a filled buffer, I send it through the 3x heterodyne+decimation before depositing the result into half-buffers at the high level Lisp layer. Then I return the original buffer back to the C ring of buffers.

So, theoretically, I can stretch 3 buffer periods in bursts, so long as I catch up on average to less than one buffer period. My processing takes 4-20 ms.

The higher level Lisp analysis routines work against phase-coherent buffer pairs, and takes as long as it needs to take. So dropouts can occur at the high level, but each analysis will be operating on a phase coherent pair of buffers, so long as the lower level buffer management sees no dropouts.

What I see after 6-8 hours, is that the low level routines suffer a phase stutter (a dropout) and that closing, then re-opening the I/O layer, does not seem to realign the MMIO system. Once whacked, the only solution is to exit the entire Lisp process, then restart from scratch. Presumably this has Windows fully closing out the MMIO subsystem, then restarting from scratch. So it appears that the MMIO is at fault here.




On Jan 17, 2025, at 12:11, David McClain <[email protected]<mailto:[email protected]>> wrote:

Well, I was very deliberate to set all of the A/D and DAC ports of my MOTU 828mk3 to ignore power saving.

And in my code, I run a thread inside of this WITH-SLEEP-DISABLED. That works to prevent the screen saver from appearing, and the monitor stays on with my Lisp app in front. No other user tasks are running, but I’m sure there is a ton of M$ stuff in the background.

I don’t have another audio interface to try here. But it is a reasonable suggestion to substitute a different device.

I still need to try boosting the startup priority of the various threads that I launch. I can boost the priority of LWW from the Task Manager, but I don’t yet understand the relationship between that process setting and the child threads that the process launches.

#+:MSWINDOWS
(progn

  (fli:define-foreign-function (win32-setThreadExecutionState "SetThreadExecutionState"
                                                              :SOURCE)
      ((new-state :UINT32))
    :RESULT-TYPE :UINT32
    :MODULE "kernel32.dll"
    :LANGUAGE :C
    :CALLING-CONVENTION :CDECL)

  (defconstant $WIN32-ES-CONTINUOUS       #x80000000)
  (defconstant $WIN32-ES-DISPLAY-REQUIRED #x00000002)
  (defconstant $WIN32-ES-SYSTEM-REQUIRED  #x00000001)

  (defun disable-sleep-mode ()
    (win32-SetThreadExecutionState (logior $WIN32-ES-CONTINUOUS
                                           $WIN32-ES-DISPLAY-REQUIRED
                                           $WIN32-ES-SYSTEM-REQUIRED)))

  (defun restore-es-state (state)
    (win32-SetThreadExecutionState state))

  (defmacro with-sleep-disabled (&body body)
    (let ((saved-state (gensym)))
      `(progn
         (let ((,saved-state (disable-sleep-mode)))
           (unwind-protect
               (progn
                 ,@body)
             (restore-es-state ,saved-state))))
      )))



On Jan 17, 2025, at 11:56, Kurt Geisel <[email protected]<mailto:[email protected]>> wrote:

A couple of things to consider:

- Don't discount the possibility of the device or its driver being involved. I think you mentioned MOTU. I'm not sure if it is feasible to substitute another audio device even just for a test run and see if you observe anything different.
- Even with full Sleep (S-states) disabled, modern systems have a complex array of run states for power and thermal management (e.g., D-states, C-states). It would be interesting to know if any dependent device makes a transition in your scenario.

Diagnosing I/O performance in a platform like this can become quite involved (e.g., https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/using-windows-performance-analyzer-to-analyze-modern-standby-issues), but it would be true on any platform. You can certainly try a different platform and get lucky enough to not have to dig 😉.

- Kurt

-----Original Message-----
From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> On Behalf Of David McClain (as dbm at refined-audiometrics dot com)
Sent: Friday, January 17, 2025 8:48 AM
To: Paul Werkowski <[email protected]<mailto:[email protected]>>
Cc: Lisp HUG <[email protected]<mailto:[email protected]>>
Subject: Re: Peculiar Win/11 Behavior?

Yes, I just looked at doing that. Windows Task Manager allows me to elevate the priority of processes. It is unclear whether spawned threads inherit the priority of the parent process or not.

I did notice that all of my Actor message dispatch threads have priority 0, both Mac and Windows. And on Windows all the LW Tools (Editor, REPL, etc) have priority 60000000 (Hex? Decimal?). At any rate, I can try to invent these threads with elevated priority.

I can’t really state that the problems only happen in the evening. I was running the other day, and it seems that after about 6-8 hours of data collection, the Windows I/O system gets badly out of sync. Even restarting the app from within Lisp, which closes and then re-opens the I/O, didn’t help. I had to exit the Lisp process entirely, and restart. I am dependent on the MMIO system in Windows for the main data collection. I am mostly a passive client of whatever Windows can achieve.

It would be nice to try Linux for this purpose, but I don’t have any A/D drivers for my MOTU interface under Linux. And MacOS is out of the question for now, since I don’t know how to read the A/D channels directly, even though the driver issue is not a problem. Maybe easier than I think under MacOS?

- DM


On Jan 17, 2025, at 09:15, Paul Werkowski (as pw at snoopy dot qozzy dot com) <[email protected]<mailto:[email protected]>> wrote:

Run the real time threads with elevated priority?



_______________________________________________
Lisp Hug - the mailing list for LispWorks users [email protected]<mailto:[email protected]>
http://www.li/
spworks.com<http://spworks.com/>%2Fsupport%2Flisp-hug.html&data=05%7C02%7C%7Cc4ae6411303f47
f3073e08dd37175271%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638727
295519760900%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwL
jAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%
7C&sdata=6XBFR3W%2BfUhzjKwjDuchdHXme5Eac7Q1p5nfR0pqh6M%3D&reserved=0


_______________________________________________
Lisp Hug - the mailing list for LispWorks users [email protected]<mailto:[email protected]>
http://www.lispworks.com/support/lisp-hug.html