JACK TRANSPORT AUDIT ==================== Gabriel M. Beddingfield 2008-09-16 ABSTRACT -------- This is a set of tools for auditing how well different applications conform to the JACK transport. It's primarily intended for people who are writing applications that have support for the JACK transport. These tools are free software, distributed under the GPL (either version 2 or any later version). DESCRIPTION ----------- This package provides the following tools: t_source_audio - An ideal transport audio source that generates a single, full-scale sample every 22050 frames. t_sink_audio - An ideal transport audio destination that reports the frames where it receives a full-scale sample. t_source_midi_jack - An ideal transport MIDI source that generates a C3 note on/note off event that lasts for one sample, and it does so every 22050 frames. t_sink_midi_jack - An ideal transport MIDI destination that reports the frame and MIDI message for the first 16 3-byte messages that it receives (this includes note on/note off events). This package also provides a test setup for the Hydrogen drum machine application. (See the apps/ directory). Note that other source/sink testers are welcome. BUILDING -------- The makefile is pretty simple, so season it to taste. However, most people will simply be able to: $ make And it will build all the test clients. USAGE ----- These test clients aren't particularly user-friendly, but this is so that the code will be simple, easily understood, and easily verified as correct. Here's some typical test setups: A. To test the audio source/sink testers: (1) Start the JACK server. Make sure that the transport is NOT rolling, and is located at the beginning (0). (2) Start t_source_audio and t_sink_audio independently. They will not give any output. (3) Manually connect the Output audio signal from t_source_audio.cpp into the Input audio port for t_sink_audio.cpp (4) Start the JACK transport. After 6 seconds, t_sink_audio will output: 0 22050 41000 63050 ... And it will exit. If you get a different series of numbers, then somebody failed the test (either the source or the sink). If you get exactly these numbers, then both clients pass the test. (5) Shut down all the applications, or rezero the transport and re-run the tests (without shutting down). B. To test with Ardour: (1) Start the JACK server. Set the sample rate to 44,100 Hz (so that barlines will match in Ardour). Make sure that the transport is NOT rolling, and is located at the beginning (0). (2) Start t_source_audio. It will not give any output. (3) Start Ardour. Set the tempo to 120 bpm, and set it to use the transport (either as master or slave is OK). (4) Manually connect the Output audio signal from t_source_audio.cpp into the Input of the Ardour track. (5) Start the JACK transport. You should see samples happen on each beat, but otherwise none. If they miss the beat, then Ardour is is adding some sort of compensation. (5) Stop the transport, and run more tests as desired. C. To test with Hydrogen: (1) Start the JACK server. Set the sample rate to 44,100 Hz (so that barlines will match with Hydrogen). Make sure that the transport is NOT rolling, and is located at the beginning (0). (2) Start t_sink_audio. It will not give any output. (3) Install the Hydrogen drumkit in apps/hydrogen/drumkits. It tries to simulate t_source_audio. Start hydrogen, and load the song apps/hydrogen/test_pattern.h2song. Make sure that the tempo is set to 120 bpm. (4) Manually connect the Output audio signal from Hydrogen into the Input of t_sink_audio.cpp. (4) Start the JACK transport. After 6 seconds, t_sink_audio *should* output: 0 22050 41000 63050 ... And it will exit. If you get different numbers, then Hydrogen failed the test. Notes: (a) The series may be 1, 22051, 41001, etc... but that might be caused by the sample I created in the drumkit. (b) Hydrogen 0.9.3 is known to pass the test, Hydrogen 0.9.4-svn is known to typically *not* pass the test, and 0.9.4-beta and 0.9.4-beta2 are known to pass the test. DEVELOPERS ---------- Contributions are appreciated. One thing to avoid: _DON'T_ make things complicated or hard to read. It's really tempting to add lots of command line options, abstract layers, a testing framework so that all the clients are reusing the same code (instead of copy-pasting code), error handling, exception handling, automatic pass/fail conclusions, etc. These defeat the purpose: Simple, easy to understand, easy to *verify*, transport clients for auditing ones that are more complex, and are not easy to verify. ABOUT ----- The original client was written by Fons Adriaensen in 2008 and posted to the jack-devel mailing list (see Documentation/). This example was shamelessly copied to create all the clients by Gabriel M. Beddingfield.