23 Jun
2004
23 Jun
'04
5:03 p.m.
http://plugin.org.uk/releases/0.4.4/
* Fixes to build on recent gcc
* New limiter for beter performance in JAMin
* Denomal fixes from Tim Blechmann (general and specifially the flanger)
* Many other things I've forgotten :(
This release is largely untested, I released it because there are a number
of important outstanding fixes. It may break some plugins, so beware.
- Steve
23 Jun
23 Jun
8:56 p.m.
On Среда 23 Июнь 2004 22:54, Steve Harris wrote:
http://plugin.org.uk/releases/0.4.4/
* Fixes to build on recent gcc
* New limiter for beter performance in JAMin
* Denomal fixes from Tim Blechmann (general and specifially the flanger)
* Many other things I've forgotten :(
This release is largely untested, I released it because there are a number
of important outstanding fixes. It may break some plugins, so beware.
- Steve
Ooops.
--------------------------------------------------------------------------------------------------------------------------------
make[2]: Entering directory `/home/aris/RPM/BUILD/swh-plugins-0.4.4/metadata'
./lxml2rdf.pl ../*.xml > swh-plugins.rdf
xmllint -noout swh-plugins.rdf
make[2]: *** No rule to make target `scale-points.txt', needed by
`swh-scales.rdf'. Stop.
make[2]: Leaving directory `/home/aris/RPM/BUILD/swh-plugins-0.4.4/metadata'
make[1]: *** [all-recursive] Error 1
_________________________________________________________________
gcc-3.3.3
autoconf-2.59
automake-1.8.3
--
Yuri N. Sedunov
06/24/04 02:41:14
24 Jun
24 Jun
3:20 a.m.
New subject: [linux-audio-dev] swh plugins and fixing undenormalize
On Wednesday 23 June 2004 15:54, Steve Harris wrote:
http://plugin.org.uk/releases/0.4.4/
* Fixes to build on recent gcc
* New limiter for beter performance in JAMin
* Denomal fixes from Tim Blechmann (general and specifially the flanger)
* Many other things I've forgotten :(
This release is largely untested, I released it because there are a number
of important outstanding fixes. It may break some plugins, so beware.
- Steve
Sorry for not checking, but I guess it could be good for the record (and
people googling for it) to ask here..
The macro for dealing denormals that I have is:
#define undenormalise(sample) if(((*(unsigned int*)&sample)&0x7f800000)==0)
sample=0.0f
however gcc 3.3 and 3.4 seem to produce an undesired effect
when the optimizer is turned on, rendering this macro unusable..
this breaks freeverb and a few other stuff I have that uses it.
How was/is this fixed properly?
Cheers!
reduz
5:40 a.m.
New subject: [linux-audio-dev] swh plugins and fixing undenormalize
On Thu, 24 Jun 2004 02:11:34 -0300
Juan Linietsky <coding(a)reduz.com.ar> wrote:
Sorry for not checking, but I guess it could be good
for the record (and
people googling for it) to ask here..
The macro for dealing denormals that I have is:
#define undenormalise(sample) if(((*(unsigned int*)&sample)&0x7f800000)==0)
sample=0.0f
however gcc 3.3 and 3.4 seem to produce an undesired effect
when the optimizer is turned on, rendering this macro unusable..
this breaks freeverb and a few other stuff I have that uses it.
How was/is this fixed properly?
Personally, I think that macro is rather silly. You bascially end up
forcing data that would otherwise be in the floating point pipeline
into the integer pipeline and then latter, it probably goes back into
the FP pipeline. Secondly, it contains a branch which is usually far
from optimal.
Since the problem is denormalised numbers, has anybody thought of
adding a small DC offset (1e-15) or alternating the addition/subraction
of a small value?
If I had a spare couple of hours I'd benchmark it myself.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"Open source is an intellectual-property destroyer. I can't
imagine something that could be worse than this for the software
business and the intellectual-property business."
-- Jim Allchin, Microsoft
6:10 a.m.
New subject: [linux-audio-dev] swh plugins and fixing undenormalize
Since the problem is denormalised numbers, has anybody
thought of
adding a small DC offset (1e-15) or alternating the
addition/subraction of a small value?
of course it is possible to add a small dc
offset ... but what if we are
working in a feedback loop? or even worse with a high pass filter?
if you alter addition/substraction and send it throuth a low pass filer?
the denormal problem is not a trivial one, but afaik a macro like this
is the only one working for sure...
cheers .... tim
--
mailto:TimBlechmann@gmx.de ICQ: 96771783
After one look at this planet any visitor from outer space
would say "I want to see the manager."
William S. Burroughs
6:51 a.m.
New subject: [linux-audio-dev] swh plugins and fixing undenormalize
On Thu, 24 Jun 2004 11:03:34 +0200, Tim Blechmann wrote
The other approach I've seen is to add inaudable random noise to the signal.
dave
Since the
problem is denormalised numbers, has anybody thought of
adding a small DC offset (1e-15) or alternating the
addition/subraction of a small value?
of course it is possible to add a small dc
offset ... but what if we
are working in a feedback loop? or even worse with a high pass
filter? if you alter addition/substraction and send it throuth a low
pass filer? the denormal problem is not a trivial one, but afaik a
macro like this is the only one working for sure... 
6:37 a.m.
New subject: [linux-audio-dev] swh plugins and fixing undenormalize
Erik de Castro Lopo wrote:
On Thu, 24 Jun 2004 02:11:34 -0300
Juan Linietsky <coding(a)reduz.com.ar> wrote:
I (re)discovered the following branch-free method a while ago:
/* branch-free denormal killer (slightly blunt) */
inline float FlushToZero( volatile float f )
{
f += 9.8607615E-32f;
return f - 9.8607615E-32f;
}
/* end */
The people who discovered it first call this method
"Elimination by Quantification".
Its slightly blunt because it damages the precision of
extremely low but not yet denormal numbers: Anything
of magnitude < 2 ** -103 loses one bit of precision for
each binary order of magnitude it is below that number.
(This means that denormal numbers lose /all/ of their
precision and become zero).
Simon Jenkins
(Bristol, UK)
Sorry for not checking, but I guess it could be
good for the record (and
people googling for it) to ask here..
The macro for dealing denormals that I have is:
#define undenormalise(sample) if(((*(unsigned int*)&sample)&0x7f800000)==0)
sample=0.0f
however gcc 3.3 and 3.4 seem to produce an undesired effect
when the optimizer is turned on, rendering this macro unusable..
this breaks freeverb and a few other stuff I have that uses it.
How was/is this fixed properly?
Personally, I think that macro is rather silly. You bascially end up
forcing data that would otherwise be in the floating point pipeline
into the integer pipeline and then latter, it probably goes back into
the FP pipeline. Secondly, it contains a branch which is usually far
from optimal.
6:46 a.m.
New subject: [linux-audio-dev] swh plugins and fixing undenormalize
On Thu, 24 Jun 2004 10:37:35 +0100
Simon Jenkins <sjenkins(a)blueyonder.co.uk> wrote:
inline float FlushToZero( volatile float f )
{
f += 9.8607615E-32f;
return f - 9.8607615E-32f;
}
/* end */
The people who discovered it first call this method
"Elimination by Quantification".
Its slightly blunt because it damages the precision of
extremely low but not yet denormal numbers: Anything
of magnitude < 2 ** -103 loses one bit of precision for
each binary order of magnitude it is below that number.
(This means that denormal numbers lose /all/ of their
precision and become zero).
There we go!!! That is an elegant solution.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"Republicans understand the importance of bondage between
mother and child." - George W. Bush
--
+-----------------------------------------------------------+
Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
Everyone seems to assume that the current system in America is capitalism.
I beg to differ. True capitalism does not involve false advertising,
distribution cartels, or political lobbying for special advantages in the
market. How can you call Microsoft or the RIAA capitalist, when their main
business is interfering with a free market? Some of us would like to see a
*return* to capitalism in this country. - Jim Flynn on Linuxtoday.com
7:30 a.m.
New subject: [linux-audio-dev] swh plugins and fixing undenormalize
On Thu, Jun 24, 2004 at 06:36:47 +1000, Erik de Castro Lopo wrote:
On Thu, 24 Jun 2004 10:37:35 +0100
Simon Jenkins <sjenkins(a)blueyonder.co.uk> wrote:
Until the optimiser notices... but agreed its nicer. How much damage does
it do if you change one of the constant values slightly? The DC offset
would only occur at very low signals, so shouldn't affect feedback loops.
- Steve
inline float FlushToZero( volatile float f )
{
f += 9.8607615E-32f;
return f - 9.8607615E-32f;
}
There we go!!! That is an elegant solution.
2:19 p.m.
New subject: [linux-audio-dev] swh plugins and fixing undenormalize
On Thursday 24 June 2004 06:21, Steve Harris wrote:
On Thu, Jun 24, 2004 at 06:36:47 +1000, Erik de Castro
Lopo wrote:
That actually looks nice... since thanks to writing "volatile float f",
the optimizer should not touch it.. it' the same thing than
when one accsses directly to the harware using pointers
to memmaped registers.. lack of using "volatile" often
ends up in non-working code..
cheers!
reduz
On Thu, 24 Jun 2004 10:37:35 +0100
Simon Jenkins <sjenkins(a)blueyonder.co.uk> wrote:
Until the optimiser notices... but agreed its nicer. How much damage does
it do if you change one of the constant values slightly? The DC offset
would only occur at very low signals, so shouldn't affect feedback loops.
- Steve inline float FlushToZero( volatile float f )
{
f += 9.8607615E-32f;
return f - 9.8607615E-32f;
}
There we go!!! That is an elegant solution.
2:40 p.m.
New subject: [linux-audio-dev] swh plugins and fixing undenormalize
On Thu, Jun 24, 2004 at 01:10:37 -0300, Juan Linietsky wrote:
Ah, yes, I guess volatile should mean that. Hmmm...
- Steve
> >
inline float FlushToZero( volatile float f )
> > {
> > f += 9.8607615E-32f;
> > return f - 9.8607615E-32f;
> > }
That actually looks nice... since thanks to writing "volatile float f",
the optimizer should not touch it.. it' the same thing than
when one accsses directly to the harware using pointers
to memmaped registers.. lack of using "volatile" often
ends up in non-working code..
8:45 p.m.
New subject: [linux-audio-dev] swh plugins and fixing undenormalize
Steve Harris wrote:
On Thu, Jun 24, 2004 at 01:10:37 -0300, Juan Linietsky
wrote:
Ah, yes, I guess volatile should mean that. Hmmm...
The reason its an inline function rather than a drop-in replacement
macro is because casting macro arguments to volatile wasn't having
the desired effect on the optimiser, whereas this does.
Simon Jenkins
(Bristol, UK)
>>inline float FlushToZero( volatile float f )
>>{
>> f += 9.8607615E-32f;
>> return f - 9.8607615E-32f;
>>}
>>
>>
That actually looks nice... since thanks to writing "volatile float
f",
the optimizer should not touch it.. it' the same thing than
when one accsses directly to the harware using pointers
to memmaped registers.. lack of using "volatile" often
ends up in non-working code..
7:27 a.m.
New subject: [linux-audio-dev] swh plugins and fixing undenormalize
On Thu, Jun 24, 2004 at 05:31:30 +1000, Erik de Castro Lopo wrote:
Since the problem is denormalised numbers, has anybody
thought of
adding a small DC offset (1e-15) or alternating the addition/subraction
of a small value?
Yes. I use it in some places.
The problem with addition is that denormals tend to bite in feedback
loops, where DC offsets are a bit of a pain.
You can do
y += delta
y -= delta
but youre at the mercy of the optimiser.
If I had a spare couple of hours I'd benchmark it
myself.
There is some stuff online about it.
A C99 safe version of the obove macro (with a bit of extension, to catch
"P4 denormals") is:
typedef union {
float f;
int32_t i;
} ls_pcast32;
static inline float flush_to_zero(float f)
{
ls_pcast32 v;
v.f = f;
// original: return (v.i & 0x7f800000) == 0 ? 0.0f : f;
// version from Tim Blechmann:
return (v.i & 0x7f800000) < 0x08000000 ? 0.0f : f;
}
- Steve
9:29 a.m.
New subject: [linux-audio-dev] swh plugins and fixing undenormalize
Steve Harris wrote:
You can do
y += delta
y -= delta
but youre at the mercy of the optimiser.
The IEEE standard specifies exactly what happens with denormals, so,
in theory, the compiler must not optimize this away. However,
optimization options for speed often disable strict IEEE
compatibility. (I don't know how gcc's options behave.)
A C99 safe version of the obove macro (with a bit of
extension, to catch
"P4 denormals") is:
typedef union {
float f;
int32_t i;
} ls_pcast32;
...
v.f = f;
return (v.i & 0x7f800000) < 0x08000000 ? 0.0f : f;
AFAIK this isn't safe either because the same type aliasing rules
apply to unions, too. The only safe way is to go through char
pointers.
Regards,
Clemens
11:08 a.m.
New subject: [linux-audio-dev] swh plugins and fixing undenormalize
On Thu, Jun 24, 2004 at 01:20:34 +0200, Clemens Ladisch wrote:
OK, thats interesting. I though it was OK, in that compiler is required to
make &v.f == &v.i, where sizeof(v.f) == sizeof(v.i)? Maybe I misunderstood.
In any case my code is full of gcc-isms, I doubt it would build on any
signifiantly different compiler.
- Steve
The IEEE standard specifies exactly what happens with
denormals, so,
in theory, the compiler must not optimize this away. However,
optimization options for speed often disable strict IEEE
compatibility. (I don't know how gcc's options behave.)
If you use -ffast-math then it note reuiqred to maintin strict IEEE
semantics. Its a lot faster for some operations if you do.
typedef union
{
float f;
int32_t i;
} ls_pcast32;
AFAIK this isn't safe either because the same type aliasing rules
apply to unions, too. The only safe way is to go through char
pointers.
7:34 a.m.
New subject: [linux-audio-user] Re: [linux-audio-dev] swh plugins and fixing undenormalize
On Thu, Jun 24, 2004 at 02:11:34AM -0300, Juan Linietsky wrote:
#define undenormalise(sample) if(((*(unsigned
int*)&sample)&0x7f800000)==0)
sample=0.0f
however gcc 3.3 and 3.4 seem to produce an undesired effect
when the optimizer is turned on, rendering this macro unusable..
this breaks freeverb and a few other stuff I have that uses it.
It violates C99's pointer aliasing rules. I've posed a C99 friendly
version later in the thread.
Another point of differentiation between denomal hacks is tht this one
doesnt even analyse the potential denomal as a float, so you miss one
denomal operation that can occur with cleaner methods.
- Steve
7:32 a.m.
New subject: [linux-audio-dev] Re: [linux-audio-announce] [ANN] swh-plugins 0.4.4
A lot of people mailed me about a missing file (scale-points.txt,
attached), it should be there, but I'm not sure why its needed cos the
file that is built from it is in hte tarball.
Anyway, I've attached it.
- Steve
On Wed, Jun 23, 2004 at 07:54:04PM +0100, Steve Harris wrote:
http://plugin.org.uk/releases/0.4.4/
* Fixes to build on recent gcc
* New limiter for beter performance in JAMin
* Denomal fixes from Tim Blechmann (general and specifially the flanger)
* Many other things I've forgotten :(
This release is largely untested, I released it because there are a number
of important outstanding fixes. It may break some plugins, so beware.
- Steve
_______________________________________________
linux-audio-announce mailing list
linux-audio-announce(a)music.columbia.edu
http://music.columbia.edu/mailman/listinfo/linux-audio-announce
7548
days inactive
7549
days old
linux-audio-dev@lists.linuxaudio.org
16 comments
8 participants
participants (8)
-
Clemens Ladisch -
Dave Griffiths -
Erik de Castro Lopo -
Juan Linietsky -
Simon Jenkins -
Steve Harris -
Tim Blechmann -
Yuri N. Sedunov