Re: [ecasound] Submixing in chains

New Message Reply Date view Thread view Subject view Author view Other groups

Subject: Re: [ecasound] Submixing in chains
From: Kai Vehmanen (k@eca.cx)
Date: Fri Dec 01 2000 - 03:12:16 EET


On Wed, 29 Nov 2000, Robert Jonsson wrote:

> In essence I tried to load three mp3 files from disk and process them in
> different chains. But before sending them to the same output buffer I
> tried to submix two of them to add common effects. This however didn't
> work out. The submixer behaved erratic, eca didn't complain, but it was
[...]
> ecasound -a:1 -i:1.mp3 -a:2 -i:2.mp3 -a:3 -i:3.mp3 -a:1 <fxstuff> -a:2
> <fxstuff> -a:3 <fxstuff> -a:1,2 <commonfxstuff> -a:1,2,3 -o /dev/dsp

Ok, this shouldn't work. I guess I should add more verbose warnings when
parsing the above. Root of the problem is adding an effect to multiple
chains at once; this is not allowed and will result in undefined
behaviour (at some point, this _was_ allowed, and thus ecasound
currently lets the error go through).

> I would consider submixing in the middle of the chains to be a rather
> complex operation, programmatically, would be nice if ecasound supported
> it though :-). Opens doors in my mind!! wide open!!

This is an interesting question. Ecasound in fact doesn't do submixing.
I call this design one-stage mixing (processing happens during one
stage). You could compare this to traditional mixers where the mixing
is clearly two-stage (inputs -> mixer stripes, stripes -> buses,
buses -> outputs). In addition, many software synths and other "modular"
gadgets/apps provide n-stage mixing, where you endlessly combine and
submix signals.

Now a few reasons why ecasound has one-stage mixing:

[command-line interface]
First of all, coming up with a command-line interface for n-stage mixing
would be really difficult. If we take your example above, the chain "1" is
selected four times. The first time, it is followed by an input, on the
second and third you add effects, and the last time it's used for adding
/dev/dsp output. Now this clearly isn't enough info for 2-stage mixing.
And even more critical, the last you select "1", it is selected together
with "2" and "3". From this ecasound knows that /dev/dsp is to be attached
to all three chains. Routing data from inputs to multiple chains uses the
same logic. Adding another mix-matrice to this would mean we'd have to
make the command-line interface quite a bit more complex.

[software vs hardware]
Ok, the second reason is that you very rarely need two-stage mixing in the
"digital domain". With a traditional hardware mixer, it's very convenient
that you can route all your drum tracks to a single bus, and then run
that bus through a reverb unit. If this wasn't possibly, you'd need
multiple reverb units, and you'd need to take care of using identical
settings in all of them. But when you think about this, adding another
reverb unit in ecasound (or any other software) is really nothing. Just
add another -etr and there you are!

Another example is bouncing. I don't know about you, but at least I've had
my fair share of doing bounce-mixes on analog recording gear. :) With
analog gear, it's a slow and painful way of getting a few extra tracks,
and you always lose in quality. But no so with ecasound. For example, if
you have a chainsetup/script which mixes all your tracks (with effects) to
the soundcard. Now all you need to do to make a submix is to replace the
"-o:/dev/dsp" with "-o:submix-1.wav" and that's it. It's fast, you won't
lose in quality, and you don't need to do much typing. So if you really
need to mix track together before applying a common effect (instead of
applying multiple identical effects), you first do a submix, then apply
the effect, and start using the submix-file in your recording/mixing work.

[performance]
Ok, so there are some good sides in one-stage mixing, but still, why
make such limitations? This actually is optimizing the common case.
Thanks to this one-stage limitation, ecasound's engine code is in fact,
_really_ simple. There's nothing special happening there - read inputs,
write to chain buffers, process chainops, write to outputs buffers, output
and back to start. This "core" of ecasound is just about a screenful of
code!

[the big lie]
Ok, so I admit it, I've been lying all the time. ;) Although one-stage
mixing is chosen to be the common-case for optimization (and interface
design), ecasound does allow even n-stage mixing, but this doesn't come
for free. There are basicly two ways to get around the one-stage mixing
limit:

1. effect presets

Ecasound effect presets are in fact small ecasound engines pretending
to be effects. Here's an example of multi-chain effect preset:

-- file 'bassbooster.ecp' --
# let's put the low freqs into one chain and high freqs in another
bassbooster = -efl:2000 -ea:200 | -efh:2000 -ea:50
# note, the '|' sign separates parallel chains
-- cut --

ecasound -a:1 -i:some.mp3 -pf:bassbooster.ecp \
         -a:2 -i:another.mp3 -pf:bassbooster.ecp \
         -a:1,2 -o:/dev/dsp

Here ecasound in fact does 2-stage mixing. Btw; I can't test this
at the moment, so report if the above doesn't work... (if it doesn't,
it's a bug!).

2. loop devices

Loop devices were added to ecasound version 1.7.0. You use them like this:

# note, the second loop parameter is the loop id-number;
# it is used to associate loop inputs with correct loop outputs
ecasound -a:1 -i:some.mp3 -o:loop,1 \
         -a:2 -i:another.mp3 -o:loop,1 \
         -a:3 -i:loop,1 -o /dev/dsp -ea:200

Both inputs are eventually routed to chain "3", where a -ea:200 is
applied to the signal. This does have one downside, loop device
adds latency (-b:x -> latency of x frames).

..

Huh, hope this reply answered your question. :)

-- 
 . http://www.eca.cx ... [ audio software for linux ] /\ . 
 . http://www.eca.cx/aivastus ... [ aivastus net radio ] /\ . 

-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request@wakkanet.fi>.


New Message Reply Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Fri Dec 01 2000 - 05:09:03 EET