Re: [ecasound] tracking with ecasound 1.6.12

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

Subject: Re: [ecasound] tracking with ecasound 1.6.12
From: Jeremy Hall (jhall@UU.NET )
Date: Thu Feb 24 2000 - 10:45:06 EET


Hi,

In the new year, Neil E. Klepeis wrote:
> Greetings,
>
> I have a few ecasound-related questions/problems:
>
well this is the place. :)

> 1. Is it possible from within ecasound to direct the left channel from
> a sound card device to one file, and the right channel to another
> file? Thereby resulting in two mono sound files. I suppose this is
> driver dependent... Currently it seems like the -f option can only
> specify mono or stereo (-f:16,1,44100 or -f:16,2,44100). Can we choose
> which channel is used for mono? (eg. a future planned feature)
>
hmm

Try thinking of it as splitting the sides like this.

ecasound -a:lefties,righties,both -i /tmp/in.raw -a:lefties -epp:0
-f:s16_le,1,44100 -o /tmp/lefties.wav -a:righties -epp:100
-f:s16_le,1,44100 -o /tmp/righties.wav -a:both -o /dev/dsp

See if that helps.

> 2. I am having a lot of trouble getting clean tracks when multitracking
> (e.g., playing 2 or three sound files, and recording another from a
> sound card). There appear a lot of clicks and pops during the tracks
> even though the first 20-30 seconds may sound perfect. Sometimes I
> don't hear any problems during the actually tracking (recording) and the
> problem only comes up when I play all the tracks back. I am setting a
> buffer of 64 (-b:64) during recording and 1024 during playback. There
> don't appear to be any timing problems. My question is: does this
> sound like a buffer issue or is there some other problem (e.g., not
> enough CPU power available)? My machine is a PII/350MHz/128MB with RH
> Linux 6.1. Does encoding mp3's on the fly with lame (or decodeing with
> mpg123) use up more of the CPU than just using wav files?
>
WOW! trying to encode with 64 as a buffer size seems aggressive. Kai and
I have had discussions about larger buffers making the delay noticable,
she suggests the delay is not that noticable. Try -b:128 and see if your
problems go away. If you're using the mic from the soundcard, you'll
likely pick up some cruft from the hardrive. Lame3.63 is improving better
still on encoding faster and for better quality, but yes it does tax quite
heavily the cpu. Adding mpg123 to the mix doesn't seriously hinder a p350
unless you are already hitting the wall.

I have noticed that recording a wav file, then encoding it with lame, then
playing both at the same time with ecasound seems to induce a 75
milisecond delay for the mp3 file, in fact, the decoded version of the wav
file is larger than the original file, I'm not certain I fully understand
that.

> 3. I am very interested in being able to loop one chain (e.g., playback
> 4 sec of a sound file over and over) while other chains keep playing
> straight through. eg, have a two bar drum loop and record guitar or
> vocals over it. I don't think this is now possible with the -t and -tl
> options or loop devices. Are there plans for such a feature?
>
yea, the -t and tl options haven't yielded good results for me either, in
fact they mostly confuse me. There isn't a really intuitive way to rid of
them in the console interactive mode, nor is there a way to fix the k
controllers...or maybe I have missed some option in ecasound-iam

We need a c-help, cs-help, aio-help, etc. command.

>
> Thanks,
>
> Neil
>
>
You're welcome

oh

looping, that might be in ecasound7. Come and test the alpha code. :-)

_J

> P.S. Sorry that this is so many questions at once. Next time I'll do
> one question at a time.
>
nah, keeps it fun this way.

> --
> ___________________________________________________________
> Neil E. Klepeis, School of Public Health, UC Berkeley, USA
> http://socrates.berkeley.edu/~nklepeis
> http://eetd.lbl.gov/ied/era/exposuremodeling/
> nklepeis@uclink4.berkeley.edu
> 510-848-5827
> ------------
>


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

This archive was generated by hypermail 2a24 : Thu Feb 24 2000 - 10:46:05 EET