Subject: Re: [ecasound] Two chains is one too many (do I need bigger iron?)
From: justin (justinrosander_AT_access-4-free.com)
Date: Tue Jul 08 2003 - 09:07:27 EEST
Hello,
In regards to the following:
> ecasound -c -r -X -b:4096 -f:s16_le,1,44100,n \
> -a:monitor -i:backing.wav -o:/dev/dsp \
> -a:record -i:/dev/dsp -o:lead.wav
I would recommend the following for a chainsetup proper (keep in mind you WANT
to keep the "-b:<arg>" option argument as LOW as your system will tolerate):
ecasound -c -r -b:1024 \
-a:1 -f:s16_le,1ch,44100,n -i:backing.wav \
-a:2,3 -f:s16_le,1ch,44100,n -i:alsa,<name of your soundcard, see docs> \
-a:1,2 -f:s16_le,1ch,44100,n -o:alsa,<name of your soundcard> \
-a:3 -f:s16_le,1ch,44100,n -o:lead.wav
This is verbose, but well-formed, and ecasound shouldn't make funny faces at
you. In my project, for the audio format "-f" option I include the following
arguments: -f:s16_l3,2ch,48000,i
I place this in front of each audio object, not before the actual chainsetup
like you did above. Ecasound doesn't like that too much, and it will screw
up your project if you try. Don't mix samplerates. Use the same one, and
don't change it.
Also, you will notice I included the output audio objects in the same line.
Keep them separate; type your inputs in first, then your outputs. In a
multitrack situation, I personally put the monitored tracks first, then the
track I am recording last for all the inputs. For the outputs, I'll place
the monitored tracks first, then the recorded track last. You will notice
that I used two "tracks" for the soundcard input: "-a:2,3". Now, I'm using
"track 2" to monitor what I'm recording, and I'm using "track 3" to record
the "lead.wav" sound file. This is a very good practice, as it will allow
you to monitor what is being played.
Now that I've taken a look at your command-line syntax, let me comment on the
following:
> Top doesn't show much CPU usage, two processes and 5% for one chain.
> Running two chains momentarily registers 30% CPU usage, which
> drops to about 1% due to some xrun-related effects.
>
> Xruns overwhelm even when one chain is simply routed from null to null,
> and with sampling frequence reduced to 22050Hz. This leads me
> to think that disk I/O is not a problem. (The IDE disks
> were tweaked with hdparm.)
>
> I'll consider shelling out more $$$ for a faster processor, but
> wonder if maybe I am missing some other bottleneck in my current
> setup.
I'm not confident that it is a processor issue; save your $$$ because I've
run ecasound nicely on a 100 mHz Pentium processor. I would be interested in
knowing some of the specs of your system, since it is under discussion. I
know you may be a Linux enthusiast, perhaps more so than I may be, but in the
O'Reilly book "Optimizing Windows 9x for Multimedia", the author points out
that your BIGGEST bottleneck is your hard drive. It doesn't matter how FAST
your CPU is, your GPU, memory, whatever. There's more to your system than
your CPU.
Your hard drive can only spin so fast, no matter how much you tweak it. My
10k RPM Fibre Channel drive will not spin 15k--period. I'll tell you, in
running 2 reads and one write on my 5200 RPM Western Digital IDE drive, I was
getting xruns like crazy--and I have a 600 mHz Pentium CPU!!
Read up a little bit on disk performance specs between IDE/ATA/SCSI/Fibre
Channel, etc. If you're going to crank out the $$$, put it where it counts
for hard-disk multitrack recording: the HARD DISK!!! You'll be a LOT
happier than investing a few hundred on the latest Megacium VIII CPU,
although it would be nice to do that, don't get me wrong!! :) take a look at
some of my comments on my website in regards to the performance I'm getting
right now: http://myrddin910.tripod.com/music.htm
Hope this helps, and I would be glad to hear the results of your endeavors,
Rocking on,
Justin
-- "I drank what?" --Socrates
This archive was generated by hypermail 2b28 : Tue Jul 08 2003 - 08:57:41 EEST