[XB] Text to Speech: Read Aloud, Audio Playback & AI Voices

[XB] Text to Speech: Read Aloud, Audio Playback & AI Voices [Paid] 1.1.2

No permission to buy ($25.00)
Overview Updates (4) History Discussion
fionix said:
I don't think the problem is the OpenAI character limit. The add-on's architecture is the issue.

It generates audio in small chunks while playback is already running instead of generating the complete audio file first and caching it. This results in long loading times, interrupted playback, unnecessary server load, and poor performance on long form articles.

For a forum with 3,000-10,000 word guides, this simply isn't a practical solution.
Click to expand...
OpenAI has a 4,000-character TTS input limit, so the text has to be split into chunks.

Generating the entire audio first would create files that can easily be 10+ of megabytes, increase server and bandwidth load, and require regenerating the whole file after even a small message edit.
 
I understand that OpenAI requires the text to be split into chunks. That's not the issue I'm reporting.

The issue is that playback stalls while the next chunk is being generated. The page sits in a loading state, playback gets interrupted, and sometimes it even triggers the "wait X seconds" message.

Switching to Opus doesn't change this behaviour.

In other words, the problem isn't that the text is chunked, it's that the chunk generation and playback aren't seamless enough for long-form content.
 
fionix said:
I understand that OpenAI requires the text to be split into chunks. That's not the issue I'm reporting.

The issue is that playback stalls while the next chunk is being generated. The page sits in a loading state, playback gets interrupted, and sometimes it even triggers the "wait X seconds" message.

Switching to Opus doesn't change this behaviour.

In other words, the problem isn't that the text is chunked, it's that the chunk generation and playback aren't seamless enough for long-form content.
Click to expand...
I don't see any noticeable delays on my test forum, even with large messages.
In the latest update, the next chunk is automatically preloaded before the current one finishes playing,so In theory, smaller chunks should be faster and less noticeable than larger ones.

The message "wait x" shown in the overlay comes from the permissions-based flood protection. Try increasing the permission value so you don't run into the request rate limit.
 
Last edited:
Increasing the flood limit isn't really an option for us. We intentionally keep those limits in place because we've been dealing with aggressive scraping and automated traffic.

The add-on should work within XenForo's default security mechanisms rather than requiring administrators to weaken them. If using the add-on requires relaxing flood protection, then that's a significant limitation for production forums.
 
fionix said:
Increasing the flood limit isn't really an option for us. We intentionally keep those limits in place because we've been dealing with aggressive scraping and automated traffic.

The add-on should work within XenForo's default security mechanisms rather than requiring administrators to weaken them. If using the add-on requires relaxing flood protection, then that's a significant limitation for production forums.
Click to expand...
It uses a separate permission for request limit


I'll add an option to queue and generate next X (instead current 1) chunks while the first one is playing
- This may reduce the delays a bit more.
 
You must log in or register to reply here.
Back
Top Bottom