Couple of thoughts -
a) Try to investigate why you’re getting 100% usage in the first place. Modern PC’s are often GPU bound for gaming. Do you have substantial CPU usage from chromium? That would be unusual for an audio-only application, which brings me to my next point …
b) Sounds like you’re doing some fancy stuff with AudioContext. If you have a usage issue with Chromium, it’s possible that it’s related to the actual audio processing. You mention that you don’t get this issue with Discord (which AFAIK doesn’t do any post-processing like you do). Some ideas:
My first go-to solution would just be to increase the priority of the chromium process. Very easy and highly likely to get you the results you want. Alternatives would be …
If you’re experiencing 100% usage on the sender (producer) side, then you might want to track.clone() the track you get from getUserMedia, and use track1 for your analyser node and plug track2 directly into mediasoup unmodified. I’m not sure if that would fix your issue but it’s a very trivial hack to do and is worth trying.
If you’re experiencing 100% usage on the receiver (consumer) side, then you could consider doing your post-processing inside of a webworker or audioWorklet (not sure if this is possible for your use case). This would move that stuff to a separate thread, but probably wouldn’t help if that thread is being executed on a busy core (and it sounds like all of your cores are busy).
You can also look at the audio stream on affected PC’s using chrome://webrtc-internals – that might give you some hints as to what’s going on.
Other things to think about:
Make sure that you’ve configured OPUS (assuming that’s the codec you’re using) to use DTX (free bandwidth reduction) and FEC.
Look into increasing the size of the receive audio buffer (jitter buffer??)? I have no idea if this is possible in WebRTC/mediasoup – they’re built to be pretty developer-friendly so you really shouldn’t have to mess with stuff like this.