Build opus with NEON intrinsics on non-Android 64-bit ARM

[mcfnord]

Note

📡 STAND BY FOR AN LLM-AUTHORED MESSAGE.

Fixes #2806.

Follows up on the root-cause analysis posted in #2806 (comment): the opus arch-optimisation block in Jamulus.pro matches only the Android ABI names (armeabi-v7a, arm64-v8a). Everywhere else, Qt reports 64-bit ARM as QT_ARCH=arm64 — Apple Silicon macOS (mac/deploy_mac.sh passes it explicitly per architecture slice), iOS, and Linux aarch64 — so all of those builds compile opus as plain C with no NEON acceleration, even though the NEON intrinsic sources ship in-tree.

While implementing the fix, a deeper problem surfaced: the ARM NEON sources have never been compiled on any target, including Android. Two independent gaps:

1. SOURCES += $$SOURCES_OPUS_ARCH only exists in the x86 consumption branch (around line 1150), so the Android arch match populated SOURCES_OPUS_ARCH but nothing ever built it.
2. Even if the files had been compiled, opus gates the inclusion of its arm/*.h headers on OPUS_ARM_MAY_HAVE_NEON_INTR (see libs/opus/celt/pitch.h:49 and libs/opus/celt/cpu_support.h), which the block never defines — the PRESUME defines alone are inert.

That the Android builds link cleanly is itself the proof: with the defines inert, the generic C paths are used and the never-compiled NEON objects are never referenced.

What this PR does

• Adds an else:contains(QT_ARCH, arm64) branch to the arch block that defines OPUS_ARM_MAY_HAVE_NEON_INTR=1 OPUS_ARM_PRESUME_NEON_INTR=1 OPUS_ARM_PRESUME_AARCH64_NEON_INTR=1. NEON is part of the base AArch64 ISA, so presuming it is always safe on this arch — with PRESUME set, opus calls the NEON functions directly and no runtime CPU detection machinery is engaged.
• Adds a matching consumption branch that compiles the NEON intrinsic sources into SOURCES. Unlike the x86 SSE files, they need no special compiler flags on AArch64, so no QMAKE_EXTRA_COMPILERS dance is required.
• Splits SOURCES_OPUS_ARM into the nine self-contained NEON intrinsic files and the two NE10 files (celt_fft_ne10.c, celt_mdct_ne10.c). The NE10 pair #include <NE10_dsp.h> from the external Ne10 library, which Jamulus does not bundle, so only the NEON subset is compiled.

Deliberately not included: activating NEON for the Android ABIs. That would change currently-shipping builds and armeabi-v7a needs its own decision about NEON baseline guarantees (#2475 territory). This PR leaves the Android and x86 branches untouched — their generated Makefiles are byte-identical before and after this change (verified by diffing qmake-generated Makefile.Release for QT_ARCH=x86_64 and QT_ARCH=arm64-v8a).

Why it's worth having

Opus encode/decode is the dominant per-channel CPU cost of a Jamulus server and a large share of the client's audio-thread budget. The NEON intrinsics cover the hot inner loops: pitch cross-correlation and inner products in CELT (celt_pitch_xcorr_float_neon, celt_inner_prod_neon, dual_inner_prod_neon) plus the SILK NSQ/LPC kernels. Every Apple Silicon Mac client, every iOS build, and every Linux aarch64 server (a rapidly growing hosting class — AWS Graviton, Oracle Ampere, Raspberry Pi 5) currently runs the scalar C fallback. This change turns the optimizations that already ship in the tree on for that hardware, with zero effect on any other platform.

Testing (cross-verified on Linux, aarch64-linux-gnu-gcc 13.3):

• qmake "QT_ARCH=arm64" on the patched tree selects the nine NEON sources and the three defines; the NE10 files are correctly absent.
• The full opus source set the patched arm64 build compiles (138 files) cross-compiles cleanly for aarch64 with the exact DEFINES_OPUS from the generated Makefile, archives into a static library with all nine *_neon symbols defined and zero unresolved NEON references.
• Disassembly of the resulting objects shows real NEON vector code (470 SIMD vector ops across the intrinsic objects, e.g. fmla v1.4s chains in celt_pitch_xcorr_float_neon) — genuinely vectorized, not scalar fallback.
• QT_ARCH=x86_64 and QT_ARCH=arm64-v8a Makefiles are byte-identical pre/post patch (regression guard).
• CI provides the remaining native proof: the macOS runners build the arm64 slice with this branch active.

🤖 Generated with Claude Code

[ann0see]

Should have Autobuild please build all targets

[ann0see]

Suggested change

# NEON intrinsic sources: self-contained, need no external library.

[ann0see]

Also this needs to be built, tested and analyzed on Apple Silicon. The arm handling in general is sketchy. For macOS Apple Silicon the explicit variable setting of arm64 is needed otherwise it tries to compile SSE for arm64 which obviously doesn't work

[ann0see]

Then investigate if we can use it and it makes sense to use it - or drop it otherwise

[ann0see]

Try to merge this with the above case to avoid duplication

[mcfnord]

Note

📡 STAND BY FOR AN LLM-AUTHORED MESSAGE.

Native verification on a Raspberry Pi 4 (Cortex-A72, aarch64 Linux, not cross-compiled), including a result I didn't expect.

Symbols: built this branch and the same base commit without it, both natively. nm on the shipped binary confirms all 9 *_neon functions defined in the fixed build, 0 in the unfixed one — the fix links and ships correctly.

CPU benefit: interleaved A/B benchmark (server pinned to one core, bot load, perf stat task-clock), at OPUS_SET_COMPLEXITY(1) (Jamulus's actual setting) I measured no significant difference — and re-tested at OPUS_SET_COMPLEXITY(10) in case low complexity was masking a win: still no significant difference.

Why: confirmed with perf record -g under load — Jamulus uses opus_custom_* (Opus Custom, CELT-only; SILK never runs). 6 of the 9 accelerated functions are SILK-only and are dead code in Jamulus regardless of this fix. Of the 3 CELT functions, only 2 ever appeared under profiling, combined under 1% of server CPU.

Bottom line: still worth merging — dead ARM code silently no-op'ing is a real defect on its own terms — but I'd frame it as a correctness/build-hygiene fix rather than a proven Jamulus performance win. This only covers Linux aarch64; it doesn't address the Apple Silicon question above.

[pljones]

I'd love to get my local (Ubuntu 24.04 LTS) Android build working. Currently I rely on Github.

[pljones]

#2806 is "mac" -- this is "android". Is #2806 mis-titled?

[mcfnord]

Note

📡 STAND BY FOR AN LLM-AUTHORED MESSAGE.

Catching up on the thread:

@ann0see, re: build all targets — CI already did, on this PR's own run: Android APK, Linux arm64 .deb, armhf .deb, macOS, macOS Legacy, iOS, Windows, Windows JACK all pass (https://github.com/jamulussoftware/jamulus/actions/runs/30064659704). The macOS job builds a universal binary and mac/deploy_mac.sh explicitly sets QT_ARCH=arm64 for the Apple Silicon slice, so that slice does compile clean with this fix. I don't have Apple hardware, so that's a compile proof only — no perf number for Apple Silicon from me, same caveat as my Pi 4 result below.

@pljones, re: is #2806 mis-titled — fair catch, and a bit of both: #2806's title says "Mac ARM," which matches how the issue was originally reported, but this PR's actual scope is wider than that title suggests. It touches every non-Android 64-bit ARM target that reports QT_ARCH=arm64 (macOS Apple Silicon, iOS, Linux aarch64) — and separately, while implementing that, it surfaced a genuine Android-specific bug: Android's own arch match populated the NEON source list but two other gaps meant those sources were never actually compiled or linked, so Android has been silently running plain-C opus too, this whole time. That second part isn't really "about" #2806 at all — it's its own defect that happened to surface in the same investigation.

My conclusion, for the record: native Pi 4 (Cortex-A72, Linux aarch64) testing confirms the fix is real and correct — all 9 NEON symbols ship where 0 did before — but produces no measurable CPU win for Jamulus specifically, at either complexity=1 (Jamulus's actual setting) or complexity=10 (max), because Jamulus's CELT-only Opus Custom mode only ever touches 2 of those 9 functions, combined under 1% of server CPU. That's a Jamulus-specific result, not a NEON-doesn't-help result — other opus consumers using SILK or the general encoder path would very plausibly see more. I'd still call this worth merging on correctness/build-hygiene grounds (dead ARM code silently no-op'ing across four platforms is a real defect on its own), just not on a proven performance claim. That's everything I can verify from here — Apple Silicon and a from-scratch Android build both remain open if anyone has the hardware.