Meetily v0.3.0 crashes silently on pre-Haswell CPUs (no AVX2) — ORT session in audio pipeline fails regardless of transcription engine

Meetily v0.3.0 crashes silently on pre-Haswell CPUs (no AVX2) — ORT session in the audio pipeline fails regardless of transcription engine selected

Summary

On Windows machines whose CPU does not support AVX2 (e.g. Intel Ivy Bridge / pre-2013 Xeon E5 v2 / older AMD), Meetily v0.3.0 closes silently the moment the user clicks Record or Import audio. The UI shows no error, no Windows dialog, no zombie process. The crash is a native STATUS_ILLEGAL_INSTRUCTION (0xC000001D) thrown inside ONNX Runtime's threadpool initialization, before any inference runs.

Critically, the crash also happens when Whisper is selected as the transcription engine, because the audio pipeline unconditionally instantiates a Silero VAD session (which loads ONNX Runtime under the hood) at the start of every recording. So switching engines from Parakeet to Whisper does not avoid the crash.

This is consistent with the symptoms described in #318 and #415.

Environment

• OS: Windows 10 Pro x64 (10.0.19045.6466)
• CPU: Intel Core i7-3770 @ 3.40 GHz (Ivy Bridge, 2012) — SSE4.2, AVX. No AVX2, no AVX-512.
• GPU: NVIDIA GeForce GTX 1050 Ti, 4 GB VRAM (CUDA + DirectCompute + Vulkan capable)
• RAM: 16 GB
• Meetily: v0.3.0 per-user install at %LOCALAPPDATA%\meetily\meetily.exe

Reproduction

1. Install Meetily v0.3.0 on a Windows x64 box without AVX2.
2. Complete onboarding, select any model (both Parakeet and Whisper reproduce).
3. Click Record (or Import audio).
4. The window closes instantly. No error in UI.

Root cause

ONNX Runtime ≥ 1.18 for Windows x64 (the version pulled in by ort = "2.0.0-rc.10") is built with AVX2 as the CPU baseline. The threadpool init in Microsoft.ML.OnnxRuntime.dll executes AVX2 instructions unconditionally during Session construction, before any execution provider runs. Pre-Haswell CPUs raise an illegal-instruction exception and Windows kills the process.

Because Meetily compiles with the GUI subsystem, no stderr is shown. Reproducing from cmd with stdout/stderr redirected confirms the crash point.

Logs (cut at the crash point, identical in both runs)

Parakeet selected — crashes on Record:

[INFO  app_lib::parakeet_engine::model] Loading quantized Parakeet model from
  encoder-model.int8.onnx...
[INFO  ort::execution_providers] Successfully registered `CPUExecutionProvider`
[INFO  ort::logging] Adding OrtHardwareDevice
  {vendor:GenuineIntel, Description=Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz}
[INFO  ort::logging] Session Options { graph_optimization_level:3 ... }
[INFO  ort::logging] Dynamic block base set to 0
<<< process dies here, no further output >>>

Whisper selected — Whisper loads fine, then crashes when Record is pressed:

[INFO  app_lib::whisper_engine] Successfully loaded model: medium-q5_0 ...
[INFO  app_lib::audio::transcription::engine] ✅ Whisper model validation successful
[INFO  app_lib::audio::recording_commands]  Starting async recording initialization
[INFO  app_lib::audio::pipeline] ️ AudioPipeline initializing with device characteristics
[INFO  ort::logging] Adding OrtHardwareDevice
  {vendor:GenuineIntel, Description=Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz}
[INFO  ort::logging] Session Options { execution_mode:0 ... thread_pool_size:4 ... }
[INFO  ort::logging] Dynamic block base set to 0
<<< process dies here, no further output >>>

Logs were captured with:

"%LOCALAPPDATA%\meetily\meetily.exe" > "%USERPROFILE%\Desktop\meetily.log" 2>&1

Windows Event Viewer (Aplicación log) shows the matching Application Error event for meetily.exe with exception code 0xC000001D (STATUS_ILLEGAL_INSTRUCTION).

Where in the source

There are two independent ORT call sites that both crash on non-AVX2 hardware:

1. frontend/src-tauri/src/audio/vad.rs:61 — VadSession::new(config) silero-rs wraps ONNX Runtime and is instantiated for every recording regardless of which transcription engine the user picked. This is the path the Whisper run dies on.

2. frontend/src-tauri/src/parakeet_engine/model.rs:91–117 — Session::builder().with_execution_providers([CPUExecutionProvider]). Dies during Parakeet model load.

The VAD instantiation in audio/pipeline.rs:729 panics on error, but in practice the process is already dead by the time the Result would be returned — the AVX2 fault is uncatchable from Rust.

Why graceful error handling alone is not enough

STATUS_ILLEGAL_INSTRUCTION is a CPU-level fault. By the time Rust would see an Err, the process is gone. The only way to prevent the crash on pre-Haswell machines is to avoid calling into ORT in the first place when AVX2 is not detected. A pre-flight std::is_x86_feature_detected!("avx2") check is required.

Proposed fix

A complete patch is attached in this issue's discussion (or available on request). The shape of the fix:

1. Pre-flight CPU capability check + energy-based VAD fallback

In audio/vad.rs:

• Add is_x86_feature_detected!("avx2") check at the top of ContinuousVadProcessor::new.
• If AVX2 is absent on x86_64, skip Silero and use an energy-based RMS VAD that produces compatible SpeechSegments.
• If AVX2 is present, behaviour is unchanged.

This single change makes recording + Whisper transcription work on pre-Haswell CPUs.

2. Pre-flight CPU capability check in Parakeet engine

In parakeet_engine/model.rs, return ParakeetError::Unsupported with a clear message when AVX2 is unavailable instead of crashing during Session::builder(). The model picker UI can then disable Parakeet and steer the user to Whisper.

3. Optional: DirectML execution provider for the GTX 1050 Ti and similar

For users with a DX12 GPU, registering DirectMLExecutionProvider first in the EP list would offload inference to GPU and bypass the AVX2 problem for Parakeet too. Requires building ort with features = ["directml"].

4. Optional: load-dynamic for swappable ORT DLL

Switching ort to features = ["load-dynamic"] (and dropping download-binaries) would let advanced users provide their own onnxruntime.dll built without AVX2 baseline.

Severity / impact

• Pre-Haswell silently-crashing install is the worst possible UX — users report the app "doesn't open" when it does open and then dies.
• The audience affected is older but non-trivial: refurbished/SOHO desktops, lab boxes, low-cost VMs.
• Fix is small (~80 lines) and entirely additive.

Related issues

• #318 — "Transcription model not ready — app forces you to have Parakeet Lightning installed". Likely same root cause: ORT init crashes on machines without AVX2.
• #415 — "Unable to get transcription or audio segment with Whisper". Matches the secondary-ORT-in-pipeline hypothesis.

Workaround until fixed

No software workaround exists for pre-Haswell users (the bundled ORT DLL cannot be swapped without rebuilding). Users in this situation have to rebuild Meetily from source with the patch above, or fall back to alternative local-transcription stacks (Buzz, WhisperDesktop, faster-whisper).

Happy to send the patch as a PR if a maintainer signals it would be welcome.