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

[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
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 at 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!!!*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.linuxaudio.org/archives/linux-audio-dev/attachments/20180219/89763bd6/attachment.html>