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)
10 Jan
10 Jan
10:40 p.m.
New subject: How to get started writing a JACK app? (also what distro for BeagleBone)
On Wed, Jan 10, 2018 at 04:01:55PM -0500, Paul Davis wrote:
My work is to develop DSP algorithms, and it's all done on Linux. I write
each of them as a Jack client which is also a Python class. So they can be
scripted, use OSC, have a PyQt Gui, interface to hardware controllers, or
whatever I need very easily. It's an extremely flexible way of doing things.
A typical test or demo setup consists of between 10 and 30 of such modules.
Most of my colleagues do similar work. They write VST plugins which they
run in Plogue Bidule on Windows. On the same hardware they easily get into
CPU load problems while the Linux/Jack/Python version of the same patch
runs happily taking only 30% CPU load.
So yes, be amazed.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
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.
My impression is that context switches are cheap compared to cache misses.
And those you'll have anyway.
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 :) 
10:53 p.m.
New subject: How to get started writing a JACK app? (also what distro for BeagleBone)
On Wed, Jan 10, 2018 at 3:48 PM, Andrew Voelkel
<jandyman.voelkel(a)gmail.com>
wrote:
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_get_sample_rate (jack_client_t *)
Allows being sample rate aware, then there is a call back that lets you
know if the sample rate has changed: jack_set_sample_rate_callback ()
A sample program does not get into these things, but from the samples it
seems pretty obvious how to use these other calls. I have found the jackd
API to be consistant in the way that it works though most of my jackd
clients have been MIDI not audio, I have had no problem figuring out the
midi from audio sample programs. The API is documented at
http://jackaudio.org/files/docs/html/index.html
Half way down the page is the text: "The full API is described in:" try
the links under that.
--
Len Ovens
www.ovenwerks.net
11:05 p.m.
New subject: How to get started writing a JACK app? (also what distro for BeagleBone)
On Wed, 10 Jan 2018 16:01:55 -0500
Paul Davis <paul(a)linuxaudiosystems.com> wrote:
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)
^^^^ This!
In my (very limited) experience, Jack is very easy to converse with for both
audio and MIDI. It's much easier than managing ALSA, and painless compared with
plugin hosts.
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
2307
days inactive
2307
days old
linux-audio-user@lists.linuxaudio.org
3 comments
4 participants
participants (4)
-
Fons Adriaensen -
Len Ovens -
Paul Davis -
Will Godfrey