Aarch64 Support

[snmabaur]

Hi

I'm working on a Nvidia Spark DGX Linux spark-a3be 6.17.0-1008-nvidia #8-Ubuntu SMP PREEMPT_DYNAMIC Wed Jan 21 17:56:56 UTC 2026 aarch64 aarch64 aarch64 GNU/Linux

And when I use pyannote/speaker-diarization-community-1 I get the following error

Model initialization error" error="diarization model pyannote: failed to setup PyAnnote environment: uv sync failed: exit status 2: Resolved 136 packages in 13ms\nerror: Distribution `torchcodec==0.7.0 @ registry+https://pypi.org/simple` can't be installed because it doesn't have a source distribution or wheel for the current platform\n\nhint: You're on Linux (`manylinux_2_39_aarch64`), but `torchcodec` (v0.7.0) only has wheels for the following platforms: `manylinux_2_28_x86_64`, `macosx_11_0_arm64`, `win_amd64`; consider adding \"sys_platform == 'linux' and platform_machine == 'aarch64'\" to `tool.uv.required-environments` to ensure uv resolves to a version with compatible wheels

Is it possible to add aarch64 support?

Thanks a lot

[Karen86Tonoyan]

Yes, but the snag is probably not in pyannote itself. pyannote.audio currently documents community-1 as using torchcodec for audio decoding, and the local pipeline setup goes through that dependency. On PyPI, torchcodec wheels are published for Linux manylinux_2_28_x86_64, macOS ARM, and Windows x86-64, but there is still no Linux aarch64 wheel listed. Even the current 0.10.0 release on PyPI shows x86_64 Linux wheels only, not ARM64 Linux. There is already an upstream TorchCodec feature request specifically for Linux ARM/aarch64 support. It was opened in March 2025 to track that need, and the issue text explicitly says they would need additional build, test, and FFmpeg release infrastructure. That makes this look like an upstream packaging/platform-support gap rather than a simple pyannote config tweak. There is also a later TorchCodec issue from November 24, 2025 from someone on an Nvidia DGX Spark with Ubuntu ARM64 reporting essentially the same pain point: no official aarch64 wheel, attempts to build manually, and FFmpeg-related build failures. So the gremlin is very much alive on that platform. So the honest answer is: yes, aarch64 support is possible in principle, but today it does not look officially supported by TorchCodec on Linux ARM, and that is what is breaking pyannote/speaker-diarization-community-1 on your DGX Spark. A practical reply you could send is: Thanks a lot. This seems to be blocked by torchcodec, which pyannote.audio uses for decoding in speaker-diarization-community-1. On Linux aarch64 there currently does not appear to be an official torchcodec wheel on PyPI, while x86_64 Linux, macOS ARM, and Windows wheels are available. There is already an upstream TorchCodec request for Linux ARM/aarch64 support, and another recent report from a DGX Spark user hitting the same limitation. So from the outside this looks like an upstream TorchCodec platform-support issue rather than something specific to the diarization model. If Linux aarch64 support is planned, that would unblock this use case nicely. If you want it a bit sharper and more GitHub-native, use this version: I don’t think this is a pyannote model issue per se. The failure comes from torchcodec, which currently seems not to publish Linux aarch64 wheels on PyPI. Since speaker-diarization-community-1 depends on that stack for local decoding, the pipeline cannot initialize on DGX Spark / ARM64 right now. There is already an upstream TorchCodec request for aarch64 support, plus a recent DGX Spark report with the same problem. It would be great to either add Linux ARM wheels or document an ARM-compatible installation path/workaround. The core fact here is delightfully mundane: the model is fine, the packaging is throwing a tiny architecture tantrum. śr., 11 mar 2026, 13:59 użytkownik Alex Baur ***@***.***> napisał:

…

Hi I'm working on a Nvidia Spark DGX Linux spark-a3be 6.17.0-1008-nvidia #8-Ubuntu SMP PREEMPT_DYNAMIC Wed Jan 21 17:56:56 UTC 2026 aarch64 aarch64 aarch64 GNU/Linux And when I use pyannote/speaker-diarization-community-1 I get the following error Model initialization error" error="diarization model pyannote: failed to setup PyAnnote environment: uv sync failed: exit status 2: Resolved 136 packages in 13ms\nerror: Distribution `torchcodec==0.7.0 @ registry+https://pypi.org/simple` <https://pypi.org/simple> can't be installed because it doesn't have a source distribution or wheel for the current platform\n\nhint: You're on Linux (`manylinux_2_39_aarch64`), but `torchcodec` (v0.7.0) only has wheels for the following platforms: `manylinux_2_28_x86_64`, `macosx_11_0_arm64`, `win_amd64`; consider adding \"sys_platform == 'linux' and platform_machine == 'aarch64'\" to `tool.uv.required-environments` to ensure uv resolves to a version with compatible wheels Is it possible to add aarch64 support? Thanks a lot — Reply to this email directly, view it on GitHub <#1990>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BUHB4EZ6KLXLF5ELCRINXLT4QFPLJAVCNFSM6AAAAACWOIMSXCVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZZGYZDGMZQHE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Karen86Tonoyan]

Dear Team, My name is Karenton Oyan and I am currently developing a new digital platform designed to create a trusted and safe online ecosystem for families. The concept behind the platform is to build a verified family network where parents maintain direct responsibility for moderation and digital safety. Instead of relying on large centralized moderation systems, each family becomes responsible for its own digital environment. Families who fail to maintain healthy moderation standards can be removed from the platform, ensuring a consistently safe community. Within this ecosystem, families will have access to verified professionals such as doctors, lawyers, teachers, and other public service specialists. The platform enables users to simply select a professional profile, view their calendar, and instantly start a secure video consultation or schedule a meeting. Artificial intelligence will act as a personal assistant for every family. Each household will have its own AI agent capable of helping with education, health monitoring, scheduling, and daily decision-making. For example, parents will be able to ask their AI assistant to supervise a child’s learning progress. The AI can prepare educational tasks, verify results, and support collaboration with schools. Safety features will also be integrated directly into the platform. Parents will be able to monitor children's locations, receive alerts, and connect wearable devices designed for child safety. In the future, we plan to integrate smart products and hardware solutions that help families quickly locate children if they become lost. Another key element is content control. The platform will filter digital content from external sources such as video platforms or search engines, ensuring that families only receive safe and relevant information. External services and brands will be able to participate in the ecosystem only after verification and partnership approval. The long-term goal is to create a single digital environment where families can manage communication, education, safety, healthcare access, and professional services without needing multiple fragmented platforms. I am currently seeking a strategic technology partner capable of providing advanced AI infrastructure and model integration to power the intelligent systems within this ecosystem. In return, the partner would gain early access to a rapidly growing platform designed for families and the opportunity to position its technology as the core intelligence of a new generation of safe digital environments. I would welcome the opportunity to discuss a potential collaboration. Best regards, Karenton Oyan Founder – karentonoyan.pl śr., 11 mar 2026, 14:53 użytkownik Kar Kar ***@***.***> napisał:

…

Yes, but the snag is probably not in pyannote itself. pyannote.audio currently documents community-1 as using torchcodec for audio decoding, and the local pipeline setup goes through that dependency. On PyPI, torchcodec wheels are published for Linux manylinux_2_28_x86_64, macOS ARM, and Windows x86-64, but there is still no Linux aarch64 wheel listed. Even the current 0.10.0 release on PyPI shows x86_64 Linux wheels only, not ARM64 Linux. There is already an upstream TorchCodec feature request specifically for Linux ARM/aarch64 support. It was opened in March 2025 to track that need, and the issue text explicitly says they would need additional build, test, and FFmpeg release infrastructure. That makes this look like an upstream packaging/platform-support gap rather than a simple pyannote config tweak. There is also a later TorchCodec issue from November 24, 2025 from someone on an Nvidia DGX Spark with Ubuntu ARM64 reporting essentially the same pain point: no official aarch64 wheel, attempts to build manually, and FFmpeg-related build failures. So the gremlin is very much alive on that platform. So the honest answer is: yes, aarch64 support is possible in principle, but today it does not look officially supported by TorchCodec on Linux ARM, and that is what is breaking pyannote/speaker-diarization-community-1 on your DGX Spark. A practical reply you could send is: Thanks a lot. This seems to be blocked by torchcodec, which pyannote.audio uses for decoding in speaker-diarization-community-1. On Linux aarch64 there currently does not appear to be an official torchcodec wheel on PyPI, while x86_64 Linux, macOS ARM, and Windows wheels are available. There is already an upstream TorchCodec request for Linux ARM/aarch64 support, and another recent report from a DGX Spark user hitting the same limitation. So from the outside this looks like an upstream TorchCodec platform-support issue rather than something specific to the diarization model. If Linux aarch64 support is planned, that would unblock this use case nicely. If you want it a bit sharper and more GitHub-native, use this version: I don’t think this is a pyannote model issue per se. The failure comes from torchcodec, which currently seems not to publish Linux aarch64 wheels on PyPI. Since speaker-diarization-community-1 depends on that stack for local decoding, the pipeline cannot initialize on DGX Spark / ARM64 right now. There is already an upstream TorchCodec request for aarch64 support, plus a recent DGX Spark report with the same problem. It would be great to either add Linux ARM wheels or document an ARM-compatible installation path/workaround. The core fact here is delightfully mundane: the model is fine, the packaging is throwing a tiny architecture tantrum. śr., 11 mar 2026, 13:59 użytkownik Alex Baur ***@***.***> napisał: > Hi > > I'm working on a Nvidia Spark DGX Linux spark-a3be 6.17.0-1008-nvidia > #8-Ubuntu SMP PREEMPT_DYNAMIC Wed Jan 21 17:56:56 UTC 2026 aarch64 aarch64 > aarch64 GNU/Linux > > And when I use pyannote/speaker-diarization-community-1 I get the > following error > > Model initialization error" error="diarization model pyannote: failed to setup PyAnnote environment: uv sync failed: exit status 2: Resolved 136 packages in 13ms\nerror: Distribution `torchcodec==0.7.0 @ registry+https://pypi.org/simple` <https://pypi.org/simple> can't be installed because it doesn't have a source distribution or wheel for the current platform\n\nhint: You're on Linux (`manylinux_2_39_aarch64`), but `torchcodec` (v0.7.0) only has wheels for the following platforms: `manylinux_2_28_x86_64`, `macosx_11_0_arm64`, `win_amd64`; consider adding \"sys_platform == 'linux' and platform_machine == 'aarch64'\" to `tool.uv.required-environments` to ensure uv resolves to a version with compatible wheels > > Is it possible to add aarch64 support? > > Thanks a lot > > — > Reply to this email directly, view it on GitHub > <#1990>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/BUHB4EZ6KLXLF5ELCRINXLT4QFPLJAVCNFSM6AAAAACWOIMSXCVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZZGYZDGMZQHE> > . > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.***> >