Thanks — I’m sorry you’re seeing that noise. I’ll help narrow this down. Quick acknowledgement: you’re asking whether Azure TTS can be published via

voice._ParticipantAudioOutput

without resampling, whether the “flush audio emitter due to slow audio generation” logs matter, whether there’s a higher-level API to publish per-listener TTS tracks, and whether Azure TTS differs from ElevenLabs/OpenAI in a way that would cause receiver-side static. I need one more diagnostic detail to proceed: • Can you attach (or paste) a short base64 WAV (or raw PCM) of one problematic published utterance’s first ~2 seconds as received by the client (or the server-side first-frame bytes you logged)? That will let me tell if the noise is encoding/format mismatch vs. timing/packetization artifacts. While I wait for that, please confirm these environment details: • Exact versions for: livekit-agents, livekit-rtc, livekit-plugins-azure (you listed ~=1.5.10 for agents; please confirm full versions of the three). • Browser and LiveKit JS client version used for playback. • Whether the published track is negotiated/advertised as mono 48kHz in the session (server logs or client track settings). A few targeted checks you can run now (these help isolate format vs timing): • Capture the raw frames you send into

audio_output.capture_frame

and write them to a local WAV with header sample_rate=48000, channels=1. Play locally — if the hiss is present locally, it’s a synthesis/format issue; if not, it’s transport/track publish. • Try publishing at 22050 + resample to 48000 (mirror the ElevenLabs path) and compare. If resampled audio is clean, that points to framing/buffering expectations in the pipeline. • On the plugin side, reproduce with a very short TTS (one sentence) and with much slower chunk delivery (add small delays between sends) to see whether the “flush due to slow audio generation” and “incomplete frame” warnings correlate with the noise. What I’ll do next after you provide the waveform/logs and confirmations: • Inspect the sample bytes to detect PCM vs. endian/channel/misalignment problems. • Correlate the plugin flush/incomplete-frame logs with chunk boundaries to determine whether the heuristic is triggering on internal buffered-chunk timing. • Recommend a minimal fix path: either confirm 48k native is fine, or suggest a lightweight resample/adapter or a different publishing API if

_ParticipantAudioOutput

proves brittle. Thanks — with the small audio sample and the version + client info I can give a precise next step. , with interactive elements