[linux-audio-dev] distributed multitracking with JACK (fwd)

For those who are interested in JACK's transport functionality, the following message provides a step-by-step example of distributed (as in multiple independent apps participating in the same session) multitrack recording, plus some discussion about current limits and usability issues. Links to the latest snapshot tarballs are available at the very end of this message. For info about JACK transport, see: http://www.joq.us/jack/refman/transport-design.html http://eca.cx/lad/2003/08/0109.html The Feb'03 mail I refer below can be found at: http://boudicca.tux.org/hypermail/jackit-devel/2003-Feb/0052.html It's good to note that I could have used any transport-aware application in place of the Ecasound instance 'ecafoo' to provide audio tracks to record against [*]. The application could have been (assuming proper support is added to them at some point) Alsaplayer, Ardour, SoundTracker, CheeseTracker, Hydrogen, Gmorgan, etc, etc... you get the picture. Similarly the recording client 'ecabar' (an Ecasound instance in our example session) could be replaced by Ardour, Rosegarden, Muse, Audacity or any other multitrack capable audio recorder. Sounds good, doesn't it? :) So let's continue with the example: [*] As we are still developing the transport system and there are only few apps that follow bleeding edge development, I had to settle on using Ecasound. :) ---------- Forwarded message ---------- Subject: Re: [Jackit-devel] distributed multitracking It's more than six months now since I last tried this, time for another look at this use case: On Wed, 5 Feb 2003, Kai Vehmanen wrote: [...] I did the same again with the new transport interface. Environment: linux-2.4.19-lowlatency-capabilities-tracepatches Midiman Delta44 as the soundcard latest 0.9.6 ALSA drivers latest JACK and Ecasound from CVS (2003-Aug-25) I set jackd to use the _maximum_ latency settings for Delta44 (-n 3 -p 1024) to create the worst possible environment for syncing clients. The test went through unbelievably smoothly. Not a single crash in any app during the whole testing. Unlike in the test in February, this time I didn't have to restart all the clients after each and every take and/or mixdown run. Also, I was now able to seek from any of the Ecasound sessions or from jack_transport and all the other clients would correctly follow the changes. Yay! Nice work Jack (J.O'Quin) and JACK! :D [...] ... and still is. [...] There doesn't seem to be any easy way around this problem. Somehow we need to provide meta-information concerning how these independent connections between JACK ports are related (from user POV) to each other. To solve this for my test case, I added a new option to Ecasound for specifying explicit multitrack recording offset. The syntax is "-z:multitrack,XXX", where 'XXX=n*p', 'n' jackd/alsa_pcm period count and 'p' jackd/alsa_pcm period size in samples. With this meta-info, the multitrack sync works comparably with a session without JACK. And finally, a test script for a minimal distributed multitracking session: --cut-- # 1. launch jackd and jack_showtime (_very_ useful if something goes wrong) # 2. test input levels (play something and verify that the meters # are moving); ctrl-c to exit ecasignalview jack_alsa # 3. create the monitor track to play against (15 secs) sh1> ecasound -i null -o monitor.wav -x -pn:metronome,120 -t:15 # 4. launch the slave client sh1> ecasound -i monitor.wav -o jack -G:jack,ecafoo,sendrecv -c ecasound1> engine-launch # 5. launch the master client (replace 3072 with value corresponding # to the -n/-p params you run jackd/alsa_pcm with) sh2> ecasound -a:rec -i jack_alsa -o recorded.wav -a:mon -i jack -o jack_alsa -G:jack,ecabar,sendrecv -z:multitrack,3072 -c ecasound2> engine-launch # 6. connect the slave client to the master client sh3> jack_connect ecafoo:out_1 ecabar:in_3 sh3> jack_connect ecafoo:out_2 ecabar:in_4 # 6. launch jack_transport and control the two multitrack-recorder # instances sh3> jack_transport jack_transport> locate 0 jack_transport> play # 7. record something against 'monitor.wav' (check jack_showtime output # if you have problems) # 8. listen to the result (note! we can let the slave client to run # all the time) jack_transport> stop ecasound2> stop ecasound2> quit sh2> ecasound -a:rec -i recorded.wav -a:mon -i jack -a:rec,mon -o jack_alsa -G:jack,ecabar,sendrecv -c ecasound2> engine-launch sh4> jack_connect ecafoo:out_1 ecabar:in_1 sh4> jack_connect ecafoo:out_2 ecabar:in_2 jack_transport> locate 0 jack_transport> play --cut-- ... and that's it, the sync should be correct. If you want to try this, remember to update to latest JACK and ecasound CVS, or use the following snapshots (note that these are __NOT__ official releases, so the APIs can still change before the next actual stable release): http://ecasound.seul.org/download/other/jack-audio-connection-kit-0.79.2-jo… http://ecasound.seul.org/download/ecasound-2.2.4-snapshot20030826.tar.gz -- http://www.eca.cx Audio software for Linux!