DEV Community

Nariaki Wada
Nariaki Wada

Posted on

Can MeanVC Stream 200 ms Voice Conversion in Real Time on an M1 Max? 37.7 ms p95

Hello, everyone.

It would be interesting if a Mac could keep what I say while changing only the characteristics of my voice, all locally and in real time.

Today, I am testing MeanVC's 200 ms streaming model on an Apple M1 Max. I will measure processing speed, the shift in speaker characteristics, and discontinuities between audio chunks.

The short answer is that one CPU thread converted a 200 ms audio chunk in 37.7 ms at p95. All 99 measured chunks finished before the next chunk arrived, and the converted voice became more similar to the target reference than to the source speaker. However, estimated time to the first output was about 0.28–0.37 seconds.

What Is MeanVC?

MeanVC is a lightweight streaming zero-shot voice conversion model whose paper was published on October 9, 2025. Voice conversion changes vocal characteristics while preserving the spoken content. Zero-shot means that a target speaker can be specified from reference audio without training a separate model for that speaker.

MeanVC divides audio into short chunks and carries context forward while converting them. It also uses MeanFlow to move from noise to generated audio features in a small number of steps. I used the officially released 200 ms model with two inference steps.

The published MeanVC code and pretrained model use the Apache License 2.0. It permits use, modification, and redistribution subject to conditions such as preserving copyright and license notices. The original WavLM implementation uses the MIT License, while S3PRL, which loads WavLM here, uses Apache License 2.0. The evaluation-only ECAPA-TDNN ONNX model uses the MIT License.

Model Roles and Data Flow

The conversion path uses four pretrained models.

Model Role
Fast-U2++ Extracts linguistic content features from the source audio
WavLM speaker encoder Extracts target-speaker characteristics from the reference
MeanFlow DiT Generates a converted audio spectrogram from the content and speaker features
Vocos Decodes the generated spectrogram into a playable waveform

The data flows as follows.

target reference -> WavLM + mel features ----┐
                                             v
source -> 200 ms chunks -> Fast-U2++ -> MeanFlow DiT -> Vocos -> converted audio

evaluation only:
source / target / converted -> ECAPA-TDNN -> compare speaker-feature distances
Enter fullscreen mode Exit fullscreen mode

Mel features describe energy at different frequencies on a scale closer to human hearing. ECAPA-TDNN is not involved in conversion. I used it only to check whether an independent model also saw a shift toward the target speaker.

What I Tested

The experiment asks three questions.

  • Can each 200 ms chunk finish before the next one arrives?
  • Do the converted speaker features move closer to the target than the source?
  • Do the 200 ms boundaries create large waveform discontinuities?

The complete code, pinned model revisions, SHA-256 hashes, and JSON report are available in the meanvc-streaming-apple-silicon lab in kiarina/labs.

Reproducing the Lab

You will need mise, uv, FFmpeg, and an internet connection for the initial download. The first run downloads about 2.7 GiB of models and related files.

git clone --depth 1 --filter=blob:none --sparse \
  https://github.com/kiarina/labs.git
cd labs
git sparse-checkout set .gitignore .mise/tasks Makefile mise.toml \
  2026/07/19/meanvc-streaming-apple-silicon
mise -C 2026/07/19/meanvc-streaming-apple-silicon run
Enter fullscreen mode Exit fullscreen mode

The converted WAV files and measurement report are written to output/. To try audio files or a live microphone from a browser, run:

mise -C 2026/07/19/meanvc-streaming-apple-silicon run demo
Enter fullscreen mode Exit fullscreen mode

MeanVC Voice Transfer Lab interface with source audio, target audio, and live microphone conversion

The browser tool accepts source audio to convert and target audio as the voice reference. It also includes a button for the same synthetic sample used in this experiment and a live mode that converts microphone input in 200 ms chunks. Audio is processed only on localhost and is not uploaded to an external service.

Test Conditions

I used a 14.171-second synthetic conversation between two speakers. Three turns from Speaker 1, totaling 6.588 seconds, formed the source. Three different turns from Speaker 2, totaling 7.583 seconds, formed the target reference. No utterance appeared in both sets.

The main conditions were:

Item Condition
Mac MacBook Pro, Apple M1 Max, 64 GB
Execution PyTorch CPU, one thread
Audio 16 kHz, mono
Chunk 245 ms first, then 200 ms
MeanFlow Two steps
Measurement 33 chunks × 3 trials, 99 chunks total

Instead of a physical microphone, the lab fed an audio file incrementally in microphone order. This measures model compute time but excludes buffering in the microphone, virtual audio device, and speakers.

Results

200 ms Converted in 37.7 ms at p95

Metric Observed
200 ms chunk inference p50 35.1 ms
200 ms chunk inference p95 37.7 ms
200 ms chunk inference p99 38.0 ms
Maximum 38.4 ms
Deadline misses 0 / 99 chunks
Peak resident memory 2,849 MB

p95 means that 95% of measurements were at or below that value. Here, most 200 ms chunks finished within 37.7 ms. That left about 162 ms before the next chunk arrived, and the model never fell behind during the measurement.

The first sound still has to wait for the initial 245 ms of input and its inference. Estimated first-output latency was 277 ms at p50, 359 ms at p95, and 368 ms at maximum. Continuous processing has ample compute headroom, but this is not a 20–100 ms low-latency voice changer.

Speaker Features Shifted Toward the Target

ECAPA-TDNN represented each audio sample as 192 numbers, and I compared them with cosine similarity. A value closer to one means that the model considers the speaker characteristics more similar.

Pair Similarity
Source − target reference 0.210
Converted − source 0.320
Converted − target reference 0.725

The converted voice was clearly closer to the target reference than to the source. Individual cross-speaker turns averaged 0.175, so 0.725 was a substantial shift for this sample.

This score alone does not mean “the same person” or “natural speech.” Naturalness, pronunciation, and listener judgments of identity require separate evaluation.

No Large Discontinuity Found at 200 ms Boundaries

I measured the sample-value difference across 32 chunk boundaries. Boundary differences had a p95 of 0.0462, while ordinary adjacent differences across the full audio had a p95 of 0.0567. The boundaries were not systematically larger. The converted waveform also contained 0% clipped samples.

This is a waveform check, not a human listening test for click noise.

A Plain-Language Reading of the Results

  1. The M1 Max CPU converted audio faster than it arrived.

Each 200 ms of speech took about 35–38 ms to process, and all 99 chunks met their deadline. The compute speed is suitable for applications such as streaming or online meetings that can tolerate some delayed output.

  1. The voice moved in the target speaker's direction.

An independent speaker model also found the converted audio more similar to the target than the source. This does not establish naturalness or pronunciation quality.

  1. “Real-time processing” is not the same as “imperceptible latency.”

Sustained conversion was fast, but the first output took about 0.28–0.37 seconds. That delay may be very noticeable when monitoring your own voice through headphones.

A Note on Japanese

The MeanVC paper trained the conversion model primarily on Mandarin speech. Fast-U2++, which extracts content, was also trained on the Mandarin-centered WenetSpeech dataset. The Japanese input used here is outside the main language conditions evaluated in the paper.

Japanese features such as geminate consonants, long vowels, and pitch accent may not be fully preserved. With one Japanese input and one speaker pair, this experiment cannot isolate language-related degradation. For the reference, clean single-speaker audio with little noise or reverberation is the safest starting point.

Limitations and Responsible Use

  • The evaluation used one short Japanese conversation and one speaker pair.
  • It did not measure full microphone-to-speaker latency.
  • It did not run listening tests for naturalness, intelligibility, or pronunciation preservation.
  • It did not test noise, singing, laughter, whispering, or long sessions.
  • It used PyTorch CPU, not MPS, ONNX, or Core ML.

Voice conversion should only use audio whose speaker has consented to both its processing and intended use. This experiment used a synthetic conversation from shared test assets and did not create a model that imitates a real person.

My Takeaway

Because the model waits for 200 ms of input, I expected the conversion itself to be fairly heavy. In practice, one CPU thread reached 37.7 ms at p95, leaving substantial headroom for continuous processing. The independent speaker model also confirmed a shift toward the target, making this more than a speed-only demonstration.

The full zero-shot path is less lightweight than the conversion core alone suggests: WavLM brings the initial download to about 2.7 GiB and peak memory to about 2.8 GB. Even so, MeanVC could work well for local streaming effects or prototyping character voices with consent when a modest delay is acceptable.

Top comments (0)