Unable to Use Silero-VAD on Raspberry Pi with PyTorch ≥ 2.9.0 Due to torchcodec Dependency (AArch64 Not Supported)

[jonatlr]

Description

Hi,
I’m running Silero-VAD on a Raspberry Pi 5 (AArch64, Python). Everything works properly when I use PyTorch 2.8.0, but upgrading to PyTorch 2.9.0 breaks the pipeline because the new version of PyTorch attempts to import torchcodec, which is not available for AArch64 architectures.

Because torchcodec is a required dependency starting from PyTorch 2.9, Silero-VAD becomes unusable on Raspberry Pi unless PyTorch is manually downgraded to 2.8.0. This effectively prevents running the latest PyTorch releases on ARM SBCs.

What Works (PyTorch 2.8.0)

With PyTorch 2.8.0, Silero-VAD loads and runs inference correctly.
The only issue is the following warning:
silero_vad/utils_vad.py:143: UserWarning: torchaudio.sox_effects.sox_effects.apply_effects_file has been deprecated. This deprecation is part of a large refactoring effort to transition TorchAudio into a maintenance phase. It will be removed from the 2.9 release. wav, sr = torchaudio.sox_effects.apply_effects_file(path, effects=effects)

This is only a warning, and VAD works as expected.

What Fails (PyTorch 2.9.0)

With PyTorch 2.9.0, Silero-VAD fails to initialize because it tries to import torchcodec, which is not shipped for AArch64. Since the Raspberry Pi relies on AArch64 wheels, there is currently no way to satisfy this dependency.

As a result, Silero-VAD cannot run at all on Raspberry Pi unless PyTorch is downgraded.

Environment

• Raspberry Pi 5
• Raspberry Pi OS (64-bit)
• Python version: 3.11
• PyTorch 2.8.0 (works)
• PyTorch 2.9.0 (fails due to missing torchcodec)

Expected Behavior

Silero-VAD should either:

1. Continue working on AArch64 systems under PyTorch ≥ 2.9, or
2. Provide a fallback path when torchcodec is unavailable, or
3. Document version constraints or ARM limitations if support is not intended.

Actual Behavior

• PyTorch 2.9 requires torchcodec
• torchcodec is not available for AArch64
• Silero-VAD fails to import / run on Raspberry Pi
• Only PyTorch 2.8.0 remains usable, and the deprecated sox_effects call will break in the next release

Additional Notes

This issue affects a large portion of makers / embedded users who run Silero-VAD on Raspberry Pi or other ARM SBCs.
If Silero-VAD relies on torchaudio preprocessing that’s being deprecated, the upcoming removal of sox_effects.apply_effects_file may cause additional breakage even on PyTorch 2.8.

Thanks for your work on this project—it's extremely useful for small, low-power devices like the Raspberry Pi.

[snakers4]

Hi,

I’m running Silero-VAD on a Raspberry Pi 5 (AArch64, Python). Everything works properly when I use PyTorch 2.8.0, but upgrading to PyTorch 2.9.0 breaks the pipeline because the new version of PyTorch attempts to import torchcodec, which is not available for AArch64 architectures.

Did you install silero-vad with pip?

PyTorch 2.9 requires torchcodec
Because torchcodec is a required dependency starting from PyTorch 2.9, Silero-VAD becomes unusable on Raspberry Pi unless PyTorch is manually downgraded to 2.8.0. This effectively prevents running the latest PyTorch releases on ARM SBCs.
With PyTorch 2.9.0, Silero-VAD fails to initialize because it tries to import torchcodec, which is not shipped for AArch64. Since the Raspberry Pi relies on AArch64 wheels, there is currently no way to satisfy this dependency.

Technically, torchaudio depends on torchcodec, not the pytorch itself.

Raspberry Pi 5
Raspberry Pi OS (64-bit)
Python version: 3.11
PyTorch 2.8.0 (works)
PyTorch 2.9.0 (fails due to missing torchcodec)
Expected Behavior
Silero-VAD should either:
Continue working on AArch64 systems under PyTorch ≥ 2.9, or
Provide a fallback path when torchcodec is unavailable, or
Document version constraints or ARM limitations if support is not intended.

The pip-package depends on torchaudio because it contains some minimal example starter code (with resampling).

torchaudio was nice, because it provided a one-stop for audio loading and resampling and relied on proper lightweight bindings for sox. Torchcodec is not so bad, if cooked properly (except for relying on ffmpeg, which may be problematic).

So if we replace torchaudio with soundfile or PyAV, then we will also have to add some dependency for resampling, which sucks.

In your particular case, I would recommend just loading silero-vad model from the repository directly (via git or via torch.hub.load) and / or using onnx-runtime.

If you have a better idea how to gracefully handle this in a future-proof way, we are open to contributions. The following options are suboptimal, imho:

• Detect the absence of torchcodec and raise an error;
• Add resampling code to the repo and replace torchaudio with soundfile / pyAV;
• Somehow detect wrong sample rate and raise an error;

An ideal solution would be the existence of a proper python sox wrapper. I have seen some projects, but they look like they just do something like opening a subprocess.

[jonatlr]

Hi,

Thanks for the answer. To answer your question: Yes, I used pip to install silero-vad.

I don't have a specific technical recommendation as I am quite inexperienced in this domain, but I can share my thoughts on the situation:

• I understand from discussions like pytorch/audio#3902 that torchaudio is currently a moving target (removing soundfile and sox), which seems to complicate things.
• Regarding the resampling dependency: while it is certainly convenient that silero-vad handles this, I feel it might be acceptable if the library raised an error only when resampling is actually attempted (if dependencies are missing). This would make the package less dependent on external libraries for users who just need the core VAD inference and handle audio processing elsewhere.

For now, I am not blocked. I can either stick to PyTorch 2.8.0 or follow your advice to load the model via torch.hub / ONNX.

Thanks again for the help!

[snakers4]

I am still hesitant on how to handle this properly.

[antimora]

I am still hesitant on how to handle this properly.

Hopefully, Burn can help you here. Burn has no_std support, meaning the library can be built with no standard library typically used with embedded devices such as Raspberry Pi.