headers
Luis Pablo Gasparotto | 6 Jul 2003 14:05
Picon
Favicon

Tkeca 2.0.0 Released!

Changes:

- Real time position clock (it's only for reference, it's not a 
precision tool). When stop playing/recording the clock values are 
replaced by the output of Ecasound's "dump-position", this is the real 
position.
- Automatic file name extension

Take a look at: http://tkeca.sourceforge.net

Regards,

Luis Pablo Gasparotto

--
To unsubscribe send message 'unsubscribe' in the body of the
message to <ecasound-list-request <at> wakkanet.fi>.
Permalink | Reply | 0 comments |
headers
Joel Roth | 7 Jul 2003 22:36

Two chains is one too many (do I need bigger iron?)

I'm surprised at the xruns I get with multiple chains.

Ecasound running on my 400MHz Celeron PC can 
take an input from the soundcard, process
it with reverb, and deliver it to the soundcard
output without overruns.

	ecasound -r -X -i:/dev/dsp -rfb:40,0,55 -o:/dev/dsp

However setting up two chains, one for recording
and one for a monitoring, causes massively unnacceptable xruns.

        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       

This is a recent (2.2.3) version of ecasound, alsa 0.9.4,
2.4.21-rc7 kernel with low-latency patches.

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
justin | 8 Jul 2003 08:07

Re: Two chains is one too many (do I need bigger iron?)

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
justin | 8 Jul 2003 08:09

Re: Two chains is one too many (do I need bigger iron?)

Bigger iron?  perhaps REDIRECTED iron..........
take care

--
To unsubscribe send message 'unsubscribe' in the body of the
message to <ecasound-list-request <at> wakkanet.fi>.
Permalink | Reply | 0 comments |
headers
Joel Roth | 9 Jul 2003 21:50

Re: Two chains is one too many (do I need bigger iron?)

Okay, my problems have receded slightly.

I plugged in an ENVY24/ICE1712 based soundboard (ST Audio DSP24 with DSP3000
ADC/DAC) to replace the on-board ISA (es1869) I used for my original post.

Justin correctly identified some mistakes in my arguments:

    ecasound      -i:test.wav -o:alsahw,1,0,0    #  works
    ecasound -a:1 -i:test.wav -a:1 -o:alsahw,1,0,0 # works! 

but:

    ecasound -a:1 -i:test.wav -o:alsahw,1,0,0    #  no! -o applies to -a:default
                                                 #  instead of -a:1 

Having sorted out the syntax problem, I succeeded in running 
two chains:

    ecasound -c -r -a:1 -i:backing.wav -a:1 -o:alsahw,1,0,0 \
                   -a:2 -i:/dev/dsp1 -a:2 -o:lead.wav

backing.wav goes to DAC channels 1 & 2, and the signals on
ADC inputs 1 & 2 are stored as lead.wav.

The order of the inputs/outputs doesn't seem to change the
'fs' report in interactive mode.

And yes, including the sample format on each argument makes sense.

Bottlenecks
(Continue reading)

Permalink | Reply | 0 comments |
headers
justin | 10 Jul 2003 22:14

Re: Two chains is one too many (do I need bigger iron?)

BTW, Joel,
I have heard that a motherboard with both PCI and ISA support don't run as 
fast as straight PCI.  Mine has support for both, and I haven't tried a 
different board because I don't have that kind of money laying around.  
Therefore, I can't really verify that.  
blessings,
justin
--

-- 
"I drank what?"
  --Socrates

--
To unsubscribe send message 'unsubscribe' in the body of the
message to <ecasound-list-request <at> wakkanet.fi>.
Permalink | Reply | 0 comments |
headers
Joel Roth | 10 Jul 2003 21:49

Re: Two chains is one too many (do I need bigger iron?)

lspci [-v | -vv | -vvv ] under gives information about the PCI bus.

My listing shows a ISA bridge, implying that the PCI bus is intermediary
in all data I/O inolving ISA devices.  

Good luck

joel

On Thu, Jul 10, 2003 at 03:14:05PM -0500, justin wrote:
> BTW, Joel,
> I have heard that a motherboard with both PCI and ISA support don't run as 
> fast as straight PCI.  Mine has support for both, and I haven't tried a 
> different board because I don't have that kind of money laying around.  
> Therefore, I can't really verify that.  
> blessings,
> justin
> -- 
> "I drank what?"
>   --Socrates
> 
> --
> To unsubscribe send message 'unsubscribe' in the body of the
> message to <ecasound-list-request <at> wakkanet.fi>.

--

-- 
Joel Roth

--
To unsubscribe send message 'unsubscribe' in the body of the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Roel de Wit | 10 Jul 2003 22:59

Re: Two chains is one too many (do I need bigger iron?)

Hi,

From what I remember systems with both PCI and ISA busses run about 5%
slower than systems with only a PCI bus.. However if your computer has
serial ports, floppy connectors etc. then you system has an ISA bus even if
there are no ISA slots.

Grtzzzzzz Roel..

----- Original Message ----- 
From: "justin" <justinrosander <at> access-4-free.com>
To: <ecasound-list <at> wakkanet.fi>
Sent: Thursday, July 10, 2003 10:14 PM
Subject: Re: [ecasound] Two chains is one too many (do I need bigger iron?)

> BTW, Joel,
> I have heard that a motherboard with both PCI and ISA support don't run as
> fast as straight PCI.  Mine has support for both, and I haven't tried a
> different board because I don't have that kind of money laying around.
> Therefore, I can't really verify that.
> blessings,
> justin
> -- 
> "I drank what?"
>   --Socrates
>
> --
> To unsubscribe send message 'unsubscribe' in the body of the
> message to <ecasound-list-request <at> wakkanet.fi>.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kai Vehmanen | 10 Jul 2003 23:18

Re: Two chains is one too many (do I need bigger iron?)

On Wed, 9 Jul 2003, Joel Roth wrote:

>     ecasound -a:1 -i:test.wav -o:alsahw,1,0,0    #  no! -o applies to -a:default
>                                                  #  instead of -a:1 

Hmm, this should definitely not be the case. All objects 
after "-a:1" should be added to the chain "1" unless another
"-a" option is given. Here's an example:

--cut--
|$ echo fs |ecasound -a:1 -i foo.wav -o alsahw,1,0 -c
****************************************************************************
*               ecasound v2.2.4 (C) 1997-2003 Kai Vehmanen                 
****************************************************************************
- [ Session created ] 
------------------------------------------------------
- [ Chainsetup created (cmdline) ] 
-----------------------------------------
ecasound ('h' for help)> fs
### Audio input/output status (chainsetup 'command-line-setup') ###
Input (1): "foo.wav," - [DB => RIFF wave file]
 -> connected to chains "1": position (0.000/0.000) seconds.
 -> closed, audio format not available until object is opened.
Output (1): "alsahw,1,0,0" - [ALSA PCM device]
 -> connected to chains "1": realtime-device; position 0, delay 0.
 -> closed, s16_le/2ch/44100Hz, buffer 1024.
ecasound ('h' for help)> ---
ecasound: Exiting...
--cut--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kai Vehmanen | 10 Jul 2003 23:28

Re: Two chains is one too many (do I need bigger iron?)

On Mon, 7 Jul 2003, Joel Roth wrote:

> Ecasound running on my 400MHz Celeron PC can 
[...]
> However setting up two chains, one for recording
> and one for a monitoring, causes massively unnacceptable xruns.

This is probably caused by something else than lack of sufficient
cpu/disk/memory resources. I've been using ecasound for multitrack
recording on my old Pentium-166Mhz and succesfully recorded lots of music.

>         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       

Try first replacing "-b:4096" with "-b:1024 -z:intbuf" and then with
"-b:1024 -z:nointbuf".

> This is a recent (2.2.3) version of ecasound, alsa 0.9.4,
> 2.4.21-rc7 kernel with low-latency patches.

If you are using ALSA, I recommend using the ALSA devices directly, i.e.
replace "/dev/dsp" with "alsa,default".

--

-- 
 http://www.eca.cx
 Audio software for Linux!

--
To unsubscribe send message 'unsubscribe' in the body of the
(Continue reading)

Permalink | Reply | 0 comments |

Gmane