microsoft/VibeVoice · error · ValueError

Audio duration ({duration_sec:.1f}s) exceeds the configured

Error message

Audio duration ({duration_sec:.1f}s) exceeds the configured limit ({_MAX_AUDIO_DURATION:.0f}s). Set the VIBEVOICE_MAX_AUDIO_DURATION environment variable to adjust this limit, or use shorter audio.

What it means

A pre-tensorization guard that rejects audio longer than the configured cap. Duration is computed as len(audio_waveform) / 24000 against _MAX_AUDIO_DURATION (overridable via the VIBEVOICE_MAX_AUDIO_DURATION environment variable). The check exists to fail fast before encoder forward passes allocate memory and OOM the GPU on very long clips.

Source

Thrown at vllm_plugin/inputs.py:87

        # Load from file path
        audio_waveform = load_audio(data)
        
    elif isinstance(data, bytes):
        # Decode bytes directly via ffmpeg stdin pipe to avoid temp-file IO
        audio_waveform, _sr = load_audio_bytes_use_ffmpeg(data, resample=True, target_sr=24000)
        normalizer = AudioNormalizer()
        audio_waveform = normalizer(audio_waveform)
                
    elif isinstance(data, np.ndarray):
        # Already loaded numpy array
        audio_waveform = data
    else:
        raise ValueError(f"Unsupported audio data type: {type(data)}")

    # Validate audio duration before tensor conversion to catch OOM early
    duration_sec = len(audio_waveform) / 24000
    if duration_sec > _MAX_AUDIO_DURATION:
        raise ValueError(
            f"Audio duration ({duration_sec:.1f}s) exceeds the configured "
            f"limit ({_MAX_AUDIO_DURATION:.0f}s). Set the "
            f"VIBEVOICE_MAX_AUDIO_DURATION environment variable to adjust "
            f"this limit, or use shorter audio."
        )

    # Convert to tensor
    audio_tensor = torch.from_numpy(audio_waveform).float()
    audio_length = audio_tensor.shape[0]
    
    return MultiModalInputs({
        "audio": audio_tensor,
        "audio_length": audio_length
    })

View on GitHub (pinned to 94da20d98b)

Solutions

Chunk the audio client-side into segments under the limit and transcribe each.
Resample the array to 24 kHz before submission so the duration math is correct (the ndarray path does NOT resample for you).
Raise the cap when memory allows: start the vLLM process with VIBEVOICE_MAX_AUDIO_DURATION=<seconds> set.
Trim silence at the head/tail with ffmpeg/librosa to bring clips under the limit.

Example fix

# before
audio = librosa.load("meeting.wav", sr=48000)[0]  # 48k array, duration double-counted
inputs = {"audio": audio}

# after
audio = librosa.load("meeting.wav", sr=24000)[0]  # match the 24 kHz assumption
segs = [audio[i:i + 24000*120] for i in range(0, len(audio), 24000*120)]
inputs = [{"audio": seg} for seg in segs]  # <=120 s chunks

Defensive patterns

Strategy: validation

Validate before calling

import numpy as np
import os

MAX_DUR = float(os.environ.get("VIBEVOICE_MAX_AUDIO_DURATION", 120))  # match deployment
SR = 24000

def check_duration(wave: np.ndarray):
    assert wave.ndim == 1, "expected 1-D waveform"
    dur = len(wave) / SR
    if dur > MAX_DUR:
        step = int(MAX_DUR * SR * 0.95)
        return [wave[i:i+step] for i in range(0, len(wave), step)]
    return [wave]

Type guard

def is_within_duration(wave: np.ndarray, max_dur: float) -> bool:
    return len(wave) / 24000 <= max_dur

Try / catch

try:
    out = llm.generate(prompt, multi_modal_data={"audio": wave})
except ValueError as e:
    if "exceeds the configured limit" in str(e):
        results = [llm.generate(prompt, {"audio": seg}) for seg in chunk(wave)]
    else:
        raise

Prevention

Always resample to 24 kHz before submission — the ndarray path assumes it.
Chunk long recordings at the ingestion layer instead of relying on the server error.
Record the deployment's VIBEVOICE_MAX_AUDIO_DURATION in your client config so both sides agree.

When it happens

Trigger: Submitting any clip whose sample count exceeds _MAX_AUDIO_DURATION * 24000; an ndarray supplied at a sample rate other than 24 kHz (e.g. 48 kHz audio makes len()/24000 overestimate duration 2x and can trip the limit spuriously); whole-file ingestion of podcasts/lectures/meetings that exceed the default cap.

Common situations: Long-form transcription use cases; users feeding 44.1/48 kHz arrays because the ndarray branch skips resampling (unlike the bytes branch); environments where the operator did not know the limit is env-tunable.

Related errors

AI-assisted analysis of microsoft/VibeVoice@94da20d98b (2026-08-15). Data as JSON: /api/errors/2c1a14ddab6d4f04. Report an issue: GitHub.