[LAU] How to get started writing a JACK app? (also what distro for BeagleBone)

Paul Davis paul at linuxaudiosystems.com
Wed Jan 10 21:01:55 UTC 2018


On Wed, Jan 10, 2018 at 3:48 PM, Andrew Voelkel <jandyman.voelkel at 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)


​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-user/attachments/20180110/27d69ba3/attachment.html>


More information about the Linux-audio-user mailing list