I'm coming late to the party. Sorry. I thought you had quite enough help, and I don't have an answer anyway. I also haven't tested anything.
However, some observations:
From the Latency Monitor report; DPC count (execution time <250 µs): 243394. Assuming an average of 125 µs, that adds up to 30.4 seconds in a 2 minute 39 second run (or was that a 03:22:00 run?). That seems quite high. But I'm no expert on Latency Monitor.
Note: The Per CPU Data in the Report.txt file doesn't seem to be consistent with my assumption above, but I'm not sure I'm reading that right. The report says each processor DPC load is sub-second, which wouldn't be an issue.
The Hard Page Faults for MC23 seem high as well at 4131. I would expect MC to be reading files made up of sequential sectors, so most of each file would be read to memory on initial request. I think.
It may be worth spending more time with Latency Monitor, and having it running while the problem is caused.
It is worth noting that ndis.sys was the most used driver, and that during that 00:02:39 time period, it was working for 69.89 seconds. May not be an issue, but...
It looks like MC is taking lots of small nibbles at the files.
BTW, did the problem actually happen during that Latency Monitor run?
What is your audio playback device? Sound card, USB DAC, network based device, etc.
As for playback, Multichannel LDPCM over HDMI to a Theta Casablanca Processor.
So, are you using the i7 HDMI out port? i.e. No discrete video card involved?
Intel iGPU capabilities haven't exactly been stellar, particularly HDMI support, which has been quite lacking. Last I heard, it still has problems with high resolution audio, or more correctly, later processors actually have reduced capabilties compared to earlier processors. I assume that you have the latest drivers for the processor, but maybe do some research around HDMI on iGPU and see if anything shows up. At least one report I read said that an earlier driver actually had better capabilities, but that may not be an option as the driver needs to support the processor version, and earlier drivers probably won't.
Also, do all of your builds with the problem use the Theta Casablanca Processor? Same version? Same firmawre? When using HDMI, it could be any component in the HDMI chain that is causing the problem. HDMI components talk to each other, and will change settings... or not, depending on capabilities.
Perhaps try with a discrete video card installed, and/or with HDMI output to a different set of devices? Worth eliminating as a possible cause.
The other thing you can do is use some of the
Microsoft Sysinternals tools to try to narrow down exactly what is happening when the file is being buffered. They aren't easy tools to learn, but they may shed some light. There are lots of tools in the Suite.
PS: I understand that a couple of other applications play these files without issue, so it does sort of point to MC. But when the other applications play them, does the Theta Casablanca Processor report it is receiving the same signal type? i.e. Could the other applications be doing something you are unaware of to the audio before sending it to the processor? Are all applications using the same output mode, such as WASAPI Exclusive? Or is Direct Sound putting in an appearance?
Or maybe MC is trying to be too smart, and is treating the LDPCM (log differential pulse code modulation) differently to regular LPCM (is there a difference?), and is therefore doing some conversion, or not doing a conversion the others are? What does the MC Audio Path say?