I have one doubt. Egress stores the audio in `.ogg...
# ask-ai
b
I have one doubt. Egress stores the audio in
.ogg
format, but it is not stable across all browsers, especially Safari. So, is it recommended to use this in production, or should we use MP3 instead?
t
Thanks for reaching out, Yethu. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — good question. You're right to be concerned. • Track Egress writes audio as
.ogg
with the Opus codec and does not transcode.
.ogg
(Opus) is not reliably supported in all browsers — Safari in particular has limited support. • For production where broad playback compatibility is required, use MP3 instead. Options: • Use a composite egress (Room Composite, Web Egress, or Track Composite Egress) and request MP3/MP4 outputs — these egress types transcode and can produce MP3-compatible files. • Or keep Track Egress and transcode the resulting
.ogg
to MP3 as a post-processing step. If you tell me which egress method you currently use (Track vs Room/Composite) and whether you need a one-time conversion or real-time MP3 output, I can give exact configuration snippets or a post-processing command you can use. Sources: Track egress | LiveKit docs | Universal Egress | Egress API | LiveKit docs
b
Hi Team , Is there any issue with livekit inference TTS? [8:39 PM] It is not working as expected, facing some distortion and delay in the voice.
t
Thanks — I’m sorry you’re seeing distortion and delay with inference TTS. I can help narrow this down. First, a few quick facts: • Latency is a known focus area. Targets are <300ms TTFB for TTS and <1.5s end-to-end; there are features (like preemptive_generation) and infrastructure choices that reduce delay. • Distortion isn’t a documented widespread issue, but it can come from the TTS node’s post-processing, encoding/publishing pipeline, or frontend playback. To diagnose, please tell me: 1. Which inference TTS setup are you using — the built-in
tts_node
or a custom TTS implementation? 2. Are you using LiveKit’s hosted inference or self-hosted? Region or deployment location? 3. When does distortion occur — always, only on certain voices, or intermittently? Any pattern with long responses vs short? 4. Do you see latency/distortion in Agent Observability traces or logs? If so, share relevant timestamps or a short log excerpt. 5. What SDK and browser (including Safari version if relevant) and network conditions are you testing from? 6. If possible, can you share a short sample audio file or a timestamped recording showing the distortion and delay? What I can do next: • If you’re using a custom
tts_node
, I’ll walk through checks for sample rate/encoding mismatches and any post-processing that can cause clipping/distortion. • If you’re on hosted inference, I’ll guide you to collect Agent Observability traces and logs to pinpoint latency and check whether preemptive generation or region changes reduce delay. • I can provide specific commands/snippets to convert or normalize audio, and recommended configs for reducing end-to-end latency. Tell me the answers to 1–5 (and attach a short sample if possible) and I’ll provide targeted steps. Sources: examples/frontdesk | livekit/livekit_composite | DeepWiki | Introducing LiveKit Inference: A unified model interface for voice AI | Agent session | LiveKit docs | Text-to-speech (TTS) models | LiveKit Docs | Agent speech and audio | LiveKit docs
b
When deploying the LiveKit agent on livekit cloud, I see that the maximum number of replicas is limited to 8. What happens if our usage goes beyond this limit? Is this a soft limit, or does it require a configuration or plan change?
t
Thanks — I’m responding to your question about the 8-replica cap when deploying the LiveKit agent on LiveKit Cloud. • The 8-replica limit is a hard, plan-enforced cap. If your usage tries to spin up more replicas beyond that cap, LiveKit Cloud will not create them. • When the cap is reached new sessions/jobs will queue or fail (higher session start latency, timeouts, or job failures) until capacity frees up. • You cannot raise this limit by changing runtime settings; you must upgrade to a higher plan (Scale or Enterprise) to allow more replicas/concurrency, or move to a self-hosted deployment where you control autoscaling and replica limits. • Monitoring: watch replica utilization and queue depth in the LiveKit Cloud dashboard/agent observability to see when you’re hitting the cap. If you tell me your current plan and expected peak concurrent sessions, I can recommend whether a plan upgrade or a self-hosted setup would be best and walk you through next steps. Sources: LiveKit Pricing | Custom agent deployments | LiveKit docs | Agents Framework | livekit/livekit_composite | DeepWiki | Agent server options | LiveKit docs | Deploy and scale agents on LiveKit Cloud
b
Unable to perform load test on LiveKit Cloud. Load testing is prohibited by our acceptable use policy: https://livekit.io/legal/acceptable-use-policy when I am trying to do the livekit testing I got this error
t
Thanks — I’m replying about the load-test error and the Acceptable Use Policy block. Short answer: • LiveKit Cloud prohibits significant load testing without prior written consent. Attempts to run tests without approval can be flagged and blocked as potential DoS activity. What you can do next: • Request written approval from LiveKit (include test window, expected concurrency, duration, and goals). LiveKit can approve or provide limits to run a sanctioned test. • Use the open-source Chrome Tester (recommended) for realistic client-simulated load; mention this when requesting approval. • Run tests in a separate staging project on LiveKit Cloud, or self‑host LiveKit where you control load testing and scaling. If you want, tell me: • The error message you saw (exact text or screenshot), and • Your planned test details (concurrency, duration, region), and I’ll help draft the approval request and recommend the safest testing approach. Sources: And…we’re Live(Kit)! | Announcing LiveKit Cloud