...I'm just using arcolinux (KDE5, 4.19-LT) so hopefully any generic solution will work without having to fight with the way the distro has set up the OS...

...The idea is to I suppose have something (script/job/config/etc) that monitors when a window that's playing audio, so that if/when that window is moved to the screen of a different monitor with it's own speakers and audio connection, that something automatically tells pulseaudio to switch the output to that monitor/speaker, without changing the output globally...

...But how do I do this?


Very partial answer:

There's no connection at all between the windows system (let's assume X and not Wayland) and the audio system (Pulseaudio).

Under X, the instance that can watch for a window moving to a different screen is the Window Manager (WM). KDE uses a particular WM.

You'd have to make sure that all applications that play sound make information about that available to the WM. There are generic mechanisms that allow to do something like this (properties on X windows).

The WM could then use this information to tell Pulseaudio to change the destination sink of playing streams when the window gets moved.

So it's doable, but you'd have to modify/wrap applications, and add a substantial part of code to the WM. I don't think anyone has ever done this before (probably because no one had the need), so probably there are no ready-made solutions for this, even outside of KDE.

  • Thanks for the answer...so there's no script-based approach available to just have an eventListener running for (onScreenChange(?)) events which one could add a script to change the target hardware for the moved applications audio i/o? – neuroDiverse Oct 26 '19 at 3:42
  • The WM would need to allow "scripts" that react to "onScreenChange". And I don't know any WM that does that (though possibly there is one). The X protocol has no concept of "screen change", multiple screens are a later add-on. What you get is Map and Unmap events, and it's the WM which listens to those events. And even with a script, you'd still have to identify the application to Pulseaudio, which is impossible with the normal information known to X. – dirkt Oct 26 '19 at 6:07
  • What about KDE's KWin scripts or the JavaScript based addon/plugin/extensions for the GNOME-Family? Just wondering if they count as "script-based WM enhancements/addons/plugins at all, whether or not they offer event listener functionality like most extendable applications have (Autodesk Maya, SideFX Houdini, Chrome/Firefox, etc)... – neuroDiverse Oct 27 '19 at 21:00
  • I am not familiar with these, so I can't say. My experience with KDE and Gnome desktops in general is that they are not very flexible in general abstract protocol terms, so I'd be surprised if it was there. – dirkt Oct 28 '19 at 4:46
  • It's kind of ironic that browser-based apps are more capable (through javascript) of controlling and interacting with sound and graphics HW than the OS...I wonder if I should create a separate ask regarding the feasability of a script-run DM/WM... – neuroDiverse Oct 30 '19 at 20:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.