在浏览器里跑 FRCRN：WebAssembly 轻量化部署实录

导出后再用 ONNX Runtime 工具做一轮优化，重点不是追求极限压缩，而是先把算子兼容性和浏览器可跑性解决掉。

浏览器端怎么接起来

项目结构不复杂，核心就是页面、推理脚本、音频处理模块和模型文件。

frcrn-wasm-demo/
├── index.html
├── style.css
├── app.js
├── wasm/
│   ├── frcrn.onnx
│   ├── ort-wasm.wasm
│   └── ort-wasm.js
├── audio-processor.js
└── package.json

音频处理这块最容易踩坑。麦克风拿到的是连续 PCM 流，模型吃的却是固定格式的频域特征，中间得做 STFT 和逆变换，还要盯住采样率、帧长和重叠关系。

// audio-processor.js
class AudioProcessor {
    constructor() {
        this.audioContext = null;
        this.processor = null;
        this.model = null;
        this.isProcessing = false;
        this.SAMPLE_RATE = 16000;
        this.FRAME_SIZE = 512;
        this.HOP_SIZE = 256;
    }

    async init() {
        try {
            this.audioContext = new (window.AudioContext || window.webkitAudioContext)({ sampleRate: this.SAMPLE_RATE });
            await this.audioContext.resume();
            return true;
        } catch (error) {
            console.error('初始化音频上下文失败:', error);
            return false;
        }
    }

    async startProcessing() {
        if (this.isProcessing) return;
        try {
            const stream = await navigator.mediaDevices.getUserMedia({
                audio: {
                    sampleRate: this.SAMPLE_RATE,
                    channelCount: 1,
                    echoCancellation: false,
                    noiseSuppression: false,
                    autoGainControl: false
                }
            });
            const source = this.audioContext.createMediaStreamSource(stream);
            this.processor = this.audioContext.createScriptProcessor(this.FRAME_SIZE, 1, 1);
            source.connect(this.processor);
            this.processor.connect(this.audioContext.destination);
            this.processor.onaudioprocess = (event) => {
                if (!this.isProcessing || !this.model) return;
                const inputData = event.inputBuffer.getChannelData(0);
                this.processAudioFrame(inputData);
            };
            this.isProcessing = true;
        } catch (error) {
            console.error('启动音频处理失败:', error);
        }
    }

    processAudioFrame(audioData) {
        const stftData = this.computeSTFT(audioData);
        const output = await this.model.run(stftData);
        const processedAudio = this.inverseSTFT(output);
        return processedAudio;
    }

    computeSTFT(audioData) { /* 实现 STFT */ }
    inverseSTFT(spectrum) { /* 实现逆 STFT */ }
}

这里有个很现实的问题：processAudioFrame 里用了 await，但函数本身不是 async，实际落地时得补上，不然代码根本跑不起来。很多示例代码都喜欢把重点写出来，边界条件留给读者自己补，这里刚好就属于这种。

ONNX Runtime Web 的接入也不复杂，模型加载后直接创建推理会话就行。

// app.js
class FRCRNApp {
    constructor() {
        this.audioProcessor = new AudioProcessor();
        this.session = null;
        this.isModelLoaded = false;
    }

    async loadModel() {
        const loadingElement = document.getElementById('loading');
        loadingElement.textContent = '正在加载模型...';
        try {
            const ort = await import('https://cdn.jsdelivr.net/npm/onnxruntime-web/dist/ort.min.js');
            this.session = await ort.InferenceSession.create('./wasm/frcrn.onnx', {
                executionProviders: ['wasm'],
                graphOptimizationLevel: 'all'
            });
            this.isModelLoaded = true;
            loadingElement.textContent = '模型加载完成！';
        } catch (error) {
            console.error('加载模型失败:', error);
        }
    }

    async processWithModel(inputTensor) {
        if (!this.session || !this.isModelLoaded) throw new Error('模型未加载');
        const feeds = { input: new ort.Tensor('float32', inputTensor, [1, 257, 100, 2]) };
        const results = await this.session.run(feeds);
        return results.output.data;
    }
}

性能上主要看什么

浏览器端做实时降噪，瓶颈通常不在模型本身，而在音频流转和内存分配。前端一旦频繁 new 缓冲区，延迟会很快抖起来。

所以比较实用的做法是重用内存池，把频繁申请的数组收起来；计算部分能放到 Web Worker 就放，主线程别被 STFT 和推理一起压住；帧长和重叠率也别写死，设备性能一般时适当放宽一点，体验会更稳。

class AudioBufferPool {
    constructor() { this.buffers = new Map(); }
    getBuffer(size) {
        if (!this.buffers.has(size)) this.buffers.set(size, new Float32Array(size));
        return this.buffers.get(size);
    }
}

实际体验

测试环境里用了 MacBook Air M1、iPhone 13 和一台 Windows PC，浏览器覆盖 Chrome、Safari 和 Firefox。对比对象包括原始音频、浏览器内置降噪和常见桌面软件。

结果上，FRCRN 在持续背景噪声上压得比较干净，突发噪声也能明显收住；语音本身没有被弄得太薄，听感还算自然。M1 机型上的端到端延迟大概在 45 到 60ms，做实时通话够用，内存和 CPU 占用也没有夸张到难以接受。

不同场景里，在线会议是最直接的用法，WebRTC 配合起来比较顺；录音监听也能用，但要注意回放链路；拿来给语音识别做前置，嘈杂环境下的识别率提升会比较明显。这里真正值钱的不是'降噪很强'这句话，而是它能把门槛压到浏览器这一层。

结尾

这套方案的核心不复杂：FRCRN 负责降噪，ONNX Runtime Web 负责推理，WebAssembly 负责把它塞进浏览器里。真正要处理的，是模型格式、音频流、缓存和延迟这些细节。

如果后面继续做，我会优先看三件事：模型量化、音频同步，以及更小的前端包体。多模型组合也有空间，比如把 VAD、AEC 一起接上，但这会把调参复杂度再抬高一截，得看实际需求值不值得。