Subject: distributed multitracking with JACK (fwd)
From: Kai Vehmanen (kai.vehmanen_AT_wakkanet.fi)
Date: Tue Aug 26 2003 - 04:08:11 EEST
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:
The Feb'03 mail I refer below can be found at:
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.
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
# 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
# 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
# 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
# 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
jack_transport> locate 0
# 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)
sh2> ecasound -a:rec -i recorded.wav -a:mon -i jack -a:rec,mon -o jack_alsa -G:jack,ecabar,sendrecv -c
sh4> jack_connect ecafoo:out_1 ecabar:in_1
sh4> jack_connect ecafoo:out_2 ecabar:in_2
jack_transport> locate 0
... 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
-- http://www.eca.cx Audio software for Linux!
This archive was generated by hypermail 2b28 : Tue Aug 26 2003 - 04:05:57 EEST