Fix Windows ole32 loading and NumPy compatibility in MediaFoundation backend

[mehran-mousavi]

Fix Windows ole32 loading and NumPy compatibility in MediaFoundation backend

Description

This pull request introduces two critical fixes to the Windows MediaFoundation backend of soundcard:

1. Robust ole32 loading

   • Previously, _ffi.dlopen('ole32') could fail on certain Windows 11 systems with Python 3.11+, where the generic library name was not resolved correctly.
   • The code now attempts to load ole32 first and falls back to ole32.dll if necessary, ensuring consistent behavior across Windows environments.

2. NumPy API compatibility

   • Replaced the deprecated numpy.fromstring (binary mode) with numpy.frombuffer(...).copy().
   • This change ensures compatibility with modern NumPy versions (≥2.x.x), while also guaranteeing a writable float32 array for downstream audio processing.

Impact

• Restores functionality on Windows 11 + Python 3.11+ where ole32 loading previously failed.
• Prevents runtime errors with the latest NumPy releases.
• Maintains backward compatibility with existing code paths.

Notes

• These changes are limited to the Windows MediaFoundation backend and do not affect Linux (PulseAudio) or macOS (CoreAudio) backends.
• Tested on Windows 11 with Python 3.11 and latest version of NumPy

[bastibe]

Thank you very much for your pull request, and debugging all of these issues. What sound card are you using that triggers these behaviors?

[bastibe]

If I remember correctly, frombuffer is supposed to use buffer objects directly, so we can skip the bytes conversion (which also incurs another unnecessary copy).

[mehran-mousavi]

Thank you for the review. You are right that in principle numpy.frombuffer can consume buffer objects directly without converting to bytes. I initially tried that approach, but in practice it produced corrupted audio on Windows 11 with modern NumPy (≥2.x). The recorded stream would play back with a “robotic” or distorted sound.

After some investigation, the root cause was that the raw ffi.buffer object was not being interpreted consistently as a contiguous float32 array. Converting it explicitly to bytes ensured that NumPy saw a well‑defined, contiguous block of memory. Adding .copy() then guaranteed that the resulting array was writable, which is required because the downstream code modifies the buffer (chunk[:] = 0).

So the combination of bytes(...) + frombuffer(...).copy() was the minimal change that both restored correct audio playback and maintained compatibility with the updated NumPy API. Without the conversion step, the audio artifacts reappeared.

If you prefer to avoid the extra copy for performance reasons, we could explore alternatives (e.g. ensuring the ffi.buffer is exposed as a writable, contiguous memoryview), but the current patch was the most reliable fix we found to resolve the distortion issue across environments.

Audio Adapter:
Intel 5 Series/34x0 Chipset PCH - High Definition Audio Controller [B3]

Audio Controller Hardware ID: PCI\VEN_8086&DEV_3B56&SUBSYS_1520103C&REV_06

Windows 11 Pro 25H2 / OS Build : 26200.7019

[bastibe]

This looks dubious to me. We probably should at least issue a warning that we're skipping the format checking here.

Unless the whole formatting checks are unnecessary, in which case we can always skip them. But I don't know enough about this API to make that decision, really. Do you know more?

[bastibe]

If there's a data discontinuity, the user must be warned. It means they're losing data, and it usually means they need to reduce their processing or increase buffer sizes. We can't skip this.