Fixes#310 (with element-call#49, released as 0.25.0-lotus.24 and pinned here).
The call-bar audio output menu listed the chat page's devices, but browsers hash deviceId per frame/origin, so those ids mean nothing inside the call iframe. Picking "Headset" saved an unknown id in Element Call, which fell back to the default output, while the menu showed a ✓ on the device you picked.
Change
CallControl handles the fork's io.lotus.audio_output_state { deviceId, available: [{id, label}] }, which also silences the fork's "host did not ack" log on every change. A unit-tested parseAudioOutputState does the parsing.
AudioOutputButton builds the menu from the fork's list and effective selection. With older forks it falls back to the old list.
Fixes #310 (with element-call#49, released as **0.25.0-lotus.24** and pinned here).
The call-bar audio output menu listed the **chat page's** devices, but browsers hash `deviceId` per frame/origin, so those ids mean nothing inside the call iframe. Picking "Headset" saved an unknown id in Element Call, which fell back to the default output, while the menu showed a ✓ on the device you picked.
**Change**
- `CallControl` handles the fork's `io.lotus.audio_output_state { deviceId, available: [{id, label}] }`, which also silences the fork's "host did not ack" log on every change. A unit-tested `parseAudioOutputState` does the parsing.
- `AudioOutputButton` builds the menu from the **fork's** list and effective selection. With older forks it falls back to the old list.
- Pins `@lotusguild/element-call-embedded@0.25.0-lotus.24`.
**Verified** with the published lotus.24 (Chromium fake devices):
- The menu shows the frame's outputs.
- Picking "Fake Audio Output 2" makes Element Call save that **frame** device.
- The ✓ follows it, and there are 0 no-ack warnings.
This also covers the audio-output half of #260.
`tsc` clean · unit tests pass · ESLint clean.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_017PCb59uY3UKqDqt7B6hzd5
deviceIds are hashed per frame/origin, so the ids the menu got from the
chat page's enumerateDevices() were unknown inside the call iframe: the
fork fell back to the default output while the menu showed a tick on
the chosen device. Handle io.lotus.audio_output_state (also silencing
the fork's "host did not ack" log) and build the menu from the fork's
list and effective selection; older forks fall back to the old list.
Fixes#310
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PCb59uY3UKqDqt7B6hzd5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Fixes #310 (with element-call#49, released as 0.25.0-lotus.24 and pinned here).
The call-bar audio output menu listed the chat page's devices, but browsers hash
deviceIdper frame/origin, so those ids mean nothing inside the call iframe. Picking "Headset" saved an unknown id in Element Call, which fell back to the default output, while the menu showed a ✓ on the device you picked.Change
CallControlhandles the fork'sio.lotus.audio_output_state { deviceId, available: [{id, label}] }, which also silences the fork's "host did not ack" log on every change. A unit-testedparseAudioOutputStatedoes the parsing.AudioOutputButtonbuilds the menu from the fork's list and effective selection. With older forks it falls back to the old list.@lotusguild/element-call-embedded@0.25.0-lotus.24.Verified with the published lotus.24 (Chromium fake devices):
This also covers the audio-output half of #260.
tscclean · unit tests pass · ESLint clean.🤖 Generated with Claude Code
https://claude.ai/code/session_017PCb59uY3UKqDqt7B6hzd5