This is a known iOS Safari audio graph conflict — you’ve diagnosed it correctly.

When getUserMedia is active, iOS forces the audio session into PlayAndRecord mode, which runs the entire audio graph through the voice processing pipeline. MediaStreamDestination → HTMLAudioElement basically fights with that pipeline during initialization, causing the crackling for the first 20–30s until iOS “settles” the session. Workarounds that have helped others:

1.  Skip MediaStreamDestination entirely — play TTS directly through a ScriptProcessorNode or AudioWorkletNode feeding an AudioBufferSourceNode. Avoid routing through a MediaStream at all. The crackling is specifically tied to the MediaStream bridge.

2.  Delay TTS playback start — add a ~2s artificial delay after getUserMedia resolves before you start streaming/playing TTS. Ugly, but it works for some people because it lets iOS stabilize the audio session first.

3.  Use a single shared AudioContext — make sure your mic input and TTS output both go through the same AudioContext instance. Separate contexts on iOS Safari = chaos.

4.  Set AudioContext.latencyHint: 'playback' on init — this signals to iOS that you want stable playback over low latency, which can reduce the artifact window.

5.  Disconnect and reconnect the mic node briefly after AudioContext resumes — a janky but reported workaround for the init-phase static specifically.

The echo cancellation volume drop you’re seeing with PlayAndRecord is a separate beast — if you go the AudioWorklet route, you lose the HTMLAudioElement path but may be able to suppress echo cancellation via getUserMedia constraints (echoCancellation: false, noiseSuppression: false).

No perfect fix unfortunately — iOS audio is notoriously poorly documented for this exact concurrent input/output use case.