Intermittent "No audio was received" errors with valid requests

[cuongnl]

Description

• Hi, I am experiencing intermittent failures when using edge-tts (via edge-tts).
• The issue started recently (last 1–2 days). Previously, the same code worked fine.
• Now many requests fail with:
• No audio was received. Please verify that your parameters are correct.

Environment

• OS: Windows 10
• Python: 3.10+
• edge-tts: latest
• Voice: vi-VN-HoaiMyNeural
• Concurrency: 1
• Timeout: 300s

Behavior

• Requests randomly succeed or fail
• Some requests take 90–150s, others ~2s
• Failures often occur after retries

Example:

• attempt 1/3 failed after ~3s
• attempt 2/3 failed after ~4s
• attempt 3/3 failed after ~3s
• No audio was received

[EMBlackZero]

I'm experiencing the exact same issue as well. It started about 1–2 days

[novapott210-a11y]

Same here, hopefully it will be fixed soon.

[DamianCryptoBoi]

I'm also facing the exact same issue but it just started from today

[tranthaihoang]

Yes! same here, mybe microsoft change, pềct!

[turtle1340-collab]

same here, hope fix soon

[nutminemz]

same here

[AMomozZz]

Same here. I tried to use another voice, and then it worked again.

[lanngoc98]

Same here, does anyone have a solution?

[Dorivika]

I looked into this a bit. The current reports look consistent with the service completing a websocket turn without sending audio, rather than obviously invalid local parameters.

A few older issues point in the same direction: some voices/IPs/regions can be blocked or temporarily unavailable upstream, and switching voices has helped at least one person here. I also tested vi-VN-HoaiMyNeural, vi-VN-NamMinhNeural, and en-US-EmmaMultilingualNeural on edge-tts 7.2.8 from Windows/Python 3.12 today and could not reproduce the failure.

Could affected users share:

• edge-tts --version
• whether edge-tts --list-voices includes the failing voice
• voice name(s) tested
• country/region and whether VPN/proxy/datacenter IP is involved
• whether vi-VN-NamMinhNeural or en-US-EmmaMultilingualNeural works
• approximate failing timestamp in UTC

A useful library-side improvement may be to make NoAudioReceived more diagnostic by reporting whether the websocket received response, turn.start, audio.metadata, and turn.end before raising. That would help distinguish unsupported/blocked voices, network/IP blocking, and upstream temporary service issues.

[Morad37]

Submitted a PR (#474) with the diagnostic improvement suggested by @Dorivika -- when NoAudioReceived is raised, the error now includes a list of WebSocket message types received (e.g. ['response', 'turn.start', 'audio.metadata', 'turn.end']), so users can immediately tell whether the connection failed at the handshake, parameter negotiation, or mid-stream stage without needing packet-level debugging.