InfiniteTalk Auto Sampler (Advanced)

If you landed here, you probably already know whether you need this node, and the honest answer for most people is: you don't. The regular InfiniteTalk Auto Sampler from this same pack does all the InfiniteTalk work with a plain KSampler interface, and it's the one beginners should use. The Advanced variant is the same lip-sync pipeline with one difference: instead of seed/steps/sampler_name/scheduler/denoise, it takes noise (NOISE), sampler (SAMPLER), and sigmas (SIGMAS) objects. That's it. It exists because the frame-extension trick deserves to work with whatever sampling machinery you already have wired into a graph - custom noise generators, custom samplers, bespoke sigma schedules - rather than being locked to the built-in KSampler options.

What it is

It's the advanced sibling in vjumpkung/comfyui-infinitetalk-native-sampler, a tiny native ComfyUI implementation of InfiniteTalk - MeiGen-AI's audio-driven talking-head model that rides on Wan 2.1. Where the standard node lets you pick sampler_name from a dropdown, this one accepts a SAMPLER object (say, from a "SamplerCustom" or your own sampler node) and a SIGMAS schedule, and derives steps from the schedule itself (sigmas.shape[-1] - 1). The sampler machinery is swapped out; the InfiniteTalk logic is identical.

How it works

Everything that makes InfiniteTalk tick lives in the shared code, not the node variant: it counts frames from audio duration × framerate, runs a base pass of length frames, then chains extend passes where the last motion_frame_count frames are VAE-encoded as motion conditioning for the next chunk. Pass count is 1 + ceil((total_frames - length) / (length - motion_frame_count)), and it accumulates pixel frames rather than latents to keep Wan's causal VAE happy. The only difference in the Advanced node's execution is that each pass samples through a CFGGuider fed your noise, sampler, and sigmas instead of calling the built-in KSampler path. It also does an explicit memory cleanup between extend passes - per-pass model clones otherwise grow the loaded-models list and your RAM climbs linearly with audio length.

The inputs that matter

• noise, sampler, sigmas - the three required objects replacing the standard sampler controls. Feed them from whatever custom sampling nodes you already use; the node respects your sigma schedule's step count.
• cfg (default 1.0) - still here, applied through the CFGGuider.
• length (default 81) - frames per pass and your main VRAM control. Lower it when you OOM.
• motion_frame_count (default 9) - conditioning frames carried between passes.
• framerate (default 25) - output fps, also drives audio resampling.
• audio_scale (default 1.0) - the lip-sync strength dial.

Required wiring otherwise matches the standard node: model (Wan 2.1), model_patch (the InfiniteTalk weights), positive/negative, vae, audio_encoder_output_1, and audio. Optional start_image, clip_vision_output, and the multi-speaker set audio_encoder_output_2 + mask_1 + mask_2 - the node validates that those come as a group. Outputs are images and audio, wired straight into a SaveVideo node.

Installing

Identical to the standard node - it ships in the same pack. ComfyUI Manager, search infinitetalk-native-sampler, or:

cd ComfyUI/custom_nodes
git clone https://github.com/vjumpkung/comfyui-infinitetalk-native-sampler

Restart ComfyUI. No pip dependencies; it needs a recent ComfyUI with the v3 extension format and comfy.ldm.wan.model_multitalk. It downloads no models - you bring the Wan 2.1 base, the InfiniteTalk patch (sample workflow uses wan2.1_infiniteTalk_single_fp16.safetensors), and a wav2vec2-base encoder.

Troubleshooting

The same issues as the standard node, because it's the same pipeline: "Audio encoder output dimensions do not match" means your encoder isn't wav2vec2-base (needs 12 blocks / 768 channels to match the patch); "length must be greater than motion_frame_count" means you set the two at odds; and the "Input type (float) and bias type (c10::Half)" crash is the known wav2vec2-in-fp16 bug. The README claims the pack auto-patches that at startup - but the shipped repo contains no such patch, so load the encoder in fp32 instead of trusting it.

If you're still deciding between the two nodes: if you can't explain, out loud, why you need a custom SIGMAS schedule, use the standard node. This one is for the people who already have custom sampler plumbing and just want InfiniteTalk's auto-extension bolted onto it.