It sounds like track.clone worked well for you right? Maybe try piping all of your sources into the audiocontext sans the analyser and gain nodes. If that works for you then just clone the track after mixing but before analysis.
Well I used context.createMediaStreamSource() twice. I suppose it is the same. Only way I managed to prevent stuttering was piping stream directly without any nodes. Probably some worker issue related to CPU usage and priority.
Also DTX works perfectly. I checked bandwidth and it was 0 or close to 0 on silence.
I created destinationNode where I redirect second stream source after I analyse it otherwise it would be dead.
Just to clarify, with your base code, the problem is persistent even when you take out the analyser and gain nodes, right? I wish I had some other suggestion for you-it seems like processing the stream through an AudioContext isnât done at an elevated thread priority level.
AudioWorklets are outside of my expertise, but you could try to do all of your preprocessing/mixing/analysis within one (is that possible?) since that seems to be at realtime priority.
Yep. Exactly. I realized the issue too. It needs to be processed on main thread. I cannot even use gain node. Interesting thing is that it works just fine other way around. Consumer nodes are not stuttering at all even with heavy processing.
Dne po 22. 3. 2021 2:07 uĹživatel dimoochka via mediasoup <mediasoup@discoursemail.com> napsal:
Take a look at:
https://bugs.chromium.org/p/chromium/issues/detail?id=813825
If youâre creating the AudioContext in a subframe (ie. not top-level document), that could produce your issue. If thatâs not the case, this might be worth opening a Chromium bug report over. I think itâs reasonable to expect that Chrome would do audio processing for you in realtime priority.
What do you mean by subframe? I just call new MediaContext() inside my angular service. Do you mean iframe? The thing is the engine I work with uses one chromium process and load multiple resources inside as iframes.
The word subframe came from that link, and I assume itâs a reference to an iframe. If your audiocontext is being created within an iframe instead of the top level document that would explain everythingâŚ
I changed it to window.parent.AudioContext() and there is no difference using that context 
Maybe try to create the variable from within the root document itself (ie. reference it as window.audiocontext) and see if that makes a difference. I donât know if your code might still be executing from the context of the iframe.
Not sure if this will work, just going off the info from that bug report.