I will definitely be looking at the example applications. I want to eventually understand how DAW applications like Ardour and Qtractor in particular are written, but the source code of those apps are quite intimidating to me at the moment. If there is anything else I can do to aid in my learning, that would be great. -Kris

On Thu, Feb 16, 2012 at 04:00:22PM -0800, Kris Calabio wrote: Hi Kris, What you're approaching is a very large subject, covering many areas of software design. If you're interested in the signal processing part, you may look at something like sox or ecasound. There is no GUI to distract you. :-) For the user interface part, there are tons of resources on GUI design. To get familiar with a GUI toolkit you have to start creating widgets. gtk and Wx are popular at the moment. Nama, which I'm most familiar with :-), uses Ecasound for the audio processing, but otherwise aspires to be at least as capable as the Big GUI Boys. It's written in perl, so you as you begin to penetrate that syntax, you can see how the data structures are managed so that Ecasound gets the guidance it needs to DAW. Some years ago, I discovered how ignorant I was when I tried to make some sense of Ardour's class hierarchy and its functions. For the uninitiated, C++ sources are probably at least as hard to browse as perl. Your approach will depend a lot on the languages and toolkits you find worth investing to understand. -- Joel Roth

For a realtime application, you are probably going to need to put at least the core audio components in C/C++. I personally prefer Python as a general programming language, so for a project I am working on I have chosen to do it in 2 communicating processes, with the JACK audio part in C and the rest in Python. This seems to work pretty well, and could work for Clojure as easily. Thanks, Bill Gribble On Fri, 2012-02-17 at 06:17 -0800, Kris Calabio wrote:

Hi kallipygo, I can not answer all of your questions, but Harry may jump in and answer them. On 02/22/2012 10:56 AM, kallipygos(a)inbox.lv wrote: Yes, kind of. More precisely: you actually only ask JACK for a pointer. "Where can I read the audio-data from" -> reply: an array starting at this memory address. similar for write. No. What's confusing you is that there is no dedicated 'read/write'. You only ask: where to read from and where to write to. Those pointers are valid during the whole process callback function. You usually query them at the start of the process function. The data that resides in the outputBuffer memory-area (float array) is /written back/ at the end of each process callback. (Actually, JACK uses a "zero-copy" approach which makes it rather fast and efficient: JACK prepares a float[] array for your application to write _output_ audio to. You ask where that float-array is and write audio data to it. The next jack-client in the graph will be pointed to exactly the same memory as _input_. -- although in reality the implementation is a bit more complicated..) jack_get_ports() the source of 'jack_lsp' is a good example: https://github.com/jackaudio/tools/blob/master/lsp.c Be very careful with that. Most applications should not do this, but let the user connect ports: either manually or automatically using studio/session patchbay tools. In a studio: the playback1/2 outputs may correspond to a sub-woofer or be connected to something where you don't want any JACK client to send audio by default.. Speakers have been killed by auto-connecting JACK applications. That being said: jack_connect(c, jack_port_name(src_port), jack_port_name(dst_port)) but disable it by default or ask the user if s/he wishes to auto-connect ports,.. theoretically yes, practically no. You can change the data-format for the whole JACK system. It requires recompiling jack and adapting all jack-clients. e.g. "video-jack" does that it uses fixed-size RGB videoframes instead of "32bit float" no JACK as we know it officially only supports audio and MIDI. but in principle it can any data: control information, video,.. yes. One usually uses a for loop and an array of ports: outputPort[0], outputPort[1] Neither with separate ports. The First sample is outputPort[0] is played at the same time as the first sample in outputPort[N]. Some example code to de-interleave N-channel audio: https://github.com/erikd/sndfile-tools/blob/master/src/jackplay.c With JACK, two channel (stereo) audio is no different than forty-two channel sound (or 5.1 or whatever). One of the big features of jack is its simple interface. There's exactly ONE format for audio: 32bit float mono channels. No interleaving, no 16/24 bit conversions, no overflow/clipping inside the JACK graph (floats can go beyond -1.0 .. +1.0). Clipping is done as last step before the audio goes back to the device. Bit-dithering [if necessary and wanted] happens inside the server back-end that interfaces with the audio-device. Cheers! robin

Related with this topic, I would like to contribute with 3 pieces of code made with an educational point of view (though I don't teach audio processing and I don't consider an expert myself). These examples use libsndfile library, that is important if the source or the destination of your audio data is a wav file. a) jcapture: *http://wiki.joanillo.org/images/0/07/Jcapture-1.0.0.tar.gz reads the data coming from the microphone, and saves a wav file. Shows a textual signal meter in the console. (I know the existance of jack-capture. I didn't look at jack-capture code, sure that has better performance and lots of options, I just wanted the minimal code) b) jplay-sndfile-simple: *http://wiki.joanillo.org/images/1/1e/Jplay-sndfile-simple-1.0.0.tar.gz It's just a playback wav file. In the callback function there are two possibilities: copying blocks of memory; or copying sample by sample, and this permits a little signal processing (in this simple case just divide the signal by 2). I borrowed code from sndfile-jackplay.c (sndfile-tools-1.03, Erik de Castro Lopo & Jonatan Liljedahl), where is interesting the thread implementation  (playing while reading the file) that I didn't implemented. c) jplay-sndfile: *http://wiki.joanillo.org/images/e/e6/Jplay-sndfile-1.0.0.tar.gz This is more interesting and not simple like the previous. A part of playing back the file, it permits frequency shifting and frequency sweeping in a range between .5 and 2. Hope this helps to somebody, Joan Quintana

On 02/24/2012 05:52 PM, Harry van Haaren wrote: Jplay-sndfile-1.0.0 does zero-order hold. No up/downsampling, no interpolation. It'd actually be easier to just use librubberband for frequency shifting and time-stretching. _simple_? well maybe example code that comes with http://breakfastquay.com/rubberband/ http://www.teuton.org/~gabriel/stretchplayer/ (C++) uses librubberband. Samplecat's jack_player.c (C) uses LADSPA rubberband and libsamplerate. The code is not complicated; but probably does not qualify as simple.

Just thought I'd mention something I found, which has been working well. PythonQT allows you to embed a python interpreter with bi-directional passing in a C++ QT App. It's a bit under documented, but once you get it working, it's a really nice way to pass off non-rt critical tasks to python from within a C++ app. I have no affiliation with it, I just think it's dead cool because I didn't have to tackle inter-process communication to do high level data mangling in python! http://pythonqt.sourceforge.net/ iain

I updated the sources. One question. In jcapture, I printf the meter in the console with vertical bars '|' as usual. I calculate an average from 5 callback calls, and I printf the meter inside the callback functions, that is not real safe. Where to printf the meter? Must be inside the infinite loop for(;;)... this way is real safe? Joan Quintana --- On Fri, 2/24/12, Robin Gareus <robin(a)gareus.org> wrote: From: Robin Gareus <robin(a)gareus.org> Subject: Re: [LAD] Tutorial for programming with JACK To: "Joan Quintana" <joan_quintana(a)yahoo.com> Cc: Linux-audio-dev(a)lists.linuxaudio.org, "Harry Van Haaren" <harryhaaren(a)gmail.com> Date: Friday, February 24, 2012, 5:07 PM Hi Joan, Thanks for sharing those! On 02/24/2012 11:12 AM, Joan Quintana wrote: The linked tar-ball includes jcapture-0.0.1.cpp that does not save any .wav file. Calling printf() in the jack-callback function is not realtime safe; [but it's perfectly valid for debugging/development purposes and] I guess you simply mixed up the files. FWIW https://github.com/jackaudio/example-clients/blob/master/capture_client.c is very close to the minimal code required to do disk I/O. It does not include a meter, but supports multiple-channel. neat. There's some cruft in it (unused variables, binary (&) vs boolean (&&) AND in line 89) - compile with `-Wall` option: g++ will tell you. Otherwise it'd make a nice addition to https://github.com/harryhaaren/Linux-Audio-Programming-Documentation see previous email (reply to Harry). best, robin

there are many example clients in the JACK source code's "example_clients" directory. including, as luck would have it, jack_sine, which generates a sine wave (based on MIDI input) and even simpler, jack_metro which outputs a beep every 1/Nth of a second. this list and google contain a wealth of information on JACK programming, including at least one other thread on this same topic recently that had some highly relevant links. you are encouraged to explore the existing examples, tutorials and other resources available online before asking people to explain it all one more time. if you have questions once you've started with JACK because some things are not clear, then please ask away. On 3/7/12, kallipygos(a)inbox.lv <kallipygos(a)inbox.lv> wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Kris, Welcome back. On 02/17/2012 03:17 PM, Kris Calabio wrote: you will like: https://github.com/jackaudio/jack2/blob/master/example-clients/simple_clien… At least the DSP part of most pro-audio applications is written in C to have tight control over worst-case execution time of the code. The reason for this are real-time constraints: "close to hardware" here means to have control over memory-allocation and avoid [thread] locks [in the audio thread]. ie. * prevent the memory needed for DSP from being paged out. * don't do any memory alloc/dealloc operations in the audio thread JACK assists greatly with that (calls memlock, provides lock-free ringbuffers, etc) but you still need to know what you're doing in your DSP code. The above constraints rule out [most] garbage-collecting (object oriented) languages. It is NTL possible to carefully program sound processing in those langs but you'll need to know much more about what happens during compilation and/or interpretation of the language. C has the least pitfalls. A really good general introduction and nice read is http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-… Anyways, There are JACK bindings for a lot of languages incl. JAVA. The most recent announcement that crossed this email-list is https://code.google.com/p/java-audio-utils/ (I don't know if that lib works with Clojure, but it should) Yet all major (proper?!) sound-applications separate the audio (here: JACK) part from the user-interface and I/O in one way or another. Mixing languages for that is not uncommon. ciao, robin