Not just highly-mobile users... as a desktop user who occasionally plugs in a USB headset, I don't think I've ever seen it automatically switch over. I've always had to go into the Gnome sound settings and select the device, so if Pipewire were to make it possible to say "always prefer this input/output device if present", it'd be really nice.
Oh, certainly. I should have put that in quotes, because the problems impact any setup where the audio configuration changes dynamically, whether it's Bluetooth audio, external sound cards, plugging in a monitor, plugging in headsets of any description, or outputting audio over the network via AirPlay and the likes. Hopefully we can figure this out better once we have a full view of it.
The best fun I had recently was when I switched my audio output to the HDMI monitor, started some music playing, and hit the Lock Screen key while going to make myself a cup of tea.
DPMS power off apparently turns off the audio as well on this LG monitor.
(And then at a latter point in time I discovered that unplugging the HDMI cable does not switch the PulseAudio output back to internal speakers.)
My main goal in attending this hackfest was to discuss Pipewire integration in the desktop, and how it will eventually replace PulseAudio as the audio daemon.
The main problem GNOME has had over the years with PulseAudio relate mostly to how PulseAudio was a black box when it came to its routing policy. What happens when you plug in an HDMI cable into your laptop? Or turn on your Bluetooth headset? I've heard the stories of folks with highly mobile workstations having to constantly visit the Sound settings panel.
PulseAudio has policy scattered in a number of places (do a "git grep routing" inside the sources to see that): some are in the device manager, then modules themselves can set priorities for their outputs and inputs. But there's nothing to take all the information in, and take a decision based on the hardware that's plugged in, and the applications currently in use.
For Pipewire, the policy decisions would be split off from the main daemon. Pipewire, as it gains PulseAudio compatibility layers, will grow a default/example policy engine that will try to replicate PulseAudio's behaviour. At the very least, that will mean that Pipewire won't regress compared to PulseAudio, and might even be able to take better decisions in the short term.
For GNOME, we still wanted to take control of that part of the experience, and make our own policy decisions. It's very possible that this engine will end up being featureful and generic enough that it will be used by more than just GNOME, or even become the default Pipewire one, but it's far too early to make that particular decision.
In the meanwhile, we wanted the GNOME policies to not be written in C, difficult to experiment with for power users, and for edge use cases. We could have started writing a configuration language, but it would have been too specific, and there are plenty of embeddable languages around. It was also a good opportunity for me to finally write the helper library I've been meaning to write for years, based on my favourite embedded language, Lua.
So I'm introducing Anatole. The goal of the project is to make it trivial to write chunks of programs in Lua, while the core of your project is written in C (we might even be able to embed it in Python or Javascript, once introspection support is added).
It's still in the very early days, and unusable for anything as of yet, but progress should be pretty swift. The code is mostly based on Victor Toso's incredible "Lua factory" plugin in Grilo. (I'm hoping that, once finished, I won't have to remember on which end of the stack I need to push stuff for Lua to do something with it ;)
"Pipewire Hackfest 2018"
3 Comments -
Not just highly-mobile users... as a desktop user who occasionally plugs in a USB headset, I don't think I've ever seen it automatically switch over. I've always had to go into the Gnome sound settings and select the device, so if Pipewire were to make it possible to say "always prefer this input/output device if present", it'd be really nice.
31 October 2018 at 12:43
Oh, certainly. I should have put that in quotes, because the problems impact any setup where the audio configuration changes dynamically, whether it's Bluetooth audio, external sound cards, plugging in a monitor, plugging in headsets of any description, or outputting audio over the network via AirPlay and the likes. Hopefully we can figure this out better once we have a full view of it.
31 October 2018 at 13:21
The best fun I had recently was when I switched my audio output to the HDMI monitor, started some music playing, and hit the Lock Screen key while going to make myself a cup of tea.
DPMS power off apparently turns off the audio as well on this LG monitor.
(And then at a latter point in time I discovered that unplugging the HDMI cable does not switch the PulseAudio output back to internal speakers.)
31 October 2018 at 15:12