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

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 not tightly synchronized, whereas JACK is. But if you can make it work as well, more power to you. Concerning seeking and timing, though, I have had to wonder. My impression of JACK for a long time (and more learned ladies and gentlemen, please correct) is that it uses a basically round-robin approach to its clients, with variation. I have had to wonder, especially given my need for this <https://github.com/ponderworthy/MultiJACK>, how practical a model might be possible, using preemptive multitasking or even Ethernet-style collision avoidance through entropic data, at current CPU speeds. It's chopped into frames, right? Couldn't audio and MIDI data be mapped into networking frames and then thrown around using the kernel networking stack? The timestamps are there...the connectivity is there...have to do interesting translations... :-) Could be done at the IP level or even lower I would think. The lower you go, the more power you get, because you're closer to the kernel at every step. -- *Jonathan E. Brickman jeb(a)ponderworthy.com <http://login.jsp/?at=02e47df3-a9af-4cd9-b951-1a06d255b48f&mailto=jeb@ponderworthy.com> (785)233-9977* *Hear us at http://ponderworthy.com <http://ponderworthy.com> -- CDs and MP3s now available! <http://ponderworthy.com/ad-astra/ad-astra.html>* *Music of compassion; fire, and life!!!*