>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
