MPS word timestamp failure due to .double() conversion order

[janngobble]

Summary
When running Whisper on Apple Silicon using the MPS backend with --word_timestamps True, transcription fails because the code attempts to convert an MPS tensor to float64 before moving it to the CPU.
Changing the conversion order fixes the problem while preserving the original intent of performing the DTW calculation in double precision.

Environment
macOS (Apple Silicon)
Python 3.12.13
PyTorch 2.12.1
OpenAI Whisper 20250625
MPS backend enabled

Reproduction
Run Whisper with:

whisper \
  --device mps \
  --word_timestamps True \
  --model tiny.en \
  input.m4v

Whisper aborts with:
TypeError: Cannot convert a MPS Tensor to float64 dtype as the MPS framework doesn't support float64. Please use float32 instead.

The failure occurs in whisper/timing.py:

return dtw_cpu(x.double().cpu().numpy())

The call to .double() executes while the tensor is still resident on the MPS device, but MPS does not support float64.

Proposed fix
This code path is already invoking dtw_cpu(), so the tensor is destined for the CPU. Reordering the operations simply avoids requesting an unsupported float64 conversion while the tensor is still on the MPS device.

Move the tensor to the CPU before converting to double precision:

whisper/timing.py (around line 151 in Whisper 20250625)

- return dtw_cpu(x.double().cpu().numpy())
+ return dtw_cpu(x.cpu().double().numpy())

This preserves the original use of double precision for the CPU DTW implementation while avoiding the unsupported MPS conversion.

Validation
After applying this one-line change:

• the MPS TypeError no longer occurs;
• --word_timestamps True completed successfully on my Apple Silicon test system using the MPS backend;
• generated SRT output is structurally valid (sequential cue numbers, valid timestamps, no overlaps);
• DTW still executes using float64 on the CPU exactly as originally intended.

If this approach looks acceptable, I'm happy to open a pull request containing this one-line change.

Scope: This change does not attempt to address separate MPS decoder stability issues (such as NaN logits with larger models), which appear to be a separate issue based on my testing and should be tracked independently (Discussion #2693).