Hi everyone,
I'm Wim Taymans and I'm working on a new project called PipeWire you might
have heard about [1]. I have given some general presentations about it during
its various stages of development, some of which are online [2].
PipeWire started as a way to share arbirary multimedia, wich requi
On Mon, 19 Feb 2018, Wim Taymans wrote:
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 g
Greetings, Wim. Amazing project you have there. I hope you succeed. Len
has covered lots of excellent thoughts. Here are a few more, clearly
intersecting.
First of all, it's a great idea. I'd love to see one layer which could do
all of JACK and pulse. But the pitfalls are many :-) It's w
Not really sure the subgraph is so good -- one of the things JACK gives us
is the extremely solid knowledge of what it just did, is doing now, and
will do next period. If I run Pulse with JACK, it's JACK controlling the
hardware and Pulse feeding into it, not the other way around, because Pulse
is
JACK is already much closer to the hardware than the networking stack.
At the conclusion of the jack process callback, it writes samples *directly
into the memory mapped buffer being used by the audio hardware*. The
process callback is preemptively (and with realtime scheduling) triggered
directl
Many thanks, Paul, for this and much more. My lame excuse is I have
had a chunk of my head buried in a singular problem for a long time and
those librarians are very tired :-)
Given reality-check, then, maybe the institution of multiple JACK
subgraphs, with time-decoupling by Pulse-style transport
