robin at gareus.org
Mon Aug 20 01:41:36 CEST 2018
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.
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
Browsing around in the pipewire source I see several potential design
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the Linux-audio-dev