fix(qwen-asr): enable timestamp output when forced_aligner is configured

[fqscfqj]

Problem

The qwen-asr backend loads the forced_aligner model correctly but never actually produces timestamps. All segments return start=0, end=0.

Two bugs cause this:

Bug 1: return_time_stamps not passed to transcribe()

Qwen3ASRModel.transcribe() defaults return_time_stamps=False. The backend never passes True, so the forced aligner is loaded but silently skipped during inference.

Bug 2: Timestamp item format mismatch

The parsing code checks isinstance(ts, (list, tuple)), but qwen_asr returns ForcedAlignItem dataclass instances with .text, .start_time, .end_time attributes — not tuples. The check always fails, so timestamps are zeroed out even if Bug 1 were fixed.

Fix

1. Pass return_time_stamps=True to transcribe() when a forced_aligner is loaded.
2. Add hasattr() check for ForcedAlignItem dataclass before falling back to tuple parsing.

Testing

Verified against qwen3-asr-0.6b with Qwen/Qwen3-ForcedAligner-0.6B — timestamps now return correctly in verbose_json, srt, and vtt formats.

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Adds support for returning and parsing word/segment timestamps when the Qwen ASR forced aligner is available.

Changes:

• Detects presence of a forced aligner and requests timestamps from model.transcribe.
• Adds parsing for forced-aligner timestamp objects (start_time, end_time, text) in addition to tuple/list timestamps.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[fqscfqj]

Additional fix: seconds → nanoseconds

While testing this PR against a real deployment, I discovered a third issue beyond the two bugs described above:

Bug 3: Timestamp unit mismatch between Python backend and Go server

The Go server reads (int64) and wraps them in :

// core/backend/transcript.go
segments = append(segments, &schema.TranscriptSegment{
    Start: time.Duration(s.Start),
    End:   time.Duration(s.End),
})

Go's time.Duration is in nanoseconds, but the backend was sending milliseconds (* 1000). This caused timestamps to be 1000x too small — e.g. 8e-8 seconds instead of 0.08 seconds.

Fix: Convert seconds → nanoseconds (* 1_000_000_000) instead of seconds → milliseconds (* 1000).

Verified output

After applying all three fixes, verbose_json, srt, and vtt formats all produce correct timestamps:

{"segments": [{"id": 0, "start": 0.08, "end": 0.24, "text": "今"}, ...]}

1
00:00:00,080 --> 00:00:00,240
今

Pushed the additional commit to the PR branch.