Re: [LAD] PipeWire, and "a more generic seeking and timing framework"

2018-02-19 Thread Jonathan E. Brickman
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

Re: [LAD] PipeWire, and "a more generic seeking and timing framework"

2018-02-19 Thread Paul Davis
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

[LAD] PipeWire, and "a more generic seeking and timing framework"

2018-02-19 Thread Jonathan Brickman
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