Persistent background hiss/noise issue during TTS

Support Help
1

Hi Support Team,

We’ve isolated a persistent background hiss/noise issue during TTS. It appears to be a carrier-specific codec/transcoding issue, not the ElevenLabs TTS engine itself.

Here is the exact proof and what we have already ruled out:

1. Carrier-specific: When calling the agent from a phone on the “Plus” network (Poland), the audio is crystal clear. However, when calling from the “Play” network (Poland), there is a loud hiss/noise specifically when the AI speaks. 2. Not the SIP Provider: Our main SIP trunk provider is Telnyx. To rule out Telnyx as the cause, we also tested different local SIP carriers (e.g., FCN in Poland), and the hiss on the “Play” network still persists across all of them. 3. Not the Voice Profile: Other platforms using the exact same ElevenLabs Voice ID over phone lines do not have this hiss.

This indicates that the audio stream Retell generates contains high frequencies that specifically cause the “Play” telecom network’s codecs to inject noise during downsampling.

Could your engineering team apply a low-pass filter (or adjust the anti-aliasing filter) to the audio stream on our Workspace before pushing it via SIP? Cutting those high frequencies should stop the Play network from generating this artifact.

Our Workspace ID is: org_B8yip1HcPH7CeVo4

2

Hello @maciorskimaciej Can you share the relevant Agent ID and Call IDs both where voice is clear and not for a Review.

Thank You

3

agent_4e9aeededde50fa45e597128d2 and agent_c7dd07befaf0032eea8a34cf4c were used for most calls, but I don’t think they are relevant. Call where voice is clear - call_c57e75e3b0726915d0500bdc5f1. Call where voice is not clear - call_01e4f2cedb64cade1f3a39914a2. Note that in Retell call history, when listening the voices are clear in both. It only appears on the phone.

4

@maciorskimaciej Looking into this with team.

5

Hello @maciorskimaciej What we verified on call_01e4f2cedb64cade1f3a39914a2:

  • SDP negotiates G.711 A-law / 8 kHz / 20 ms ptime on both sides clean SIP ladder, no codec renegotiation.
  • PCMA at 8 kHz is Nyquist-limited to 4 kHz, so we can’t put high-frequency energy on the wire. A low-pass filter on our side would be a no-op.
  • Pipeline: ElevenLabs eleven_flash_v2_5 → 24 kHz PCM → LiveKit SIP egress resamples to PCMA/8 kHz. Retell-side recording matches this and is clean.
  • Same artifact across Telnyx and FCN, only on Play → the only shared variable is Play’s PSTN->mobile transcoder (PCMA re-encoded to AMR-NB/EVS inside Play’s MGW), downstream of our egress.

There is no workspace-level filter, gain, or codec knob in Retell that would change this.

Can you please test the below test these two things from your side (won’t fix Play, but may dodge the interaction):

  • Try a stock ElevenLabs voice or eleven_turbo_v2_5 on a throwaway agent different spectral profile.
  • Lower voice_temperature on agent_4e9aeededde50fa45e597128d2 from 1.0 to 0.3–0.5.
    Confirm the asymmetry on Orange / T-Mobile too Play-only behavior is the strongest evidence to take to them.

Thank You

6

Hi Shaw,

Thank you for the incredibly detailed technical breakdown—that level of support is highly appreciated!

I tested your suggested workarounds (lowered the voice temperature, changed ElevenLabs models, and even disabled VoLTE/Wi-Fi Calling on my end). The artifact still persisted on my specific device.

I also ran tests on several other mobile devices across different Polish carriers (Plus, T-Mobile, and even another phone on the exact same ‘Play’ network). The audio was perfectly clean and artifact-free on all of them.

It clearly points to an isolated hardware/handshake issue between my specific phone model and Play’s transcoder, rather than a global carrier problem. Since the audio is flawless for other users and networks, I am completely fine with this outcome for our production environment.

Thanks again for the outstanding support and for pointing me in the right direction. We can consider this ticket officially closed.