Compiling Ecasound with gcc 4.3

Before the next release, would it be possible to add the necessary #include
headers to compile Ecasound with gcc 4.3?

I just tried building on a Fedora 9 system and it failed for that reason.

For those of us who are running Debian, these changes have already been
included in the package; they just need to propagate upstream before the next
release.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ecasound-list mailing list
Ecasound-list <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecasound-list

a lot of trouble these days

Greetings!
   I'm sorry this is just a list of what I experienced with my last ecasound 
version (git from 20.05.2008).
   1. Still jack_auto doesn't care about the client parameter handed. It just 
connects to the first two ports of my soundcard regardless.
   2. Effect troubles. Consider the following commandlne:
ecasound -c -a:1 -i t1.wav -ea:60 -a:2 -i 2.ewf -ea:70 -a:3 -i 3.ewf -ea:40 
-a:4 -i 4.ewf -ea:64 ... -a:8 -i 8.ewf -ea:57 -z:mixmocd,sum -a:all -o out.wav
   I can say for sure, that with more then six chains, it ignore the ea-option 
on one of them. with eight chains it ignore chain 7s ea with less some other 
ea-options. At least I didn't get any sound from that chain. I checkd spelling 
multiple times. When I removed the -ea from teh chain in question, I got it 
good and loud. In that case it was alright, but definitely not helpful.
   the ewf-files just contained stuff like:
source = t2.wav
offset = 180
--------------
source = t3.wav
offset = 311
--------------
   And so on.
   3. Not sure if this is a problem: I handed ecasound a few 24bit wav-files, 
but the output was 16bit. I passed -f:24,2,48000 to all chains and still it 
wouldn't work. I deleted the ouput-file I was trying to create and used the 
same commandline and voila. Is this behaviour intended?
   If you need log-files Kai, I could provide them for a few cases.
   Kindest regards
         Julien

--------

starting with pyeca : exception error

Hi,

I made some tests to work with ecasound, it work perfectly well with jack.
I need to make a script in python to automate the reading of multiple audio files.

So i try at first in the python interactive mode : seems to work when i call pyeca : 

>>> import pyeca
>>> e = pyeca.ECA_CONTROL_INTERFACE()
********************************************************************************
*        ecasound v2.4.6.1 (C) 1997-2007 Kai Vehmanen and others    
********************************************************************************

Native python ECI (ecasound control interface) implementation

   Can be used to replace the C implementation 'pyecasound.so'.

by Kai Vehmanen, Eric S. Tiedemann and Janne Halttunen.

(to get rid of this message, pass zero to instance init)

But when i make my first script like that :

#!/usr/bin/env python
import pyeca
e = pyeca.ECA_CONTROL_INTERFACE()

and run it, it put this message :

laptop <at> alex:~/Bureau$ python testPyeca.py 

Alsa input sample rate puzzle

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

_______________________________________________
Ecasound-list mailing list
Ecasound-list <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecasound-list

Re: Alsa input sample rate puzzle

Hello!
   As to the S24_LE and the arecord way of things, they just developed 
seperately and didn't obviously communicate. Weel there's nothing saying, that 
the bit-depth option has to be in a certain format. Alas.
   As to your samplerate problem. This is really curious. I started out 
recording 44100, but for a long time I've been doing 48000kHz. I work with 
JACK though. Question: Does you soundcard have a samplerate setting. Mine has, 
it called clock or something. This can be set to different values.
   And there is your /usr/local/share/ecasound/ecasoundrc (if you installed 
manually or /usr/share/ecasound/ecasoundrc if you took a package). There is a 
setting for standard format. I set it to: s16_le,2,48000,i
maybe this also helps.
   Beyond that, I'm out of it...
   Kindeest regards
         Julien

--------
Music was my first love and it will be my last (John Miles)

======== FIND MY WEB-PROJECT AT: ========
http://ltsb.sourceforge.net
the Linux TextBased Studio guide
======= AND MY PERSONAL PAGES AT: =======
http://www.juliencoder.de

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Ecasound-list mailing list
Ecasound-list <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecasound-list

Re: Alsa input sample rate puzzle

Hi,

On Tue, 17 Jun 2008, Andrew Lees wrote:

> trying ecasound.  I have a slight puzzle though.  I am using an Audigy
> NX external USB card, and other recording software (arecord, audacity,
> for example) seem to think that the card supports an input side sample
> rate of 48000 s/s, but not 44100, while ecasound thinks it supports a
> 44100 rate but not 48000.  Both camps are set in their ways, and will
[...]
> ecasound -f:s24_le,2,44100 -i:alsahw,1,0 -t:1800 -ge:5,0.02 -B:nonrt -o
> side2-2.wav (currently lockup are making me wary about rt modes)
>
> whereas ecasound -f:s24_le,2,48000 -i:alsahw,1,0 ... will not work.

that would suggest the card natively supports only 44100. Arecord should 
behave similarly if you pass it:

arecord -D hw:1,0 ...

If you use the ALSA plugin layer (arecord without extra options, or 
ecasound with "-i:plughw:1,0"), alsa-lib will resample the audio for you. 
But usually (and especially when recording) it's better to record in the 
native sample rate supported by HW (so 44100 in this case).

> Also arecord requires a -f S24_3LE option rather than a -f S24_LE option
> (which it says is not supported), while ecasound will not work with a
> -f:s24_3le, option - all very curious.

Yes, ecasound does not recognize '-f:s24_3le'. This is quite complicated 
in fact... if you use the ALSA plug layer (-i:plughw:1,0 or arecord -D 
plughw:1,0), alsa-lib will make the conversion for you, but otherwise you 
need to understand what is going on. Basicly ALSA's S24_3LE is same as 
ecasound's '-f:s24_le'. ALSA's S24_LE is in fact a 32bit sample, with 
least-significant byte zeroed (so 24bit of information, stored in 32bits).
The latter one is much more common. In ecasound, you can use '-f:s32_le' 
for both ALSA types S24_LE and S32_LE (because ecasound doesn't care 
whether the lower bits are zeroed out or have valid info).

--

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Ecasound-list mailing list
Ecasound-list <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecasound-list

Re: Alsa input sample rate puzzle

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

_______________________________________________
Ecasound-list mailing list
Ecasound-list <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecasound-list

Re: Alsa input sample rate puzzle

Hi,

On Fri, 20 Jun 2008, Andrew Lees wrote:

> Which is exactly what I did to get the 48000 rate, with 44100 not being
> supported by arecord.  So for example, this is a session:
>
> ~/Audio $ arecord -D hw:1,0 -f cd xxx.wav
> Recording WAVE 'xxx.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
> Warning: rate is not accurate (requested = 44100Hz, got = 48000Hz)
>         please, try the plug plugin
> ~/Audio $ arecord -D hw:1,0 -f dat xxx.wav
> Recording WAVE 'xxx.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo

aa, ok. So my guess was definitely wrong...

> Happy at 48000, unhappy at 44100.  The same for other formats, and the
> converse of the situation with ecasound.  Is there some setup that

Hmm, it is really weird you get different behaviour with arecord and 
ecasound. Could you send me a private mail with a log of running ecasound 
with full debugging (-ddd)?

> configurs the card to do one rate vs another?  I can sample at integer
> multiples  and ratios of 44100 with ecasound, and similarly wrt 48000
> with arecord, so some basic parameter of the card must be being set up
> differently in the two cases, perhaps?

Some cards in fact do have rather bizarre limitations (channel count 
and/or sample width impact the possible values for other settings), but 
this is not very common. Plus in your tests, you've requested the very 
same params with both arecord and ecasound, so there shouldn't be any 
difference.

--

-- 

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Ecasound-list mailing list
Ecasound-list <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecasound-list

Re: Compiling Ecasound with gcc 4.3

Hi,

On Tue, 3 Jun 2008, Jason White wrote:

> Before the next release, would it be possible to add the necessary #include
> headers to compile Ecasound with gcc 4.3?

yes, a very good idea. I just tested the codebase (the git tree at [1]) with
gcc 4.3.1 and after a few more fixes (mostly related to warnings), the 
build now goes through fine.

[1] http://ecasound.seul.org/ecasound.git

> I just tried building on a Fedora 9 system and it failed for that reason.

Assuming Fedora 9 doesn't contain any funny gcc patches, it should now be 
fine.

> For those of us who are running Debian, these changes have already been
> included in the package; they just need to propagate upstream before the next
> release.

Yes, I've been getting a steady stream of patches from Debian and those 
are now all merged.

--

-- 

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Ecasound-list mailing list
Ecasound-list <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecasound-list

Re: a lot of trouble these days

Hi,

On Wed, 4 Jun 2008, Julien Claassen wrote:

>   I'm sorry this is just a list of what I experienced with my last ecasound
> version (git from 20.05.2008).
>   1. Still jack_auto doesn't care about the client parameter handed. It just
> connects to the first two ports of my soundcard regardless.

yes, this indeed was a bug (introduced by yours truly in March this year, 
so not in 2.4.6.1). Thanks a lot Julien for finding this out!

>   2. Effect troubles. Consider the following commandlne:
> ecasound -c -a:1 -i t1.wav -ea:60 -a:2 -i 2.ewf -ea:70 -a:3 -i 3.ewf -ea:40
> -a:4 -i 4.ewf -ea:64 ... -a:8 -i 8.ewf -ea:57 -z:mixmocd,sum -a:all -o out.wav
[...]
>   I can say for sure, that with more then six chains, it ignore the ea-option
> on one of them. with eight chains it ignore chain 7s ea with less some other

This one is still open -- seems very odd to me, but stranger things have 
happened. ;)

>   3. Not sure if this is a problem: I handed ecasound a few 24bit wav-files,
> but the output was 16bit. I passed -f:24,2,48000 to all chains and still it
> wouldn't work. I deleted the ouput-file I was trying to create and used the
> same commandline and voila. Is this behaviour intended?

Yes, this is intended. Passing '-f' doesn't have any impact when reading, 
and updating an existing, .wav file. Ecasound always uses the params in 
the file header. If you really want to override the header info, you can 
for instance interpret the file as raw PCM ("-f:24,2,48000 -i 
typeselect,.raw,foo.wav"). For output files, you can also pass '-x' so 
that ecasound will truncate (vs updating) the outputs.

--

-- 

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Ecasound-list mailing list
Ecasound-list <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecasound-list