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

[Kai Vehmanen]

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:

> --------------
> The good news:
[...]
> I just managed to record a piece with three guitar tracks using three
> separate instances of ecasound, each instance handling one guitar take. I

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 

> -------------
> The bad news:
[...]
> Synchronization is a big problem. Let's say you have the following setup:

... and still is.

> 	alsa_pcm	-> ardour
> 	soundtracker	-> alsa_pcm
[...]
> Jackd is run with -p 1024 -n 2, ST is the sync master, hw-monitoring is
> used for the alsa_pcm input. The big problem is that there's no easy way
> for ardour to learn how much non-valid data will come out of alsa_pcm in
> the start. In this distributed recording case ardour should ignore the
> first 2*1024 samples (maximum of ST output and alsa capture latency).

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-joq.tar.gz   
   http://ecasound.seul.org/download/ecasound-2.2.4-snapshot20030826.tar.gz

-- 
 http://www.eca.cx
 Audio software for Linux!