Audio occasionally cuts out and requires rejoining

tepichord commented

2026-04-12 17:28:13 -07:00

Collaborator

Happened semi-frequently when @seb and I were testing #55. We caught the event when it happened in logs but we actually need a way to filter the logs with the tracing crate (preferably in a way that's controllable with the RUST_LOG environment variable), this is demonstrated here although alternatives are likely available.

Happened semi-frequently when @seb and I were testing #55. We caught the event when it happened in logs but we actually need a way to filter the logs with the tracing crate (preferably in a way that's controllable with the RUST_LOG environment variable), this is demonstrated [here](https://artificialworlds.net/blog/2025/03/29/rust-tracing-basic-setup/) although alternatives are likely available.

tepichord added this to the Ludwig (MVP) milestone

2026-04-12 17:28:13 -07:00

tepichord added the

bug

label

2026-04-12 17:28:13 -07:00

tepichord added this to the Feature Development project

2026-04-12 17:28:13 -07:00

puregarlic commented

2026-04-12 17:31:39 -07:00

Owner

@tepichord Log filtering might already be available to use. Check this out: https://docs.rs/tracing-subscriber/latest/tracing_subscriber/filter/struct.EnvFilter.html

seb commented

2026-04-13 09:10:21 -07:00

Collaborator

When I've seen/fixed this before it's because we send frames at a higher rate than expected, which causes the LiveKit server to try to do some attenutation/pushback stuff that I don't really understand. I've seen it before because my first implementation of mute was to send no frames rather than silent frames, which basically pinged the server at CPU clock speed instead of at the audio framerate.

As I understand it adverse conditions on the network, hiccups on an OS level, or bugs on our side could cause this. There is a warning displayed in the logs if this occurs, although I unfortunately don't know what the text of the warning is. There might be a LiveKit-side buffer that we can turn on and/or turn up in order to reduce the incidence of this if it isn't a bug on our end.

When I've seen/fixed this before it's because we send frames at a higher rate than expected, which causes the LiveKit server to try to do some attenutation/pushback stuff that I don't really understand. I've seen it before because my first implementation of mute was to send no frames rather than silent frames, which basically pinged the server at CPU clock speed instead of at the audio framerate. As I understand it adverse conditions on the network, hiccups on an OS level, or bugs on our side could cause this. There is a warning displayed in the logs if this occurs, although I unfortunately don't know what the text of the warning is. There might be a LiveKit-side buffer that we can turn on and/or turn up in order to reduce the incidence of this if it isn't a bug on our end.

seb commented

2026-04-13 09:18:12 -07:00

Collaborator

There could also be weirdness associated with joining/double joining the LiveKit server. @puregarlic is probably best positioned to debug it if you have more logs on the server side than we get from the client.

I suspect that if there are some latent issues with how the LiveKit server handles audio frames getting backed up, as opposed to this issue being a feature bug that I wrote (sorry) then you'd be able to replicate it in the main branch build (as of today, 4/13), rather than the build after we merge all of the PRs that are in-flight. We didn't observe it on that version of the repo, but we also didn't spend very much time testing it.

There could also be weirdness associated with joining/double joining the LiveKit server. @puregarlic is probably best positioned to debug it if you have more logs on the server side than we get from the client. I suspect that if there are some latent issues with how the LiveKit server handles audio frames getting backed up, as opposed to this issue being a feature bug that I wrote (sorry) then you'd be able to replicate it in the `main` branch build (as of today, 4/13), rather than the build after we merge all of the PRs that are in-flight. We didn't observe it on that version of the repo, but we also didn't spend very much time testing it.

Rows
Columns

Audio occasionally cuts out and requires rejoining #94