This message was deleted.

PS. Kudos to the team for the great work, LiveKit seems really nice even at this pretty early stages! 👍

Are you setting

audioBitrate

in your track publishing options? https://docs.livekit.io/client/publish/#advanced-track-management We don’t resample audio; the layers for low/medium/high quality are only used for video. Also are you setting

AudioCaptureOptions

in

setMicrophoneEnabled

? https://docs.livekit.io/client-sdk-js/classes/LocalParticipant.html#setMicrophoneEnabled

For the DJ, you can get the optimal audio quality with: • AudioCaptureOptions ◦ channelCount: 2 ◦ echoCancellation: false ◦ noiseSuppression: false ◦ autoGainControl: false • TrackPublishOptions ◦ audioBitrate: 320_000 ◦ dtx: false these should minimize any type of processing WebRTC performs (which are typically tuned for voice conversations). For audience, defaults should work well for them

Thanks for the help! 👍 I'm using those exact settings for the DJ, but the audio quality seems to fluctuate quite a bit during my short ~15min tests. I'm not yet familiar with the codec but it seems to make all kinds of artifacts, audible speedups etc. to the sound very easily, which kills the listening experience compared to RTMP streams. But as the tools are so powerful, I'm pretty hopeful that learning enough of the underlying codecs and tech will help 🙂 (Btw. It would be super nice to have to have for example a flag for the cli load-test command to feed it your own audio source -- would help quite a bit in testing music applications (which are very different to voice/speech in general)!)

if audio seems to fluctuate (speedup/etc), then it might be a sign that it's publishing at a bitrate that's too high for the publisher and/or subscribers. WebRTC is much more sensitive to network fluctuations compared to RTMP, due to low latency requirements. In terms of load testing, you could publish a pre-encoded file with this command. and then spin up subscribers with

livekit-cli load-test

yeah, we can look at supporting CBR mode too. that's currently not enabled as it requires some SDP wrangling with WebRTC. FWIW, it would be the publisher encoding in CBR. the SFU only forwards data, and does not re-encode.

Great info, thanks! 👍