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.

--
Jonathan E. Brickman   jeb@ponderworthy.com   (785)233-9977
Hear us at http://ponderworthy.com -- CDs and MP3s now available!
Music of compassion; fire, and life!!!

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev