I'm Wim Taymans and I'm working on a new project called PipeWire you might
have heard about . I have given some general presentations about it during
its various stages of development, some of which are online .
PipeWire started as a way to share arbirary multimedia, wich requires vastly
different requirements regarding format support, device and memory management
than JACK. It wasn't until I started experimenting with audio processing that
the design started to gravitate to JACK. And then some of JACKs features became
a requirement for PipeWire.
The end goal of PipeWire is to interconnect applications and devices through
a shared graph in a secure and efficient way. Some of the first applications
will be wayland screen sharing and camera sharing with access control for
sandboxed applications. It would be great if we could also use this to connect
audio apps and devices, possibly unifying the pulseaudio/JACK audio stack.
Because the general design is, what I think, now very similar to JACK, many
people have been asking me if I'm collaborating with the linux pro-audio
community on this in any way at all. I have not but I really want to change
that. In this mail I hope to start a conversation about what I'm doing and I
hope to get some help and experience from the broader professional audio
developers community on how we can make this into something useful for
I've been looking hard at all the things that are out there, including
Wayland, JACK, LV2, CRAS, GStreamer, MFT, OMX,.. and have been trying to
combine the best ideas of these projects into PipeWire. A new plugin API was
designed for hard realtime processing of any media type. PipeWire is LGPL
licensed and depends only on a standard c library. It's currently targeting
At the core of the PipeWire design is a graph of processing nodes with arbirary
input/output ports. Before processing begins, ports need to be configured with a
format and a set of buffers for the data. Buffer data and metadata generally
lives in memfd shared memory but can also be dmabuf or anything that can be
passed as an fd between processes. There is a lot of flexibility in doing this
setup, reusing much of the GStreamer experience there is. This all happens on
the main thread, infrequently, not very important for the actual execution of
In the realtime thread (PipeWire currently has 1 main thread and 1 realtime data
thread), events from various sources can start push/pull operations in the
graph. For the purpose of this mail, the audio sink uses a timerfd to wake up
when the alsa buffer fill level is below a threshold. This causes the sink to
fetch a buffer from its input port queue and copy it to the alsa ringbuffer. It
then issues a pull to fetch more data from all linked peer nodes for which there
is nothing queued. These peers will then eventually push another buffer in the
sink queue to be picked up in the next pull cycle of the sink. This is somewhat
similar to the JACK async scheduling model. In the generic case, PipeWire has to
walk upstream in the graph until it finds a node that can produce something (see
below how this can be optimized).
Scheduling of nodes is, contrary to JACKs (and LADSPA and LV2) single 'process'
method, done with 2 methods: process_input and process_ouput. This is done to
support more complex plugins that need to decouple input from output and to also
support a pull model for plugins. For internal clients, we directly call the
methods, for external clients we use an eventfd and a shared ringbuffer to send
the right process command to the client.
When the external client has finished processing or need to pull, it signals
PipeWire, which then wakes up the next clients if needed. This is different from
JACK, where a client directly wakes up the peers to avoid a server context
switch. JACK can do this because the graph and all client semaphores are shared.
PipeWire can't in general for a couple of reaons: 1) you need to bring mixing of
arbitrary formats to the clients 2) sandboxed clients should not be trusted with
this information and responsability. In some cases it would probably be possible
to improve that in the future (see below).
This kind of scheduling works well for generic desktop style audio and video.
Apps can send buffers of the size of their liking. Bigger buffers means higher
latency but less frequent wakeups. The sink wakeup frequency is determined by
the smallest buffer size that needs to be mixed. There is an upper limit for the
largest amount of data that is mixed in one go to avoid having to do rewinds in
alsa and still have reasonable latency when doing volume changes or adding new
The idea is to make a separate part of the graph dedicated to pro-audio. This
part of the graph runs with mono 32bit float sample buffers of a fixed size and
samplerate. The nodes running in this part of the graph also need to have a
fixed input-output pattern. In this part of the graph, negotiating the format
becomes trivial. We can preallocate a fixed size buffer for each port that is
used to send/mix data between nodes. Exactly like how JACK works. In this
scenario it would be possible to bring some of the graph state to trusted
clients so that they can wake up their peers directly.
As it turns out, the generic scheduling mechanism simplifies to the JACK way of
scheduling and the option to do some optimisations (can directly start push from
the sources, bundle process_input/output calls, mixing on ports is simplified by
equal buffer sizes, ...)
There is a lot more stuff that I can talk about and a lot of things that need
to be fleshed out like latency calculations, an equivalent of JACK transport,
session management, ... But this mail is already getting long :)
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.
PipeWire is currently still in heavy development, many things can and do
still change. I'm currently writing a replacement libjack.so that runs jack
clients directly on PipeWire (mixing and complicated scheduling doesn't
Hope to hear your comments,
I'm pleased to announce the 1.1.0 release of hexter, a DSSI softsynth
plugin that models the sound generation of a Yamaha DX7 synthesizer.
This release provides support for DSSI hosts which don't support
run_multiple_synths(), for example, Carla and Renoise. Each instance of
the plugin is run separately, and support for the global polyphony
limit has been removed.
Several bugs and numerous compiler warnings have been fixed.
Find hexter here:
The distribution tarball is here:
More information on the DSSI plugin standard, available hosts and
plugins can be found here:
hexter is written and copyright (c) 2018 by Sean Bolton, and licensed
under the GNU General Public License, version 2 or later.
Thanks to Andreas Müller for contributing a bug fix.
It seems, that rosegarden forces gui font to be Sans. On my system
default sans seems to be droid. In qt5, with russian locale, russian
bold letters are drawen by some kind of Courier New. Regular font is
still Sans, and this bug seems to affect all qt5 stuff - i noticed it
first time in Converseen.
After i changed to Deja Vu, and yet later began to search for more
interesting fonts (up to tomorrow i had Exo), problem disappeared. For
qt5 config i use qt5ct.
Today i assidentally discovered font pair, which imho looks awesome
with programs like MuseScore and Rosegarden. I don't know, is it
intended to force some specific font... so i want to propose as variant
to use any Serif font. Last time i tried CMU fonts:
CMU has very interesting (imho) serif variants (though simple sans
style also presents). Especially i want to note:
- Contrete - as easy to read as any Serif, but more interesting, than
its own CMU Serif - i.e., it looks much sharper.
- Pair of two fonts:
- - CMU Serif Upright Italic: regular ornamental font
- - CMU Classical Serif: former's italic kind (both have bold kinds)
And i would note, there is some mess in names. Thus, upright italic is
not really italic (just looks ornamental), while simple classical looks
like "CMU Serif Upright Italic" Italic :). Would be better for them, of
course to be in one "CMU Classical" font, providing as usually - 4
This of course, is for aesthetes :)
Screenshot with musescore, with CMU Classical font:
I guess (it is still my imho+taste), all these Serif/Concrete/Classical
fonts would look much better in rosegarden. Can't tell about other (even
musical) software, but for now i made "CMU Serif Upright Italic"
default font - in qt5ct, desktop appearance settings (xfce), and now
trying to get for qt4. It exactly works with qjackctl and musescore.
About qtractor, if Rui Nuno Capella reads, there are few places,
where, where sans is forced:
- clock on toolbar,
- files list and track list use sans italic.
I don't know, is it sideback of setting to italic, but track list ruler
uses regular sans. But still, BPM display, near of clock,
followes system font.
It has been quite some time since I last wrote here.
Please forgive me for using this channel for such communication but we have
some news that are particularly interesting for this community in special.
MOD Devices is growing. You can read a bit here:
We're opening a job position specifically targeted to Linux Audio. Since
this is the place were most of the matching profiles communicate, I thought
it might be a good place to publish it here.
Please contact us if interested and feel free to pass on to friends from the
Linux Audio community that you think might be interested.
+49 160 646 9313
+49 030 555 70435
10829 - Berlin
FFADO version 2.4.1 is now available, a package of userspace drivers for
firewire audio interfaces. This is a bugfix release with many of the
changes associated with the use of python3 and distribution packaging.
This is a source-only release which can be downloaded from the ffado.org
or via the direct link:
Issues addressed in this release include:
* Fix some python syntax which was not compatible with python3. These
were missed during the preparation of FFADO 2.4.0.
* Modify the SCons build system to allow for scons running under python3.
As of this release there seem to be a number of issues in scons itself
when running under python3, so building FFADO in this environment is not
* Merge distribution patches provided by package maintainers.
* Address some difficulties experienced by package maintainers when
* Improve the output of ffado-diag.
Thanks to the developers and users who contributed to this release: Nicolas
Bouleng, Benoit Delcour, David Kastrup, Hector Martin, Orcan Ogetbil, Dave
Plater, David Runge, Jano Svitok and Jonathan Woithe. If an omission has
been made please contact us through the ffado-devel mailing list so this can