For me Jack has been confusing as I'm not sure in
what process/thread
my audio routine runs. Somebody here wrote Jack's interesting thing is
its not your job to know which thread, only that it runs in a
different thread that you do not control, and that you should not block.
that it can route audio through applications. I
don't want that.
I want that Jack takes my C function (or its compiled object) and
executes that within the real-time audio engine.
well, it does both, in order to better maximise peace, love and
happiness throughout the world and beyond.
Even if Jack is used, should one prepare process
non-realtime audio
within your own application. You cannot send background audio
processings to Jack. Threads in the application are important
because it is not good that the whole application freezes when
one opens a big audiofile to editor, for example.
the capture client gives a good pedagogical example of how to handle
stuff in another thread so that you don't block the audio thread. it
might make sense to come up with jack_play at some point, but i've
resisted it because alsaplayer exists already.
I have not yet seen even moderate explanations or
guides on those
topics. We have discussed about Model-View-Controller (MVC)
scheme, but nobody seemed to have any practical tool-level
explanations so that I could easily use MVC in my applications.
MVC is an approach for writing UIs and/or control models. code with no
control path, or a control path that is invisible to the code
(e.g. LADSPA) doesn't really benefit from MVC. MVC also isn't a tool
level approach, its a design method that you mostly have to keep in
your head as you work. i've never seen any tools that enforce or
support an MVC model.
I suggest to start with Jack, not with Alsa or OSS.
It took me an hour to write a Theremin synth, sort of.
Very easy. (GUI was built with GTK+.)
that's great to hear.
--p