So anyone reading my blog posts would probably have picked up on my excitement for the PipeWire project, the effort to unify the world of Linux audio, add an equivalent video bit and provide multimedia handling capabilities to containerized applications. The video part as I have mentioned before was the critical first step and that is starting to look really good with the screen sharing functionality in GNOME shell already using PipeWire and equivalent PipeWire support being added to KDE by Jan Grulich. We have internal patches for both Firefox and Chrome(ium) which we are polishing up to propose them upstream, but we will in the meantime offer them as downstream patches in Fedora as soon as they are ready for primetime. Once those patches are deployed you should have any browser based desktop sharing software, like Google Hangouts, working fully under Wayland (and X).
With the video part of PipeWire already in production we decided the time has come to try to accelerate the development of the audio bits. So PipeWire creator Wim Taymans, PulseAudio developer Arun Raghavan and myself decided to try to host a PipeWire hackfest this fall to bring together many of the core Linux audio developers to try to hash out a plan and a roadmap. So I am very happy to say that at the end of October we will have a gathering in Edinburgh to work on this and the critical people we where hoping to have there are coming. Filipe Coelho who is the current lead developer on Jack will be there alongside Arun Raghavan, Colin Guthrie and Tanu Kaskinen from PulseAudio, Bastien Nocera from the GNOME project and Jan Grulich from KDE will be there representing desktop integration and finally Nirbheek Chauhan, Nicolas Dufresne and George Kiagiadakis from the GStreamer project. I think we have about the right amount of people for this to be productive and at the same time have representation from everyone who needs to be there, so I am feeling very optimistic that we can come out of this event with both a plan for what we want to do and the right people involved to make it happen. The idea that we can have a shared infrastructure for consumer level audio and pro-audio under Linux really excites me and I do believe that if we do this right Linux will take a huge step forward as a natural home for pro-audio desktop users.
A big thanks you to the GNOME Foundation for sponsoring this event and allow us to bring all this people together!
What problems does PipeWire solve?
It solves a multitude of problems. First of all it ensures we have a proper way of providing audio and video hardware access for sandboxed applications. Secondly it provides a unified solution for user space and pro-audio, which means pro-audio users will no longer have to read howto’s on how to get Jack going on their system and how to avoid potential conflicts with PulseAudio over HW control etc. And third it provides a video equivalent of PulseAudio making dealing with cameras, screen capturing etc. a lot simpler for developers.
Cool! Shouldn’t that ideally also include some ALSA people?
We plan to try to do another event a bit further down the road where we plan to invite ALSA and V4l people, but this event is strongly going to be focused on getting feature parity and API compatibility with Pulse and Jack, so we don’t want to widen the group so much that we are unable to keep that focus. That said if someone from the ALSA team asked to come we wouldn’t say no.
This is great, I’d love to see a better user experience with proaudio on linux
Do not forget that reliable (pro) audio really wants a pull model (with a push model provided on top for apps that do not care about low-latency), roughly as what coreaudiod does on OSX.
A DLL to accurately predict where the audio hardware’s read pointer is, to be able to provide different latencies to different audio applications at the same time would be great too, and would enable low-lat when needed while providing low-power-usage when no low-latency app is running.
Any model that builds on top of push-only (that is software decides when to give data to the audio driver, thus the driver *has* to provide a large enough buffer so that there is no underrun) is doomed to fail to provide reliable low-latency without eating huge amounts of CPU. That’s happening now with the USB audio stack where the driver allocates a “safety” buffer whose size is varying and cannot be queried, thus latency compensation is a nightmare (and even when asking for small buffers you actually get twice or thrice the latency).
The risk with not involving core ALSA devs, and maybe the originators of JACK in the loop is choosing a design that cannot really accomodate the above needs, thus not achieving the laudable goal of JACK/Pulse unification…
Cheers,
This would be amazing and is desperately needed in the Linux world. Pulse actually makes my laptop unstable. I’m done with all of the layers, let’s just do sound correctly once and for all.
What’s going to happen with midi? In particular sample accurate sync with audio?
There’s also an audio mini-summit scheduled for the 21st (just before ELC) which *will* have some ALSA and driver people there, it’d be good to at least get some crossover if we can.
https://blog.sirena.org.uk/2018/09/19/2018-linux-audio-miniconfernce/
(it was announced earlier on the list, took me a while to sort out my blog :/ ). I’m just about to start the thread on the schedule, I’ll mention this.
One question here would be if you’re talking to the Android people involved, and especially if the licensing can be suitable for them. The fact that Android is off on the side is a frequent pain point for all this stuff, the more we can do to converge what they’re doing with what the rest of the Linux ecosystem is doing the better.
Would it be a good idea to invite a developer from one of the professional digital audio workstations? Reaper in particular (www.reaper.fm) are alone in providing an unsupported Linux build, so they might care to provide insight as to what features are needed for these types of tools to work, and give feedback for the API.
Pipewire is a great initiative and I’m hoping you can improve the state of the art in Linux audio. However, I must also agree with #6 that if the pro audio people are not involved in the design, there’s a risk of XKCD 927 happening.
Regarding #10, might be also a good idea to invite people from Bitwig and Tracktion, who provide supported Linux builds of their DAWs.