> I have a short, simple question:
>
> Would anyone around here care for ALSA drivers for
the Echo
> (formerly Event/Echo) line of studio audio
interfaces?
>
>
> (We're talking about the original Darla/Gina/Layla,
as well as the
> new 24 bit interfaces.)
>
> I have an old 20 bit Layla. I have their C++ driver
source, which has
> been released under some BSD/MIT style licence. I
have kernel hacking
> experience. I still have some hard feelings, I
think...
I have an Echo Darla card that I used to use with
CEPro and Win98. I have converted this system over to
Linux - but alas there is not ALSA driver for the
Darla. :-( I would love to see an ALSA driver for it.
__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com
>> you can't declare a variable except at the top of a block. Newer
>> compilers let you, and I think C99 supports it. Don't count on it
>> yet, too many people with old compilers.
>Yes. That'll be it. Dang. I've obviously been doing too much C++
>recently... I'll fix it and put out another release...
For gcc3 at least, CFLAGS=-std=gnu99 makes this work. Personally I like
it, maybe its time to switch to gcc3?
Hi there, I'm just a humble hobbyist coder.
I'm looking for some coders who can spare some time to help me with a
program I've been writing.
It is basically a C++ modular synth /sequencer /sampler which only generates
wav files. Not for people with decent computers (ie not me), but for those
of us with heaps of crap which refuse to do anything except a handfull of
audio channels and fx in cubase in windows, (works better than linux equiv
on same machine - sorry)
But I've decided to write the program in Linux using anjuta because I'd
rather do that than learn visual C & mfc, and I'd rather use Linux.
My program keeps going wrong, now it's decided that it will transpose all
notes up four octaves for now apparent reason.
if anyone can is willing to help I'd much appreciate it.
thanks
james Morris
sirromseventyfive
_________________________________________________________________
MSN Messenger - fast, easy and FREE! http://messenger.msn.co.uk
Hi all,
A couple of days ago Steve Harris posted results from a quick benchmark on
on the jackit-devel mailing list.
On Wed, 12 Feb 2003 23:57:02 +0000
Steve Harris <S.W.Harris(a)ecs.soton.ac.uk> wrote:
> Just to follow up, I rebuilt my test code on gcc3, and it went from C++
> being around 30% slower, to about 1% faster, which is what I expected to
> see in the first place. I guess they fixed the optimizer deficiency.
As a C fan I was rather curious about this. I didn't want people getting the
wrong impression that C++ is automatically faster than C (it isn't) or that in
the long term improvements in the C++ compiler will make it faster than C
(it won't). So I asked Steve for more details and he pointed me at the code:
http://plugin.org.uk/filter/
and suggested that further discussion of this issue should probably be moved
from the jackit-devel list to this one. So here we are. (Steve, please don't
take this as a slight on you, I simply want to get the facts right).
For those interested, my machine is a dual 450Mhz PIII, with SCSI disks,
2.4.20 kernel and running Debian Testing. All compilers and toolchain
programs are from Debian Testing; none have been compiled from source.
Debian is rather nice in that it allows more than one compiler to be
installed on a machine at anyone time. Here are the compilers I used for
my testing:
erikd@coltrane > gcc-2.95 -v
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)
erikd@coltrane > g++-2.95 -v
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)
erikd@coltrane > gcc-3.2 -v
Reading specs from /usr/lib/gcc-lib/i386-linux/3.2.1/specs
Configured with: /mnt/data/gcc-3.1/gcc-3.2-3.2.1ds2/src/configure -v
--enable-languages=c,c++,java,f77,proto,objc,ada --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.2 --enable-shared
--with-system-zlib --enable-nls --without-included-gettext
--enable-java-gc=boehm --enable-objc-gc i386-linux
Thread model: posix
gcc version 3.2.1 20020924 (Debian prerelease)
erikd@coltrane > g++-3.2 -v
Reading specs from /usr/lib/gcc-lib/i386-linux/3.2.1/specs
Configured with: /mnt/data/gcc-3.1/gcc-3.2-3.2.1ds2/src/configure -v
--enable-languages=c,c++,java,f77,proto,objc,ada --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.2 --enable-shared
--with-system-zlib --enable-nls --without-included-gettext
--enable-java-gc=boehm --enable-objc-gc i386-linux
Thread model: posix
gcc version 3.2.1 20020924 (Debian prerelease)
And here are the results running Steve's tests (neglecting the Objective
C tests because my system seems to be missing something):
Compiler Program Cycles
-------- ------- ------
gcc-2.95 ansic.c 85058
g++-2.95 cpp.C 90719
gcc-3.2 ansic.c 196581
g++-3.2 cpp.C 85042
Thats all a little strange. So lets look at the code. In cpp.C, Steve
defines a Lowpass class and its process member functions like this:
class LowPass {
private:
float ym1;
float a;
public:
void setA(float newa);
void reset();
float process(float x);
};
float LowPass::process(float x)
{
float y = ym1 * (1.0f - a) + x * a;
ym1 = y;
return y;
}
while the C version is defined like this:
typedef struct {
float ym1;
float a;
} lowpass;
float lowpass_process(lowpass *this, float x)
{
float y;
y = this->ym1 * (1.0f - this->a) + x * this->a;
this->ym1 = y;
return y;
}
So what is going on here? Well my guess is that both versions of g++ and the
older version of gcc are applying an optimisation that the new gcc isn't and
my guess is that the missing optimisation is function in-lining. So why was
in-lining present in gcc-2.95 and absent in gcc-3.2? Thats probably because
gcc-3.2 is working towards compliance with the C1999 ISO Standard. In C99,
inline is a new C keyword.
If I now change the lowpass_process function as follows:
inline float lowpass_process(lowpass *this, float x)
{
float y;
y = this->ym1 * (1.0f - this->a) + x * this->a;
this->ym1 = y;
return y;
}
and add -std=c99 to the gcc-3.2 command line, the new results are:
Compiler Program Cycles
-------- ------- ------
gcc-3.2 ansic.c 86299
g++-3.2 cpp.C 85042
So, g++-3.2 is still beating gcc-3.2. However, if g++ is in-lining one
function, its probably in-lining them all. Adding inline to all functions
in ansic.c gets these results:
Compiler Program Cycles
-------- ------- ------
gcc-3.2 ansic.c 85044
g++-3.2 cpp.C 85042
which is a 0.002 percent difference. My guess is that even this small
difference is purely in the start-up code which is completely irrelevant
when the speed that matters is in the processing loop.
This little exercise shows that there is more to benchmarking than just
getting results. Once you have results, you have to:
1) Compare the results with other results (ie gcc-3.2 and g++-32. vs
gcc-2.95 and g++-2.95).
2) Analyze the results and figure out why you get the results you get
(in this case, by compiling to assembler it would have obvious that
gcc-3.2 was not by-default in-lining functions while the others were).
I think that for applications like audio processing where speed is one of
the main goals benchmarking is extremely important. Personally I would
love to see more people do it properly and publish their results like I
did here:
http://www.mega-nerd.com/FPcast/
Results like these are repeatable and verifiable.
Cheers,
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
When a user mailbombs me with 100,000 messages, we
call it denial of service and the guy can be thrown
in jail. When 100,000 SPAMMERS send me one mail each,
we call it marketing.
Hi all,
I'm trying to hack up a quick app that sends MIDI clock pulses in sync
with a ringbuffer playback.
I've got it reading MIDI (thanks to Matthias' great exmaple code), but I
cant figure out how to send MIDI clock pulses explicitly. The ALSA seq
interface lets me set it up to go automatically, but I want to send a
clock pulse every 1/24th of the buffer, so the sync is correct.
I dont think I can use raw MIDI because I need the ALSA seq for other
apps, on the same MIDI port.
- Steve
PS I know there are several apps that can, or will be able to do this, but
I need it to work by saturday. Its disposable code.
Hi,
>
>>> I think that for applications like audio processing where speed is one of
>>> the main goals benchmarking is extremely important. Personally I would
>>> love to see more people do it properly and publish their results like I
>>> did here:
>
>
> Agreed. If someone that knows c, c++ and objective c were to write up an
> audio focused benchmark that would be great. I've not realy used GObject,
> but I guess it should include that too.
Okay, this isn't even remotely audio focused, but nevertheless very
entertaining reading.
- The great computer language shootout -
http://www.bagley.org/~doug/shootout/
/Robert
Hi all,
A couple of days ago Steve Harris posted results from a quick benchmark on
on the jackit-devel mailing list.
On Wed, 12 Feb 2003 23:57:02 +0000
Steve Harris <S.W.Harris(a)ecs.soton.ac.uk> wrote:
> Just to follow up, I rebuilt my test code on gcc3, and it went from C++
> being around 30% slower, to about 1% faster, which is what I expected to
> see in the first place. I guess they fixed the optimizer deficiency.
As a C fan I was rather curious about this. I didn't want people getting the
wrong impression that C++ is automatically faster than C (it isn't) or that in
the long term improvements in the C++ compiler will make it faster than C
(it won't). So I asked Steve for more details and he pointed me at the code:
http://plugin.org.uk/filter/
and suggested that further discussion of this issue should probably be moved
from the jackit-devel list to this one. So here we are. (Steve, please don't
take this as a slight on you, I simply want to get the facts right).
For those interested, my machine is a dual 450Mhz PIII, with SCSI disks,
2.4.20 kernel and running Debian Testing. All compilers and toolchain
programs are from Debian Testing; none have been compiled from source.
Debian is rather nice in that it allows more than one compiler to be
installed on a machine at anyone time. Here are the compilers I used for
my testing:
erikd@coltrane > gcc-2.95 -v
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)
erikd@coltrane > g++-2.95 -v
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)
erikd@coltrane > gcc-3.2 -v
Reading specs from /usr/lib/gcc-lib/i386-linux/3.2.1/specs
Configured with: /mnt/data/gcc-3.1/gcc-3.2-3.2.1ds2/src/configure -v
--enable-languages=c,c++,java,f77,proto,objc,ada --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.2 --enable-shared
--with-system-zlib --enable-nls --without-included-gettext
--enable-java-gc=boehm --enable-objc-gc i386-linux
Thread model: posix
gcc version 3.2.1 20020924 (Debian prerelease)
erikd@coltrane > g++-3.2 -v
Reading specs from /usr/lib/gcc-lib/i386-linux/3.2.1/specs
Configured with: /mnt/data/gcc-3.1/gcc-3.2-3.2.1ds2/src/configure -v
--enable-languages=c,c++,java,f77,proto,objc,ada --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.2 --enable-shared
--with-system-zlib --enable-nls --without-included-gettext
--enable-java-gc=boehm --enable-objc-gc i386-linux
Thread model: posix
gcc version 3.2.1 20020924 (Debian prerelease)
And here are the results running Steve's tests (neglecting the Objective
C tests because my system seems to be missing something):
Compiler Program Cycles
-------- ------- ------
gcc-2.95 ansic.c 85058
g++-2.95 cpp.C 90719
gcc-3.2 ansic.c 196581
g++-3.2 cpp.C 85042
Thats all a little strange. So lets look at the code. In cpp.C, Steve
defines a Lowpass class and its process member functions like this:
class LowPass {
private:
float ym1;
float a;
public:
void setA(float newa);
void reset();
float process(float x);
};
float LowPass::process(float x)
{
float y = ym1 * (1.0f - a) + x * a;
ym1 = y;
return y;
}
while the C version is defined like this:
typedef struct {
float ym1;
float a;
} lowpass;
float lowpass_process(lowpass *this, float x)
{
float y;
y = this->ym1 * (1.0f - this->a) + x * this->a;
this->ym1 = y;
return y;
}
So what is going on here? Well my guess is that both versions of g++ and the
older version of gcc are applying an optimisation that the new gcc isn't and
my guess is that the missing optimisation is function in-lining. So why was
in-lining present in gcc-2.95 and absent in gcc-3.2? Thats probably because
gcc-3.2 is working towards compliance with the C1999 ISO Standard. In C99,
inline is a new C keyword.
If I now change the lowpass_process function as follows:
inline float lowpass_process(lowpass *this, float x)
{
float y;
y = this->ym1 * (1.0f - this->a) + x * this->a;
this->ym1 = y;
return y;
}
and add -std=c99 to the gcc-3.2 command line, the new results are:
Compiler Program Cycles
-------- ------- ------
gcc-3.2 ansic.c 86299
g++-3.2 cpp.C 85042
So, g++-3.2 is still beating gcc-3.2. However, if g++ is in-lining one
function, its probably in-lining them all. Adding inline to all functions
in ansic.c gets these results:
Compiler Program Cycles
-------- ------- ------
gcc-3.2 ansic.c 85044
g++-3.2 cpp.C 85042
which is a 0.002 percent difference. My guess is that even this small
difference is purely in the start-up code which is completely irrelevant
when the speed that matters is in the processing loop.
This little exercise shows that there is more to benchmarking than just
getting results. Once you have results, you have to:
1) Compare the results with other results (ie gcc-3.2 and g++-32. vs
gcc-2.95 and g++-2.95).
2) Analyze the results and figure out why you get the results you get
(in this case, by compiling to assembler it would have obvious that
gcc-3.2 was not by-default in-lining functions while the others were).
I think that for applications like audio processing where speed is one of
the main goals benchmarking is extremely important. Personally I would
love to see more people do it properly and publish their results like I
did here:
http://www.mega-nerd.com/FPcast/
Results like these are repeatable and verifiable.
Cheers,
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
When a user mailbombs me with 100,000 messages, we
call it denial of service and the guy can be thrown
in jail. When 100,000 SPAMMERS send me one mail each,
we call it marketing.
1. A short summary of changes
The JACK slave mode code has been completely rewritten. As a
new feature it is now possible to use libsamplerate for
resampling. Using JACK has been made more user-friendly as ecasound
can now automatically configure the runtime parameters to
match the current server settings. And thanks to build system
and signal handling updates, it's now possible to compile
ecasound for win32 under Cygwin.
---
2. What is ecasound?
Ecasound is a software package designed for multitrack audio
processing. It can be used for simple tasks like audio playback,
recording and format conversions, as well as for multitrack effect
processing, mixing, recording and signal recycling. Ecasound supports
a wide range of audio inputs, outputs and effect algorithms.
Effects and audio objects can be combined in various ways, and their
parameters can be controlled by operator objects like oscillators
and MIDI-CCs. A versatile console mode user-interface is included
in the package.
Ecasound is licensed under the GPL. The Ecasound Control Interface
(ECI) is licenced under the LGPL.
---
3. Changes since last release
* If configured with JACK-support, ecasound will now fetch the
correct buffer size and sampling rate parameters from the
JACK server when connecting a chainsetup with JACK inputs or
outputs. In other words you don't have to manually match
these settings between the JACK server and ecasound.
* Support for Erik de Castro Lopo's libsamplerate
resampling library added. If libsamplerate is not installed,
ecasound will fall back to the old resampling algorithm.
* Rewritten the code that handles JACK slave-mode operation.
Ecasound is now able to more quickly and reliably follow
transport state and position changes, as initiated by the
current JACK timebase master.
* Ecasound for Windows! :) With help of the Cygwin environment,
you can now compile win32 ecasound binaries straight from
the standard source package. As of 1.3.1, Cygwin also
contains basic /dev/dsp emulation, so even audio playback
works.
* Fixed many, more or less serious, bugs. The most annoying
ones were incorrect handling of the '-t' option, excessive
DBC warnings with JACK inputs and outputs and failing to
properly reset the terminal after a CTRL-C while in interactive
mode.
Full list of changes is available at
<http://www.wakkanet.fi/~kaiv/ecasound/history.html>.
---
4. Interface and configuration file changes
None.
---
5. Contributors
Patches
Junichi Uekawa (build system)
Kai Vehmanen (various)
Bug Hunting (items closed)
Janne Halttunen (2)
Eric Amundsen (1)
Antti Boman (1)
William Goldsmith (1)
Andrew Reilly (1)
Oliver Thuns (1)
---
6. Links and files
Web sites:
http://www.eca.cxhttp://www.eca.cx/ecasound
Source packages:
http://ecasound.seul.org/downloadhttp://ecasound.seul.org/download/ecasound-2.2.1.tar.gz
Related sites:
http://jackit.sf.net (JACK)
http://www.mega-nerd.com/SRC (libsamplerate)
http://www.cygwin.com
Distributions with maintained ecasound support:
Agnula - http://www.agnula.org
Debian - http://packages.debian.org/stable/sound/ecasound.htmlhttp://packages.debian.org/unstable/sound/ecasound2.2.html
DeMuDi - http://www.demudi.org
FreeBSD - http://www.freebsd.org/ports/audio.html
Gentoo Linux - http://www.gentoo.org
PLD Linux - http://www.pld.org.pl
PlanetCCRMA - http://www-ccrma.stanford.edu/planetccrma/software
SuSE Linux - http://www.suse.de/en
Contrib Packages for Distributions:
Mandrake - http://rpm.nyvalls.se/sound9.0.html
Note! Distributors do not necessarily provide packages for
the very latest ecasound version.
--
http://www.eca.cx
Audio software for Linux!
Well, here's the reason for the delay: The .org domains are being
moved to some other maintaner, and as a result, domain info is
totally screwed up. xap.org has been taken for almost 3 years,
apparently by the same owner as xap.net... :-/
(I did get audiality.org while I was at it, but that's to be expected.
Weird names have their advantages...)
Now, should I try some others instead? xapaudioplugins.org (*heh*) or
whatever? Not all that interesting, of course...
Well, I could try and contact the owner of xap.org. Doesn't seem to be
Xap Corporation (who owns xap.com), but they'll probably want some
extra bucks anyway.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
