> Gstreamer is certainly not perfect but its strengths and weaknesses should be evaluated in comparison to the alternatives.
Meant to respond to this point as well. One of the criticism I would offer about gstreamer is that it is making simple things far more complicated than they have to be. The number of audio formats it supports is a prime example. It is as if there was a belief that converting between two formats was so impossibly costly that you can't possibly afford it, which is bit of crazy given the low data rate of audio and the extremely fast CPUs available everywhere, including mobile devices. So instead of supporting every imaginable format and providing algorithms that work with every format you can name, how about nominating one privileged format and promoting audio from source and demoting it (with appropriate dithering) when entering a sink?
A good compromise audio format might be 32-bit integer (with unity = 1 << 24) or 32-bit float, both would work quite well, and my personal preference would be for floating point audio because it is simpler to work with. The design does not really make it easy to pass high-quality audio through the pipeline, for instance the volume control does not support dithering and for this reason one should always convert audio to some high-quality intermediate format after demuxing. On the other hand, the audioconvert module does do dithering and even defaults to a reasonable algorithm, so if you know what you are doing it is possible to get good result. However, it would be better if the good result was given by default, especially as the cpu cost to do so is low and architecture would be significantly simplified.