Audio Context gets closed and cannot be resumed

[indexds]

Describe the bug

Hello,

I consistently get an issue that only occurs when using a headset. Everything will work perfectly for a few minutes after a call was started, until a certain point where the AudioContext gets closed by the browser(?) at which point I am screwed because it cannot be resumed. I assume livekit is trying to do that automatically because we get the following error in the logs:

Error trying to auto-resume audio context DOMException: Can't resume if the control thread state is "closed".

I tried setting webAudioMix to both true and false and the error remained.

My application is running on Firefox 142.0.1 and was also tested on Chromium with the same results.

Any insight is appreciated as this makes the application completely unusable.

Related issues: #1116 #1445

Reproduction

• Plug in a headset
• Wait for many(?) minutes
• Alt-tab out of the application(?)
• Eventually the AudioContext will be force closed by the browser at which point the only way to fix it is to close and reopen the browser.

Logs

Error trying to auto-resume audio context DOMException: Can't resume if the control thread state is "closed"
    handleResume http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:10333
    __awaiter http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:5765
    __awaiter http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:5747
    handleResume http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:10329
    getNewAudioContext http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:10340
    detectSilence http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:10300
    __awaiter http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:5765
    __awaiter http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:5747
    detectSilence http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:10297
    checkForSilence http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:14375
    __awaiter http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:5765
    __awaiter http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:5747
    checkForSilence http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:14374
    onLocalTrackPublished http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:21332
    __awaiter http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:5765
    __awaiter http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:5747
    onLocalTrackPublished http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:21325
    emit http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:5897
    publish http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:19538
    fulfilled http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:5750
    promise callback*step http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:5763
    __awaiter http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:5765
    __awaiter http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:5747
    publish http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:19308
    publishPromise http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:19260
    fulfilled http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:5750
    promise callback*step http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:5763
    __awaiter http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:5765
    __awaiter http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:5747
    publishPromise http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:19249
    publishOrRepublishTrack http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:19249
    fulfilled http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:5750
    promise callback*step http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:5763
    __awaiter http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:5765
    __awaiter http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:5747
    publishOrRepublishTrack http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:19158
    publishTrack http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:19154
    __awaiter http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:5765
    __awaiter http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:5747
    publishTrack http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:19153
    setTrackEnabled http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:19002
    fulfilled http://localhost:3000/node_modules/.vite/deps/chunk-673D7ERD.js?v=3e4507ff:5750
<anonymous code>:1:145535

System Info

System:
    OS: Linux 6.16 Fedora Linux 41 (Container Image)
    CPU: (20) x64 Intel(R) Core(TM) Ultra 9 185H
    Memory: 40.08 GB / 62.24 GB
    Container: Yes
    Shell: 5.9 - /usr/bin/zsh
  Binaries:
    Node: 22.19.0 - /usr/bin/node
    npm: 10.9.3 - /usr/bin/npm
    pnpm: 10.9.0 - /usr/bin/pnpm
    bun: 1.2.15 - /usr/bin/bun
  npmPackages:
    livekit-client: 2.15.7 => 2.15.7

Severity

blocking all usage of LiveKit

Additional Information

No response

[indexds]

Erratum: Unplugging and replugging the headset when the issue occurs temporarily fixes it. I assume an AudioContext is recreated when that happens.

[indexds]

So I isolated the issue to this function,

export function getNewAudioContext(): AudioContext | void {
  const AudioContext =
    // @ts-ignore
    typeof window !== 'undefined' && (window.AudioContext || window.webkitAudioContext);
  if (AudioContext) {
    const audioContext = new AudioContext({ latencyHint: 'interactive' });
    // If the audio context is suspended, we need to resume it when the user clicks on the page
    if (
      audioContext.state === 'suspended' &&
      typeof window !== 'undefined' &&
      window.document?.body
    ) {
      const handleResume = async () => {
        try {
          if (audioContext.state === 'suspended') {
            await audioContext.resume();
          }
        } catch (e) {
          console.warn('Error trying to auto-resume audio context', e);
        }

        window.document.body?.removeEventListener('click', handleResume);
      };
      window.document.body.addEventListener('click', handleResume);
    }
    return audioContext;
  }
}

We are entering the catch block because the audioContext.state is 'closed' at this point.

[indexds]

I isolated the issue further, I noticed many warnings about "silence detected on local audio track", which I initially ignored.
The warn is being thrown by this function,

  async checkForSilence() {
    const trackIsSilent = await detectSilence(this);
    if (trackIsSilent) {
      if (!this.isMuted) {
        this.log.warn('silence detected on local audio track', this.logContext);
      }
      this.emit(TrackEvent.AudioSilenceDetected);
    }
    return trackIsSilent;
  }

Which calls the following,

/**
 * This function detects silence on a given [[Track]] instance.
 * Returns true if the track seems to be entirely silent.
 */
export async function detectSilence(track: AudioTrack, timeOffset = 200): Promise<boolean> {
  const ctx = getNewAudioContext();
  if (ctx) {
    const analyser = ctx.createAnalyser();
    analyser.fftSize = 2048;

    const bufferLength = analyser.frequencyBinCount;
    const dataArray = new Uint8Array(bufferLength);
    const source = ctx.createMediaStreamSource(new MediaStream([track.mediaStreamTrack]));

    source.connect(analyser);
    await sleep(timeOffset);
    analyser.getByteTimeDomainData(dataArray);
    const someNoise = dataArray.some((sample) => sample !== 128 && sample !== 0);
    ctx.close();
    return !someNoise;
  }
  return false;
}

And therein lays the issue, when an audio track is detected as being silent, we kill the audio context which is bad.

[lukasIO]

Thanks for digging into this!

for a "new" AudioContext it should be fine to use it and close it. I think the problem here is that we're not unregistering the click handlers for auto resume once the AudioContext is closed.

[indexds]

Right I misread the function, I thought it would return the current audio context if it already exists and create a new one if it does not. Since it always creates a new one the ctx.close() inside the detectSilence function has no bearing on my issue.

I'll try to fix my PR, but that will not solve my original issue, the audioContext gets closed either way.

[indexds]

export function getNewAudioContext(): AudioContext | void {
  const AudioContext =
    // @ts-ignore
    typeof window !== 'undefined' && (window.AudioContext || window.webkitAudioContext);
  if (AudioContext) {
    const audioContext = new AudioContext({ latencyHint: 'interactive' });
    // If the audio context is suspended, we need to resume it when the user clicks on the page
    if (
      audioContext.state === 'suspended' &&
      typeof window !== 'undefined' &&
      window.document?.body
    ) {
      const handleResume = async () => {
        try {
          if (audioContext.state === 'suspended') {
            await audioContext.resume();
          }
        } catch (e) {
          console.warn('Error trying to auto-resume audio context', e);
        }

        window.document.body?.removeEventListener('click', handleResume);
      };
      window.document.body.addEventListener('click', handleResume);
    }
    return audioContext;
  }
}

It is especially interesting that we would enter the await audioContext.resume(); since that should be on the predicate that the state is suspended, which it is not, because it immediately fails, telling us the thread is closed.

[lukasIO]

So the warning log you're seeing should not cause any issues as the audio context is used exclusively for the silence detection.

It's somewhat unexpected that this causes issues with the headset.
Maybe additionally disconnecting the source like you did in your PR is the right move?

[indexds]

So the warning log you're seeing should not cause any issues as the audio context is used exclusively for the silence detection.

It's somewhat unexpected that this causes issues with the headset. Maybe additionally disconnecting the source like you did in your PR is the right move?

I don't think that is required, no. Closing the context should free up resources properly.

I might have gone in a completely wrong direction with my assumption to be honest. The facts are we are getting this issue where the audio context gets randomly closed a few minutes into the conversation. People can still see each other speaking (the camera works just fine) and screen shares work just fine as well. But "the audio context gets closed" was just an assumption at this point. I see nothing in the code that closes the audio context in any circumstance, so is it the browser? If so why and how?

And this only seems to happen when people plug headsets in. The issue occurs with different headsets, on both firefox and chromium. Unplugging and replugging one's headsets fixes the issue for them but not others. All of this points to a client javascript audio management issue, which is why I investigated the audio context related functions and found the single function that seems to close the context. Unfortunately, that seems unrelated.

[indexds]

Small update on this, the isSpeaking variable still updates correctly when speaking even though nobody can hear each other. This means that the mic does work properly so it ((shouldn't)) be a headset issue, especially because this occurs with different headsets. The data is properly sent to the SFU which then properly sends it to the other participants, we're just not listening for the audio anymore.

[indexds]

#1220 seems related

[indexds]

Whelp, in the end it was something stupid, as expected. The issue was we all use bad headsets that do not seem to work with pipewire: https://www.reddit.com/r/NobaraProject/comments/16pn9ka/psa_is_youre_using_pipewire_and_your_audio_cuts/