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 directly from the interrupt handler of the audio interface. JACK does not use a round-robin approach to its clients. It creates a data (flow) graph based on their interconnections and executes them (serially or in parallel) in the order dictated by the graph. On Mon, Feb 19, 2018 at 5:57 PM, Jonathan Brickman <jeb@ponderworthy. com> wrote: > 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, 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. > >