Add support for Apple Silicon and PyTorch device configuration

[openoms]

Enhance transcription configuration by adding support for specifying the PyTorch device and integrating MLX Whisper for Apple Silicon, allowing users to choose between ASR backends.

btop evidence of Mac M1 GPU usage:

[openoms]

@blink-claw-bot review

[blink-claw-bot]

PR Review: Add support for Apple Silicon and PyTorch device configuration

Nice addition — MLX Whisper support for Apple Silicon is a solid feature. The abstraction into _transcribe_asr is the right approach. Tests are well-structured. A few issues to address:

---

HIGH

1. Double model load in dual-channel mode (performance regression)

_transcribe_asr() loads and deletes the whisperx model on every call. In _transcribe_dual_channel, it's called twice (mic + system channel). Previously, the model was loaded once and reused for both channels.

This doubles model load time for dual-channel whisperx transcription — that's a multi-second regression on GPU and much worse on CPU.

Suggestion: Either:

• Accept a pre-loaded model as an optional param to _transcribe_asr, or
• Split into _load_asr_model() / _run_asr() so dual-channel can reuse the model, or
• Cache the model within _transcribe_asr for the whisperx path (less clean)

2. whisperx remains a hard dependency even with MLX backend

The mono transcribe() function still calls whisperx.load_audio() unconditionally (line ~1008 in the new code). This means whisperx must be installed even when using MLX as the ASR backend. If someone installs only the [mlx] extra on Apple Silicon without whisperx, it will crash.

Is this intentional? If so, the README should clarify that whisperx is still required (MLX only replaces the transcription step, not audio loading/alignment/diarization). If not, load_audio needs an alternative path for MLX-only installs.

---

MEDIUM

3. VAD options silently ignored with MLX backend

_transcribe_asr() uses config.vad_onset / config.vad_offset for whisperx but silently ignores them for MLX. If a user passes --vad-onset / --vad-offset with --asr-backend mlx, they get no feedback that their settings have no effect.

Suggestion: Log a warning when VAD options are set but the MLX backend is active.

4. _empty_torch_cache swallows all exceptions

except Exception:
    pass

Per project conventions (and general best practice), catch-and-ignore is a code smell. For cache cleanup it's less critical, but at minimum log the exception at DEBUG level so failures are diagnosable.

5. Redundant double cache clear

After ASR in both mono and dual paths:

_empty_torch_cache(torch, config.device)
_empty_torch_cache(torch, config.torch_device)

When torch_device defaults to device (the common case), this clears the same cache twice. Add a guard:

_empty_torch_cache(torch, config.device)
if config.torch_device != config.device:
    _empty_torch_cache(torch, config.torch_device)

---

LOW / nits

6. nit: _transcribe_asr uses print() for status messages. Consistent with existing code, but worth noting for a future logging pass.

7. nit: _mlx_available() imports importlib.util inside the function. Since importlib.util is stdlib and always available, this could be a top-level import. The defensive try/except around it is unnecessary.

8. nit: Test test_transcribe_asr_normalizes_mlx_result passes "audio.wav" (a string) as the audio argument. In production, the MLX path in dual-channel receives a numpy array. Consider adding a test case with a numpy-like input to validate both code paths.

---

What's good

• Clean separation of ASR backends via _transcribe_asr()
• _empty_torch_cache properly handles MPS device
• Auto-detection logic (_apple_silicon() + _mlx_available()) is sensible
• MLX model alias mapping is complete and well-structured
• Test coverage is solid: config validation, auto-detection, monkeypatched backend tests
• README docs are clear and well-placed

Verdict: Request changes — the dual-channel model reload regression (#1) needs to be fixed before merge. The whisperx dependency story (#2) needs at least a documentation clarification.

🤖 Review by Claude Opus 4 via Blink-Claw-Bot

[openoms]

@blink-claw-bot review with the new changes addressing the previous comments

[pretyflaco]

Verdict

Approve. Solid, well-scoped Apple Silicon / MLX integration with good test coverage. Happy to merge after one small follow-up below.

What's good

• Clean ASR-backend abstraction in _transcribe_asr (meet/transcribe.py:771).
• Dual-channel WhisperX model reuse fix (meet/transcribe.py:860) — addresses prior review feedback about double model load.
• Torch device split for alignment/diarization throughout the pipeline (meet/transcribe.py:1076).
• MLX model alias map and auto-detect logic (_apple_silicon, _mlx_available, _MLX_MODEL_ALIASES).
• VAD-options-ignored warning under MLX backend (meet/transcribe.py:781).
• README clarifies that MLX only replaces transcription; WhisperX remains required for audio loading, alignment, and diarization (README.md:176).
• Tests cover MLX result normalization, MLX VAD warning, dual-channel WhisperX model reuse, and config validation (tests/test_transcribe.py).

One small ask before merge

On macOS / Apple Silicon, the CLI --device still defaults to cuda (meet/cli.py:208 and meet/cli.py:471). Combined with auto-MLX selection at meet/transcribe.py:432, a Mac user running meet transcribe file.wav with no flags will hit whisperx.load_align_model(..., device="cuda") (meet/transcribe.py:1076) and fail.

Could you add a short pre-flight notice in both the transcribe and run commands when _apple_silicon() is True and device == "cuda", suggesting --device cpu --torch-device mps? Roughly:

from meet.transcribe import _apple_silicon
if _apple_silicon() and device == "cuda":
    click.echo(
        "Note: detected Apple Silicon. CUDA is not available on macOS — "
        "re-run with `--device cpu --torch-device mps` for best results.",
        err=True,
    )

This keeps the "Apple Silicon support" claim honest without changing global defaults. It belongs in this PR's scope since it's part of the Apple Silicon UX you're adding.

Everything else (auto-defaulting device on Darwin, GUI exposure of --asr-backend / --torch-device / --mlx-model, CI workflow, runtime validation of torch_device, always-on MLX VAD note) we'll handle as separate follow-up issues on our side — no need to expand this PR.

Thanks for the contribution and the btop screenshot proof of M1 GPU usage.