Open metasystem opened 1 year ago
Remembering that Iris is only the browser-based web interface, does the issue persist when you have no browsers open on the Iris web app?
Iris will provide playback controls to the browser; to do this it provides an empty audio element which may be related.
The other factor is Snapcast which, if you have enabled streaming in your browser, will stream audio directly to your browser. Are you using Snapcast?
I don't use Snapcast, the problem only exist on iris (I tried the other mopidy web client). It seems iris don't consider people want to play on alsasink on the same computer as mopidy... I have to use ncmpcpp or rompr to remote...
To isolate the possible cause for this issue, we can deny the webpage permission to play audio.
Can you please use "Site Settings" for your Iris browser tab and mute audio? It should look a little something like this in Chrome:
With this change saved (and your browser tab reloaded), does the issue persist or is it gone?
hi, mute tab don't work because sound is not declared in browser... It's not a video or music by player, it's pipewire/pulse direct stream. It seems like kodi, playing blank sound to "mute" the speakers... I tried to mute in pipewire controller but don't work, the only way is to create "fake" pipewire output, use specific browser and output browser to fake output... In this case, music work on alsa on the rocks, but it is too complicated and not normal to do that. I remove mpd remote in mopidy, just start http and iris and the problem is already here, so the problem is not from mopidy, but from iris who send data to pipewire/pulse in backend. The stream start when click on "browse" and never disappear instead of close tab or browser. I think, navigation sounds have be implanted on code, but never add, and option never removed... Please, remove them, it is non-sense...
New info:
audio is identified in pipewire in firefox
For exemple:
I had blocked all permission on firefox and chrome
Google chrome blocks sound, but firefox not. So, iris bypass firefox user rights for audio access...
I think it's very bad because it's consider iris can pass over user decisions.
I think possibly firefox vulnerability or iris audio forbidden access.
bug reported on mozilla firefox bugzilla, linked to this thread...
Iris version
3.67.0
Operating system(s) affected
Browser(s) affected
What happened?
iris lock sound server when browse with blank sound. Locks alsa output for direct alsa playing. works if iris is launched from another support (because it lock sound server on the client machine, not on the host). tested on gentoo-current, manjaro, archlinux, debian. Tried on another mopidy and the problem exist only on iris (so not mopidy-http issue it seams). visible on pipewire with pw-top
Logs