On 02/19/2018 09:39 AM, Wim Taymans wrote: [...] > I would very much like to hear your ideas, comments, flames, thoughts on this > idea. I think I'm at a stage where I can present this to a bigger audience and > have enough experience with the matter to have meaningful discussions.
Hi Wim, I think the general lack of enthusiasm about pipewire here is because it does not solve any issues for linux-audio and at best does not introduces new ones. In the past years the most prominent question that I have received is * How can I use all of my USB Mics with Ardour on Linux? * How do I uniquely identify my many MIDI devices? * Why does my audio device not have proper port-names? * Why can't I re-connect my device and resume work? These questions are mostly from Mac or Windows users moving to Linux ... and many of them moving back to MacOS. While it is not impossible to combine multiple devices, it is not a straightforward to set this up. Manging devices uniquely and handling temporarily missing devices is not possible on GNU/Linux AFAIK. If you try to come up with a new system (think pipewire), please copy as many concepts as possible from Mac's CoreAudio. Both pulseaudio and jack had the correct idea to present audio as a service to applications. The server is concerned with device(s) and device settings. However, both fail to abstract multiple devices, map their port uniquely and provide multiple apps to concurrently use those devices for different purposes. The main issue with pulse is that it is a poll API. Also pulseaudio's per device, per port-latency is incorrect (if set at all). JACK on the other hand is too limited: single device, fixed buffersize. jackd also periodically wakes ups the CPU and uses power (even if no client is connected). Browsing around in the pipewire source I see several potential design issues. In particular data format conversions: The nice part about JACK is that uses float as only native format. Also port-memory is shared between application with zero-copy. In pipewire a port can be any data-type including vorbis and worse MIDI is a bolted-on sub-type on an audio port. JACK-MIDI has in the past been criticized most because MIDI was a dedicated type instead of JACK providing generic event-ports. Another conceptual issue that I see with pipewire is that it pushes sync downstream (like gstreamer does), instead of sources being pulled upstream. This in particular will make it hard to compensate for latencies and align outputs. Implementation wise there are plenty of other issues remaining to be discussed, e.g. context-switches, resampling, process-graph,.. but those are not important at this point in time. Cheers! robin
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev