Subject: Re: [linux-audio-dev] App intercomunication issues, some views.
From: Kai Vehmanen (kai.vehmanen_AT_wakkanet.fi)
Date: Thu Jul 25 2002 - 01:17:52 EEST
On Wed, 24 Jul 2002, Andy Wingo wrote:
[JACK transport control]
> I've been meaning for some time to make a universal transport control, a
> separate app whose sole purpose would be transport control.
> This would be rad (TM) for a number of reasons:
>
> 1) Get your whole rig to start at once, even if you're not using
> ecasound or ardour
Yup, I agree, a generic (and simple) transport master client would be a
very valuable addition. Even though "works out-of-the-box" is a very high
priority item in ecasound development, I must admit that achieving this
goal is anything but easy with applications of this size. If nothing else,
broken soundcard hardware, kernel drivers (and sometime the kernel itself)
and libraries make it practically impossible to prepare for all
situations. And the last thing people developing new client apps need is
to worry about bugs and misc problems of other large client apps.
In other words there should be enough jack_simple_client style apps to
cover all JACK functionality. Getting these apps to work should require no
more effort than that required by jackd. This is critical for getting more
developers writing JACK clients. Requiring installation and use of
ardour/ecasound/someotherbigapp is not good.
> 3) funny tricks with beats -- speed up, slow down the tempo. Loop the
> last 4 beats. All the GDAM tricks, but on a system-wide level.*
[...]
> * You'll run into some buffering issues here when streaming from disk.
> Oh well.
Actually the JACK transport API is quite flexible in this way. Ecasound
doesn't yet (if ever, ecasound prefers per-audio-object looping to
session-level looping) support the loop transport mode, but it does
support "live seeks" (ie. random-access style changes in transport
position during successive callbacks). If the disk-i/o subsystem can't
keep up with the changes, the rt-part (callbacks) will ignore it until
it has caught up.
Of course for sample-accurate looping, the looping transport mode is still
the only real solution. It's also true that transport-change patterns
involving regulars jumps (like skipping x samples during each callback)
will cause trouble to clients with slow non-rt i/o subsystems.
But anyways, the most important feature IMHO is the basic transport
control (ie. start, stop and non- or near-rt fw, rw and setpos). Most
importantly this solves the old LAAGA use-case with
drum-machine+soft-synth+multitracker (<http://eca.cx/laaga>).
-- http://www.eca.cx Audio software for Linux!
This archive was generated by hypermail 2b28 : Thu Jul 25 2002 - 01:40:55 EEST