FAQs: Text-to-speech

No. After Hi-Fi voice support is enabled, TTS engines or bots request 16 kHz, and calls receive it whenever the negotiated media supports Opus. Endpoints limited to narrowband codecs (GSM, G.726, Truespeech, G.722, PCMU, PCMA) are downsampled to 8 kHz.

Media-service preserves 16 kHz audio internally. If the second agent’s station also supports Opus, that leg stays high fidelity; otherwise, it is downsampled to 8 kHz.

It applies to all portions of the call, depending on the negotiated media codecs. Even without Hi-Fi voice support enabled, live agent-customer calls can achieve high fidelity if both ends use Opus and media-service does not need to transcode.

No. An in-progress call already running at 16 kHz keeps that rate. However, any subsequent transfer or routing to a new IVR or bot after disabling Hi-Fi voice support will use 8 kHz for that new media context.

The sample rate is fixed at the moment a call’s media context is created. Calls already established before the change keep their existing rate. If the call is later transferred or routed to a new IVR or bot, the new media context uses the current Hi-Fi voice support setting.

Yes. It may take a few minutes to propagate across all edges/CSS instances, after which new interactions will use 16 kHz.

Yes, if the trunk and station legs use different codecs and run in separate media contexts (or media-service instances), each leg can be recorded at its own rate. If both legs share the same media context, the entire recording uses that context’s single rate.

GSM, G.726, and Truespeech support neither — both sides of the call are mixed into a single 8 kHz channel. PCMU and PCMA support 8 kHz only, but each side is recorded on separate channels. Among all non-Opus codecs, only L16 supports 16 kHz (via a rate parameter), though it currently defaults to 8 kHz since the rate is not passed.

If your Google Cloud text-to-speech integration is not working properly, ensure that the Google Cloud Text-to-Speech API is enabled.