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

From: Paul Davis <paul@email-addr-hidden>
Date: Tue Feb 20 2018 - 01:04:51 EET

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@email-addr-hidden>
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 <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@email-addr-hidden
> <http://login.jsp/?at=02e47df3-a9af-4cd9-b951-1a06d255b48f&mailto=jeb@email-addr-hidden> (785)233-9977
> <(785)%20233-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!!!*
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@email-addr-hidden
> https://lists.linuxaudio.org/listinfo/linux-audio-dev
>
>

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Mon Jun 18 21:47:10 2018

This archive was generated by hypermail 2.1.8 : Mon Jun 18 2018 - 21:47:11 EEST