Consume the shared FFT from DspTap; adopt tap::mu (and TapHouse v4)#27
Merged
Conversation
Everything already matched TapHouse v4 (configs + tidy.sh); only the drift-check ref needed bumping off v3. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MRTDgYKY38WH8Bqz17W9k1
Wire MuTap onto the extracted tap::dsp real FFT and move MuTap's own code to
the family namespace.
FFT:
- Add submodules/dsptap and link tap::dsp; delete the vendored copies
(include/mutap/fft.h, third_party/{ooura,cmsis-dsp}) and the FFT unit tests
(now DspTap's). include/mutap/fft.h becomes a thin shim that includes
tap/dsp/fft.h and re-exports real_fft / real_fft32 / basic_real_fft into
tap::mu, so the historical include path and the unqualified names keep
working. The extracted wrapper is byte-identical to what lived here, and
DspTap selects the per-target backend itself (CMSIS on the M55, vDSP on
Apple, Ooura elsewhere), so the CMSIS/Accelerate option blocks are gone.
Namespace:
- Rename mutap -> tap::mu across the library, tests, tools and benches
(CMake target MuTap::MuTap and the MUTAP_* build options are unchanged, so
MuTap-Max keeps building against it until it is migrated separately).
Verified: builds on Linux against the DspTap submodule; the FFT-consuming
suites (FDAF, FD-Kalman, LPC, closed-loop, PEM-AFC, postfilter) all pass. The
heavy ITU/G168 integration battery exercises the same byte-identical FFT and
runs in MuTap's CI.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MRTDgYKY38WH8Bqz17W9k1
Move the submodule pin off the pre-merge feature-branch commit (48f2629) onto DspTap main (9cbfbca). Main additionally carries the double-engine float-I/O overloads, which MuTap does not use (C++20-constrained, additive) — verified the build is unaffected. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MRTDgYKY38WH8Bqz17W9k1
MuTap gained a submodule (submodules/dsptap) when it moved to the shared FFT, but the workflows predate that and checked out without submodules, so every build/clang-tidy job failed at configure (submodules/dsptap empty → add_subdirectory has no CMakeLists.txt). Add `submodules: recursive` to every actions/checkout step. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MRTDgYKY38WH8Bqz17W9k1
The suppressor branch-free/branchy parity job compiles the Ooura sources and the parity harness directly (bypassing CMake). The vendored Ooura moved into the DspTap submodule, so update the paths (third_party/ooura -> submodules/dsptap/third_party/ooura) and add -Isubmodules/dsptap/include (the harness pulls mutap/fft.h, now a shim over tap/dsp/fft.h). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MRTDgYKY38WH8Bqz17W9k1
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Moves MuTap onto the extracted shared FFT and into the family namespace, plus the TapHouse v4 style bump. Three commits:
1. Adopt TapHouse v4
Normalize the drift-check pin to v4 and add
scripts/tidy.sh(the local clang-tidy gate mirror) — matches the rest of the family.2. Consume the shared FFT from DspTap; adopt the
tap::munamespaceFFT:
submodules/dsptapand linktap::dsp; delete the vendored copies (include/mutap/fft.h,third_party/{ooura,cmsis-dsp}) and the FFT unit tests (now DspTap's).include/mutap/fft.hbecomes a thin shim that includestap/dsp/fft.hand re-exportsreal_fft/real_fft32/basic_real_fftintotap::mu, so the historical include path and unqualified names keep working.Namespace: rename
mutap→tap::muacross the library, tests, tools, and benches. The CMake targetMuTap::MuTapand theMUTAP_*build options are unchanged, so MuTap-Max keeps building against it until it's migrated separately.3. Re-pin the DspTap submodule to
mainAfter the DspTap PRs merged, move the pin from the pre-merge feature-branch commit onto
main.Verification
Builds on Linux against the DspTap submodule; the FFT-consuming suites (FDAF, FD-Kalman, LPC, closed-loop, PEM-AFC, postfilter) pass. The heavy ITU/G168 integration battery exercises the same byte-identical FFT and runs in CI.
Follow-up (not here)
MuTap-Max consumes MuTap and will need updating: recursive submodule init (the nested
dsptap) and themutap::→tap::mu::rename.🤖 Generated with Claude Code
https://claude.ai/code/session_01MRTDgYKY38WH8Bqz17W9k1
Generated by Claude Code