livekit/client-sdk-js

Audio track.attach() appears to create more than one audio output?

rykkers opened this issue · 2 comments

rykkers commented

Describe the bug

Expected:
Receive remote audio track, attach it using track.attach(), then use the returned audio element to be able to alter sound output e.g. volume, muting, sinkId etc.

Actual:
No matter what i do with that audio element (even delete it), the audio continues to play. It's clearly being played through another audio element that hasn't been added to the DOM.

If this is a known 'feature' i'd recommend that it's added to the docs, as currently you're encouraged to add this new DOM element to the page, which is essentially useless.

Reproduction

I can reproduce on the demo app (https://meet.livekit.io/)

  1. Join a room with two people
  2. Access the remote audio DOM element audioElem = document.getElementsByClassName("lk-participant-media-audio")[0];
  3. Note that it is muted and volume 0 audioElem.muted
  4. If you unmute and set volume to 1 you'll hear echo as now two audio elements are playing the audio

Logs

No response

System Info

System:
    OS: macOS 14.0
    CPU: (10) arm64 Apple M2 Pro
    Memory: 1.21 GB / 32.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.3.0 - ~/.nvm/versions/node/v20.3.0/bin/node
    npm: 9.6.7 - ~/.nvm/versions/node/v20.3.0/bin/npm
  Browsers:
    Chrome: 125.0.6422.142
    Firefox: 118.0.2
    Safari: 17.0
  npmPackages:
    livekit-client: ^2.1.1 => 2.2.0

Severity

serious, but I can work around it

Additional Information

No response

lukasIO commented

This is expected, as the current default playback for remote tracks is via WebAudio.
There are APIs today that you can use to change volume (e.g. publication.setVolume).

That said, we're currently planning to change the default setting to not use WebAudio in this PR which also outlines some of the reasoning.

For a quick fix for you, just set webAudioMix: false in your room options

rykkers commented

Ok, that's amazing thanks.

Also a reminder for myself to also look at PRs before raising an issue.
Although i'm used to most PRs being attached to an "Open" issue.

Keep up the good work!