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]> 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]> 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]> 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]> 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]> 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]
>>>> 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
>