macOS Chrome PWA audio remains "playing" after Talk call - headphones' other input sources blocked
Open
Nobody has claimed this yet.
bug
feature: call 📹
feature: frontend 🖌️
- Dominant language
- JavaScript
- Stars
- 2.2k
- Forks
- 586
- Avg merge
- 18h 27m
- Merged PRs (30d)
- 333
Description
Steps to reproduce
- Start a Talk call in a Chrome/Brave Progressive Web App and leave/end the call after some time.
- See after ending the call macOS still displays the App "playing" although it is silent and so blocking bluetooth headphones from selecting another input source - because they are still geting the "playing" signal from the Mac.
Expected behaviour
The "playing" status should vanish after ending the call.
Actual behaviour
The "playing" status remains after ending the call and only vanishes when quitting the PWA.
Talk app
Talk app version: 24.0.5
Custom Signaling server configured: yes
Custom TURN server configured: yes
Custom STUN server configured: yes
Nextcloud Version: 34.0.4.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the Talk call in a Chrome or Brave Progressive Web App on macOS, then trace the audio cleanup that runs when the call ends. Done means the app no longer shows as playing after the call and Bluetooth headphones can select another input source without quitting the PWA.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- audio-video-rtc
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 58/100