Open-Source SDK Streams Speech Enhancement on CPU, Mobile and Browsers

An open-source SDK called GigaEdge Spench now packages neural speech enhancement as a streaming pipeline that runs on CPU servers, phones and in browsers, according to a paper posted to arXiv by Artem Sokolov, Artem Khaidarov, Yana Lysova, Alexander Gladkikh and Vitaliy Yulis. It matters because most speech-enhancement research stops at offline quality scores, while live products need audio that keeps up with a microphone, a call or a video encoder running on the same machine.

The release is aimed at the unglamorous middle of the problem: making enhancement usable inside real applications rather than demonstrating a better model in a benchmark.

What does GigaEdge Spench actually ship?

According to the paper, the SDK lets an application assemble an "enhancement channel" — a configurable pipeline — from neural denoising, normalization and dynamics blocks, sample-rate conversion, and acoustic echo cancellation where the host platform supports it. Stages can be combined, and normalization can run on its own without a neural model at all, which the authors present as a deliberate design choice rather than a fallback.

The release includes three models: an 8 kHz INT8 denoiser and discriminative and hybrid 48 kHz FP32 models. Training, quantization and conversion tooling is explicitly outside this SDK release, so what is published is the deployment side plus the weights needed to run it.

The name, the authors note, is a compression of Speech, Enhancement and Channel.

How is it built to run everywhere?

The architecture has three parts. A shared C++ core handles sample-rate conversion, spectral processing and per-stream model state, exposing C and C++ interfaces for its audio-processing modules. Platform wrappers then connect that core to Android, iOS and Web Audio applications, with worker-based execution for live audio. The core supports ONNX Runtime and TensorFlow Lite through native interfaces, plus Android and iOS SDKs and WebAssembly integration for browsers.

Two implementation details do most of the work. Independent stream contexts share model resources, so several audio streams can be served from one loaded model. And consecutive frames from a single stream can be grouped into one inference call, which the paper treats as a central tuning knob rather than an incidental optimisation. All SDK timing reported in the paper uses ONNX Runtime; the external RNNoise reference uses its native C kernels.

What did the measurements show?

The authors evaluate the released models on EARS–WHAM v2 and compare quality and processing cost against RNNoise and sherpa-onnx/DPDFNet2, stating which operations and processing stages are counted in each figure. Echo cancellation in the SDK is built on SpeexDSP, following the approach of established audio pipelines such as WebRTC's Audio Processing Module.

Three findings stand out. Every native and Web configuration tested processed audio faster than real time, though larger chunks cost more time up front because more input has to be collected before processing starts. Larger chunks also delivered more throughput than adding extra command-line processes. And the model with the lowest arithmetic cost did not necessarily give the best balance of quality and measured stream capacity — a caution against picking a model on FLOPs alone.

Who is this for, and what are the limits?

The stated motivation is videoconferencing across native platforms and browsers, where devices vary widely in compute and microphone quality and where enhancement has to share the machine with video encoding and decoding, including demanding codecs. The authors argue that a high quality score alone does not tell you whether a model fits such an application, because total processing cost, buffering and concurrent-stream capacity impose separate limits.

The paper is candid about scope. The architecture and training objectives of the 48 kHz hybrid model are not covered, nor are the training and conversion tools. Recurrent-state caching, model sharing, ring buffers and worker threads are described as established techniques; the contribution claimed is their integration into configurable channels plus the study of how model choice, chunk size and execution environment interact. Comparison tables summarise documented functions rather than ranking systems by measured speed or quality.

How could you explore this with Grafy?

For most readers the practical entry point is reading rather than integrating. Grafy Reader can take the arXiv paper directly, search across its sections and answer questions about specific claims — for instance, which sampling rates the released models cover, or exactly which processing stages the authors counted in each timing figure. That distinction matters here, because the paper's comparisons depend heavily on counting scope.

If you are weighing this SDK against alternatives such as RNNoise, DTLN, DeepFilterNet2 or GTCRN, Grafy Chat is a reasonable place to put the trade-offs side by side and pressure-test your own deployment constraints. Grafy does not ship a speech-enhancement runtime, so integration work would happen in your own codebase; the SDK's value is in shortening that path.

Frequently asked questions

Does GigaEdge Spench include acoustic echo cancellation?

Yes, but conditionally. According to the paper, applications can add acoustic echo cancellation to an enhancement channel where the host platform's API supports it, and the implementation uses SpeexDSP for that stage. The SDK follows the general approach of integrated audio pipelines such as WebRTC's Audio Processing Module, which combines noise suppression, echo cancellation and gain control in one place.

Can normalization run without a neural model in this SDK?

Yes. The authors state that the processing stages can be combined, and that normalization can also run without a neural model. The normalization stage can itself be assembled from selectable signal-processing blocks, which lets an application use a purely signal-processing path, neural denoising alone, or both together, depending on the compute budget available on the target device.

Does the SDK release include model training and quantization tools?

No. The paper says the open-source release supplies three models — an 8 kHz INT8 denoiser and discriminative and hybrid 48 kHz FP32 models — but that training, quantization and conversion tools fall outside this SDK release. The detailed architecture and training objectives of the 48 kHz hybrid model are also declared out of scope for the study.

---

Source: Grafy Research Lab — GigaEdge Spench: An SDK for Practical Streaming Speech Enhancement