Skip to content

Refactor DSP Pipeline: Implement Worker Pooling and Raw Pointer API#14

Draft
jLynx wants to merge 1 commit into
mainfrom
perf_update
Draft

Refactor DSP Pipeline: Implement Worker Pooling and Raw Pointer API#14
jLynx wants to merge 1 commit into
mainfrom
perf_update

Conversation

@jLynx
Copy link
Copy Markdown
Owner

@jLynx jLynx commented Apr 11, 2026

This PR significantly optimizes the DSP architecture by moving from a "one-worker-per-VFO" model to a more scalable pooled worker system. It also introduces a raw-pointer-based WASM API to bypass wasm-bindgen borrow-checking limitations, allowing multiple DSP instances to reside efficiently in a single worker.

Key Changes

1. High-Efficiency DSP Worker Pooling

  • Transition from 1:1 to N:M: Instead of spawning a dedicated Web Worker for every VFO, VFOs are now assigned as "slots" to a pool of DSP workers (defaulting to a max of navigator.hardwareConcurrency).
  • Dynamic Load Balancing: New VFOs are assigned to the least-loaded worker in the pool to keep per-chunk processing time low.
  • Batch Processing: Workers now process all assigned slots in a single pass and return an audioBatch message, reducing the overhead of postMessage communication.

2. Raw Pointer WASM API (processor.rs)

  • Bypassing RefCell: Implemented a dsp_new/dsp_process_ptr API in Rust that uses raw heap pointers (Box::into_raw).
  • Parallel Coexistence: This allows multiple DspProcessor instances to exist within the same WASM module instance without triggering WasmRefCell borrow errors, which previously necessitated separate workers for each instance.

3. Decoupled Audio Mixer

  • Timer-Based Mixing: The audio mixer has been moved out of the worker message handler and into a dedicated setInterval loop (50Hz).
  • Complexity Reduction: This prevents the $O(N^2)$ complexity scaling where every worker message triggered a full scan of all VFO queues, leading to much smoother audio performance under high VFO counts.

4. Remote Client Enhancements

  • Independent Pooling: Remote clients now utilize the same pooling logic, ensuring that multi-client usage doesn't lead to an explosion of system threads.

Performance Impact

  • Reduced Thread Overhead: Significantly lower memory and CPU usage when running multiple VFOs.
  • Scalability: Allows the application to handle many more concurrent VFOs (both local and remote) before hitting browser performance bottlenecks.
  • Stability: Reduced "jank" in the main thread by batching messages and decoupling the mixing logic from the DSP throughput.

- Replaced individual DSP workers for each VFO with a pooled worker model.
- Introduced dynamic slot management for VFOs within the worker pool.
- Updated methods for adding and removing VFOs to accommodate the new pooling strategy.
- Enhanced audio processing to handle batched results from workers, improving performance.
- Adjusted remote client handling to utilize the new worker pool structure.
- Cleaned up and optimized existing code for clarity and maintainability.
@cloudflare-workers-and-pages
Copy link
Copy Markdown

Deploying with  Cloudflare Workers  Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status Name Latest Commit Preview URL Updated (UTC)
✅ Deployment successful!
View logs
browsdr 5ff6d17 Commit Preview URL

Branch Preview URL
Apr 11 2026, 10:37 AM

@jLynx jLynx changed the title Refactor DSP worker management to use a pooled approach Refactor DSP Pipeline: Implement Worker Pooling and Raw Pointer API Apr 11, 2026
@jLynx
Copy link
Copy Markdown
Owner Author

jLynx commented Apr 11, 2026

I'm still not convinced this is the correct approach to improve performance. I think more tests are needed before this PR is ready

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant