RE: Peculiar Win/11 Behavior?

OH! When I heard MMIO my first thought was reading multimedia files but dismissed this interpretation because you were talking about the device. I thought you were doing direct I/O with the device (say, in real time). But am I to understand you are reading already-captured WAV files? So, one might expect the device doesn’t matter (unless it’s ADC problems we’re observing).

So perhaps my suggestion is less practical—if you have to mmioClose part way through, you would have to re-seek to where you were. Perhaps you are processing very large files.

Could you keep WAV file reading in the Lisp realm (riff-wave [https://github.com/eugeneia/riff-wave] sounds like it might not be robust enough for all the format variations one might encounter—and you’ve already mentioned fake sample rates)?

I guess form your description of a continuous time-sensitive process, perhaps you are trying to read a WAV file concurrently with it being written? Hmmm. I might think about replacing the device with a test process that writes a continuous WAV file with a known repeating pattern, then perhaps you can rig it to detect when you observe corruption. Then, you might catch mmio “red-handed” or narrow down where it is going wrong. Another, more involved approach to isolate mmio would be to have two consumer processes—one running in Lisp and one a dumb harness around your C code. They both just write a data stream that you can later compare to see if was only the Lisp version that observed corruption. If both observe it, I think you pretty much painted mmio into a corner.

- Kurt

From: David McClain <[email protected]>
Sent: Friday, January 17, 2025 3:08 PM
To: David McClain <[email protected]>
Cc: Kurt Geisel <[email protected]>; Toomas Altosaar <[email protected]>; Yuri Davidovsky <[email protected]>; Lisp HUG <[email protected]>
Subject: Re: Peculiar Win/11 Behavior?

When I say that I restart the app from Lisp, I mean that the MMIO stuff is closed out, then reopened with fresh buffers, threads, etc. The whole MMIO should be back to init state.

Getting to a point where a debugger could be used is very tedious. It takes typically 6-8 hours for something interesting (bad) to happen.

I have gone through the Lisp with a fine-toothed comb looking for problems. So far, I’m not seeing any.  But that shouldn’t be too surprising - how often does the Fox smell its own hole?





On Jan 17, 2025, at 16:00, David McClain (as dbm at refined-audiometrics dot com) <[email protected]<mailto:[email protected]>> wrote:

Here is my code. I’m using plain old MMIO - the very oldest API that M$ defined.

WASAPI? Oh dear… I was hoping to avoid diving too deeply into Windows. I have an allergic reaction whenever I get too deeply into Windows or VMS code.

The WAV file stuff is at the top, the realtime acquisition is in the middle, and some high-perf subroutines for Lisp are at the end.

<lispwave.cpp>



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

I'm still not sure which specific API you are using. For example, if using WASAPI, you could try to make two test runs separated by IAudioClient::Stop() and see if that alone recovers from your phase jitter. If not, you can incrementally tear down more things (e.g., Release() all the interfaces) between the two runs until you've found the suspect. If you can't find any way to recover from within the Lisp process, this might not tell you much more than what it is *not* :-/.

- 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 2:10 PM
To: Toomas Altosaar <[email protected]<mailto:[email protected]>>
Cc: Yuri Davidovsky <[email protected]<mailto:[email protected]>>; Lisp HUG <[email protected]<mailto:[email protected]>>
Subject: Re: Peculiar Win/11 Behavior?

GC should not be an issue. Every 15 sec or so I make a call to (HCL:GC-GENERATION T).

And yes, I am using Multi-media subsystem (MMIO). I can open the incoming A/D and request a sample rate of 8 kHz, even though it is happening physically at 48 kHz. There is nothing in the signal above 3 kHz. So, no matter how sloppily M$ pulls off that sample rate conversion, I’ll be okay.

(That’s another reason I hesitate to use a Mac here. I don’t believe the Mac will accommodate the fake 8 kHz sample rate.

The Windows machine also hooks up to the plethora of RS-232 Serial I/O ports needed by other equipment and software. Yes, EE’s seem to be heavily wedded to Windows PC’s and Serial I/O - now done with USB interfaces.)

After this experience, I’m finding that in many ways the M1 iMac and the Windows/11 AMD Ryzen 5 5600G with Radeon Graphics at 3.9 GHz, are both remarkably the same effective compute speed.





On Jan 17, 2025, at 14:36, Toomas Altosaar (as toomas dot altosaar at gmail dot com) <[email protected]<mailto:[email protected]>> wrote:

Garbage collection came to mind as well: make a substantial amount of garbage, then time how long (gc) takes to run (or whatever a full gc is called in LW). David: are you running with ephemeral gc enabled?


On 17. Jan 2025, at 23.25, Yuri Davidovsky (as work at disclosure dot ie) <[email protected]<mailto:[email protected]>> wrote:


Could that be the garbage collector secretly trying to stab you in the back?


On 17 Jan 2025, at 20:21, David McClain (as dbm at refined-audiometrics dot com) <[email protected]<mailto:[email protected]>> wrote:

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.


_______________________________________________
Lisp Hug - the mailing list for LispWorks users
[email protected]<mailto:[email protected]>
http://www.l/
ispworks.com<http://ispworks.com/>%2Fsupport%2Flisp-hug.html&data=05%7C02%7C%7Cabe57c1f8fd8
4aa48b5508dd3743ecac%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638
727487075972181%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiO
iIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7
C%7C%7C&sdata=2Lw%2Bp8c8gZnSK90AupMahRLiiucEur3SPkMozbczasI%3D&reserv
ed=0

_______________________________________________
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%7Cabe57c1f8fd84a
a48b5508dd3743ecac%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638727
487075991088%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwL
jAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%
7C&sdata=03RQeVZNuGMNRmDFffgE4aIu6N6i8M03glGHqyIMyIk%3D&reserved=0


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