10 Jan
2018
10 Jan
'18
10:02 p.m.
On Wed, Jan 10, 2018 at 3:48 PM, Andrew Voelkel <jandyman.voelkel(a)gmail.com>
wrote:
Glad to hear the discussion. From an outsider’s point
of view, there are
few things I don’t get.
First, if each JACK app is a separate process, then theoretically you have
to do a bunch of expensive process context switches for each audio buffer.
In the scheme of things, a context switch is typically not very expensive
compared to a typical audio buffer size (say 16 samples and up). The only
way it gets unusually expensive is if a process touches a lot of memory
during its execution. This isn't impossible in an audio/DSP context, but it
isn't very likely either.
And then there is interprocess communication. Uses
shared memory buffers?
it's all in shared memory. there's no communication overhead.
As opposed to a typical plug-in architecture where everything runs under
the host process. It is amazing to me that an
interprocess scheme wouldn’t
run into major problems under compute load when running with the small
buffers needed for low latency.
be amazed :)
What am I missing here?
The other thing I’m used to seeing in a plug in API is setup for buffer
sizes, sample rates, audio IO. The host centralizes this process.
JACK does the same thing. Each client has no control over those things (at
least, not in the normal way). They can ask to change the buffer size, but
their request may be ignored, or it may be reset by something else. Just
like in a plugin architecture.
Then there is advertising your pins and capabilities. I was mystified when
looking at the simple JACK examples that I didn’t see
code for dealing with
these issues (e.g. being sample rate aware).
JACK clients have only one thing of interest to other clients: ports.
These are all clearly visible, and tagged appropriately (though for most
clients, there's almost no tagging to do)