2 Dec
2003
2 Dec
'03
1:59 p.m.
http://plugin.org.uk/releases/0.4.3/
New plugins:
Butterworth filter plugin (Alexander Ehlert)
Impulse generator plugin (Andy Wingo)
Delay plugin (Andy Wingo)
Signal decay plugin (Andy Wingo)
DJEQ plugin (me)
Reverse Delay plugin (Jesse Chappell)
Expander plugin (me, more-or-less untested)
Vinyl sound plugin (me)
Improvements:
Improvements to the IIR filter code (Alexander Ehlert)
Gain and delay correction factors for hilbert transformer (Fons Adriaensen)
Make biquads internally float/douable at compile time (me)
Changes to pitch scale (can't remember why, me)
Added latency reporting ports to (most) plugins that need them (me)
Updated README and auto* stuff (me)
Changes to allow building under Win32 (Audacity Project)
Fixed UID clash (me)
- Steve
3 Dec
3 Dec
4:43 a.m.
Steve Harris wrote:
http://plugin.org.uk/releases/0.4.3/
New plugins:
Butterworth filter plugin (Alexander Ehlert)
Impulse generator plugin (Andy Wingo)
Delay plugin (Andy Wingo)
Signal decay plugin (Andy Wingo)
DJEQ plugin (me)
Reverse Delay plugin (Jesse Chappell)
Expander plugin (me, more-or-less untested)
Vinyl sound plugin (me)
Improvements:
Improvements to the IIR filter code (Alexander Ehlert)
Gain and delay correction factors for hilbert transformer (Fons Adriaensen)
Make biquads internally float/douable at compile time (me)
Changes to pitch scale (can't remember why, me)
Added latency reporting ports to (most) plugins that need them (me)
Updated README and auto* stuff (me)
Changes to allow building under Win32 (Audacity Project)
Fixed UID clash (me)
- Steve
whohooo!
builds fine, except for those warnings:
ladspa-util.h: In function `f_trunc':
ladspa-util.h:110: warning: dereferencing type-punned pointer will break
strict-aliasing rules
however, when i use --enable-sse, gcc falls apart:
ladspa-util.h: In function `runRateShifter':
ladspa-util.h:78: internal compiler error: in emit_move_insn, at expr.c:3149
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.suse.de/feedback> for instructions.
make[2]: *** [rate_shifter_1417.so.o] Error 1
make[2]: *** Waiting for unfinished jobs....
has anyone submitted this to the gcc folks? or is it a known problem?
i would love to be able to use sse, it might really help my old-ish box
up to speed.
best,
jörn
--
To someone whose only tool is a hammer, each problem looks like a nail.
- Edsger W. Dijkstra, EWD838
Jörn Nettingsmeier
Kurfürstenstr 49, 45138 Essen, Germany
http://spunk.dnsalias.org (my server)
http://www.linuxaudiodev.org (Linux Audio Developers)
5:04 a.m.
On Wed, Dec 03, 2003 at 09:41:30AM +0100, Joern Nettingsmeier wrote:
builds fine, except for those warnings:
ladspa-util.h: In function `f_trunc':
ladspa-util.h:110: warning: dereferencing type-punned pointer will break
strict-aliasing rules
Very true, but I dont think I asked to compiler to use strict aliasing,
can you send an example gcc line make spits out? I've checked a fix into
CVS that should stop alising for most people anyway.
Anyone know why some gcc's check for aliasing?
however, when i use --enable-sse, gcc falls apart:
Oops. Yes, that a known problem, but I think the README file is a bit
misleading - its supposed to be hinting that you should build FFTW with
--enable-sse, not the plugins. gcc's automatic SSE support is not very
good (which is all it enables IIRC), and used to produce worse code.
If your gcc is new enough it might ne better, i'd be happy to hear if it
is. I'l change the README.
- Steve
5:44 a.m.
Steve Harris wrote:
On Wed, Dec 03, 2003 at 09:41:30AM +0100, Joern
Nettingsmeier wrote:
gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -Wall -O6
-fomit-frame-pointer -fstrength-reduce -funroll-loops
-fmove-all-movables -ffast-math -fPIC -DPIC -mcpu=i686 -march=i686 -c
imp_1199.so.c
In file included from imp_1199.xml:37:
ladspa-util.h: In function `f_trunc':
ladspa-util.h:110: warning: dereferencing type-punned pointer will break
strict-aliasing rules
builds fine, except for those warnings:
ladspa-util.h: In function `f_trunc':
ladspa-util.h:110: warning: dereferencing type-punned pointer will break
strict-aliasing rules
Very true, but I dont think I asked to compiler to use strict aliasing,
can you send an example gcc line make spits out? I've checked a fix into
CVS that should stop alising for most people anyway. Anyone know why some gcc's check for aliasing?
so i can safely use --enable-sse with fftw, when it produces an internal
compiler error with swh-plugins???
however, when i use --enable-sse, gcc falls apart:
Oops. Yes, that a known problem, but I think the README file is a bit
misleading - its supposed to be hinting that you should build FFTW with
--enable-sse, not the plugins. gcc's automatic SSE support is not very
good (which is all it enables IIRC), and used to produce worse code. If your gcc is new enough it might ne better, i'd
be happy to hear if it
is. I'l change the README.
# gcc -v
Reading specs from /usr/lib/gcc-lib/i586-suse-linux/3.3.1/specs
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib
--enable-languages=c,c++,f77,objc,java,ada --disable-checking
--enable-libgcj --with-gxx-include-dir=/usr/include/g++
--with-slibdir=/lib --with-system-zlib --enable-shared
--enable-__cxa_atexit i586-suse-linux
Thread model: posix
gcc version 3.3.1 (SuSE Linux)
--
To someone whose only tool is a hammer, each problem looks like a nail.
- Edsger W. Dijkstra, EWD838
Jörn Nettingsmeier
Kurfürstenstr 49, 45138 Essen, Germany
http://spunk.dnsalias.org (my server)
http://www.linuxaudiodev.org (Linux Audio Developers)
6 a.m.
On Wed, Dec 03, 2003 at 10:42:40 +0100, Joern Nettingsmeier wrote:
Yes, the --enable-* options are implemented by the package, in my case it
tries to use the sse operations instead of the 387 ones. Its supposed
to be an improvement (at least on PIV).
- Steve
Oops. Yes, that
a known problem, but I think the README file is a bit
misleading - its supposed to be hinting that you should build FFTW with
--enable-sse, not the plugins. gcc's automatic SSE support is not very
good (which is all it enables IIRC), and used to produce worse code.
so i can safely use --enable-sse with fftw, when it produces an internal
compiler error with swh-plugins??? 
6:42 a.m.
--- Joern Nettingsmeier <nettings(a)folkwang-hochschule.de> wrote: > Steve
Harris wrote:
-O2 will include the -fstrict-aliasing flag for gcc, so it's turned on here.
I've no idea what -O6 does (intel compiler, pgcc?). -O3 is the highest in the
gcc documentation.
Mike
________________________________________________________________________
Download Yahoo! Messenger now for a chance to win Live At Knebworth DVDs
http://www.yahoo.co.uk/robbiewilliams
On Wed, Dec
03, 2003 at 09:41:30AM +0100, Joern Nettingsmeier wrote:
gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -Wall -O6
-fomit-frame-pointer -fstrength-reduce -funroll-loops
-fmove-all-movables -ffast-math -fPIC -DPIC -mcpu=i686 -march=i686 -c
imp_1199.so.c builds fine, except for those warnings:
ladspa-util.h: In function `f_trunc':
ladspa-util.h:110: warning: dereferencing type-punned pointer will break
strict-aliasing rules
Very true, but I dont think I asked to compiler to use strict aliasing,
can you send an example gcc line make spits out? I've checked a fix into
CVS that should stop alising for most people anyway.
7:20 a.m.
On Wed, Dec 03, 2003 at 10:41:05 +0000, Mike Rawes wrote:
-O2 will include the -fstrict-aliasing flag for gcc,
so it's turned on here.
I've no idea what -O6 does (intel compiler, pgcc?). -O3 is the highest in the
gcc documentation.
-O6 is historical, I just keep it in cos it doesnt hurt. Interesting that
-O2 turns on strict aliasing... that changes the semantics of ANSI C,
though I've a feeling that C99 might specify strict aliasing.
- Steve
7:30 a.m.
On Wed, Dec 03, 2003 at 11:18:42 +0000, Steve Harris wrote:
-O6 is historical, I just keep it in cos it doesnt
hurt. Interesting that
-O2 turns on strict aliasing... that changes the semantics of ANSI C,
though I've a feeling that C99 might specify strict aliasing.
Sorry, typo, s/ANSI C/ANSI C89/, C99 is the also ANSI C of course.
- Steve
10:18 a.m.
At Wed, 3 Dec 2003 11:18:42 +0000,
Steve Harris wrote:
On Wed, Dec 03, 2003 at 10:41:05 +0000, Mike Rawes wrote:
as far as i understand, there is no strict definition of behavior
about type punning. with GCC, you can use a union as a workaround (as
found in info), but it's not sure to work with other compilers...
Takashi
-O2 will include the -fstrict-aliasing flag for
gcc, so it's turned on here.
I've no idea what -O6 does (intel compiler, pgcc?). -O3 is the highest in the
gcc documentation.
-O6 is historical, I just keep it in cos it doesnt hurt. Interesting that
-O2 turns on strict aliasing... that changes the semantics of ANSI C,
though I've a feeling that C99 might specify strict aliasing.
10:56 a.m.
On Wed, Dec 03, 2003 at 02:55:48PM +0100, Takashi Iwai wrote:
as far as i understand, there is no strict definition
of behavior
about type punning. with GCC, you can use a union as a workaround (as
found in info), but it's not sure to work with other compilers...
I though unions were guaranteed to work as long as the punned types are of
the same size?
- Steve
2:18 p.m.
At Wed, 3 Dec 2003 14:54:44 +0000,
Steve Harris wrote:
On Wed, Dec 03, 2003 at 02:55:48PM +0100, Takashi Iwai wrote:
on gcc, yes, it's guaranteed to work. but not guaranteed for others,
although i can't imagine there would be any compiler that doesn't
assure this behavior :)
Takashi
as far as i understand, there is no strict
definition of behavior
about type punning. with GCC, you can use a union as a workaround (as
found in info), but it's not sure to work with other compilers...
I though unions were guaranteed to work as long as the punned types are of
the same size?
7721
days inactive
7722
days old
linux-audio-dev@lists.linuxaudio.org
10 comments
4 participants
participants (4)
-
Joern Nettingsmeier -
Mike Rawes -
Steve Harris -
Takashi Iwai