[4/4] Optimize SILK int16 output#118
Closed
zshang-oai wants to merge 1 commit into
Closed
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## codex/reduce-silk-lpc-synthesis #118 +/- ##
==================================================================
Coverage ? 82.36%
==================================================================
Files ? 26
Lines ? 5808
Branches ? 0
==================================================================
Hits ? 4784
Misses ? 790
Partials ? 234
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
RFC 6716 / 8251 conformationStatus: pass The action extracts the RFC 6716 reference implementation, applies the RFC 8251 decoder update patch, and then builds the patched reference tools. Legend: numeric cells are Inputs use the shared RFC 6716 / RFC 8251 bitstream corpus; accepted references follow RFC 8251 Section 11.
Run output |
Contributor
Author
|
Abandoning this draft; the measured gain on the production-like 48 kHz stereo conformance decode workload is too small to carry forward. |
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.
Summary
Decodebyte output from the directint16path instead of round-tripping throughfloat3216 kHz -> 48 kHzstyle output so it streams the 2x allpass samples into the three FIR phases without materializing the intermediate bufferWhy
The stress profile after the earlier stacked changes is dominated by SILK resampling and the final float-to-int16 output path. The RFC resampler already computes signed 16-bit samples internally, so the common SILK-only direct-output path can avoid converting those samples back to float only to quantize them again. The same profile shows the fixed 3x IIR/FIR path as the remaining hot resampler case for the fixture, so this PR keeps the generic path and adds a narrow streaming specialization for that fixed ratio.
This is stacked on #116. Until that lands, the diff against
mainincludes the LPC optimization below it.Validation
GOCACHE=/private/tmp/opus-go-build GOLANGCI_LINT_CACHE=/private/tmp/opus-golangci-lint golangci-lint runGOCACHE=/private/tmp/opus-go-build go test ./...15s x 3medians on the local fixture:BenchmarkPionDecodeToInt16Serial: about110.5kpackets/sBenchmarkPionDecodeToInt16Serial: about160.5kpackets/s