https://bugs.kde.org/show_bug.cgi?id=375943
--- Comment #60 from pallaswept <[email protected]> --- (In reply to Milkii B from comment #59) > what kind of patch does FF need to add a new JACK/PW metadata property that > can be used programmatically to tie a stereo set of > streams to a page/process/thread?", It's very complicated, and pretty far offtopic for a KDE forum. Short version: it's a lot. Long version... > which is why I started the FR issue over there If you share the link to that issue, that would be a good place to discuss it. I'll try and briefly address your question but, this is not the best place to continue the discussion. For chromium, I honestly haven't looked at it much but it won't be simple. They use pulse. As for firefox, they use pulse - a jack backend exists but is unsupported and the alsa backend is considered a fallback and can't help us here anyway. They aren't going to work on jack, it's beyond deprecated, it's retired, they're just leaving it there for now, but it's dead. pulse doesn't have an interface to set custom metadata, that's a pipewire feature. Firefox need to write a pipewire native backend to cubeb-rs and chromium a native Audio Session backend likewise, so that they can set custom metadata. Then cubeb has to get that metadata from firefox, which means a new handler in (based on how they set the tab title) I think its three places (AudioStream, MediaStream, and the RTC one I forget the name) in firefox. Or maybe the browser devs would do something different, I don't know. Maybe the reason they aren't working on the pulse backend is because they're working on a new pipewire backend already and have all this planned? Maybe there would be security implications in publishing window IDs and stream names in a shared space (Wayland security model being what it is)? Maybe they will expect DE's to provide an API to set it? Maybe they're planning an XDG portal for that, which none of us know about? I could imagine a lot of 'what ifs'. And any kind of planning or forethought might be pointless, they might just say no, or just not even respond at all. It's really something that would need to be discussed over there. All we know from the DE/sound server side, is that we can't get the data we need to do this job of relating a sound stream to a window, and that it does work on MS Windows because they use the default sound API to set the window ID as metadata on the stream. How or if they're going to provide a means to do this on linux, is up to them. If you have some sort of conversation with the browsers, it'd be great to share the link here so that KDE users effected by this can go there to talk about it. Obviously, this same issue effects all DEs, so I'm sure we'll be in good company :) -- You are receiving this mail because: You are watching all bug changes.
