27 Sep
2007
27 Sep
'07
2:32 p.m.
Hallo list!
I am just thinking about the right strategy for denormal handling in a
floating point (single or double prec) audio application (and yes I
already read the docs of the different methods at musicdsp and so on ...)
Basically my question is, if it is enough to simply turn on the
Flush-to-zero and Denormals-are-zero mode and then compile everything
with -msse -mfpmath=sse ?
I know it won't run on older Pentium3,2 etc. - but for the machines
which support this feature, is this enough ?
Thanks for any hint,
LG
Georg
27 Sep
27 Sep
2:39 p.m.
On Thu, 2007-09-27 at 18:32 +0200, Georg Holzmann wrote:
Hallo list!
I am just thinking about the right strategy for denormal handling in a
floating point (single or double prec) audio application (and yes I
already read the docs of the different methods at musicdsp and so on ...)
Basically my question is, if it is enough to simply turn on the
Flush-to-zero and Denormals-are-zero mode and then compile everything
with -msse -mfpmath=sse ?
I know it won't run on older Pentium3,2 etc. - but for the machines
which support this feature, is this enough ?
it helps, but adding a small DC bias (i.e. adding a very very very small
constant number to all sample data) works even better.
if you app is going to be GPL'ed, feel free to grab libs/pbd/fpu.cc from
the ardour source code.
--p
5:19 p.m.
Hallo!
Thanks for all the answers !
it helps, but adding a small DC bias (i.e. adding a
very very very small
constant number to all sample data) works even better.
What do you mean with "works even better"? If we assume that denormal
handling is supported by hardware (like in pentium4 + etc.), isn't this
unnecessary ?
BTW: adding just a small DC bias won't work if I have IIR high pass like
structure, or am I wrong ?
if you app is going to be GPL'ed, feel free to
grab libs/pbd/fpu.cc from
the ardour source code.
Thanks!
LG
Georg
6:22 p.m.
On Thu, Sep 27, 2007 at 09:19:53PM +0200, Georg Holzmann wrote:
BTW: adding just a small DC bias won't work if I
have IIR high pass like
structure, or am I wrong ?
You have to apply the small offset at 'strategic places'. For an IIR
this is at the summing node, to the value that gets stored into the
filter's delay line. In other words, inside the feedback loop.
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
29 Sep
29 Sep
4:26 p.m.
On Thu, 2007-09-27 at 22:31 +0200, Fons Adriaensen wrote:
On Thu, Sep 27, 2007 at 09:19:53PM +0200, Georg
Holzmann wrote:
Fons!
Although you are approximately right in many parts of this discussion,
you are wrong on the cost of the CPU flags to round twards zero. The
cost is nil.
Unlike other forms of Voodoo, we can neasure this.
mvh // Jens M Andreasen
BTW: adding just a small DC bias won't work
if I have IIR high pass like
structure, or am I wrong ?
You have to apply the small offset at 'strategic places'. For an IIR
this is at the summing node, to the value that gets stored into the
filter's delay line. In other words, inside the feedback loop.
7:48 p.m.
On Sat, Sep 29, 2007 at 08:25:53PM +0200, Jens M Andreasen wrote:
On Thu, 2007-09-27 at 22:31 +0200, Fons Adriaensen
wrote:
I never said the cost was not nil... In fact I never said anything
about it at all !
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
On Thu, Sep 27, 2007 at 09:19:53PM +0200, Georg
Holzmann wrote:
Fons!
Although you are approximately right in many parts of this discussion,
you are wrong on the cost of the CPU flags to round twards zero. The
cost is nil. BTW: adding just a small DC bias won't work
if I have IIR high pass like
structure, or am I wrong ?
You have to apply the small offset at 'strategic places'. For an IIR
this is at the summing node, to the value that gets stored into the
filter's delay line. In other words, inside the feedback loop.
8:09 p.m.
Jens M Andreasen wrote:
Although you are approximately right in many parts of
this discussion,
you are wrong on the cost of the CPU flags to round twards zero. The
cost is nil.
My memory of this is that changing the FPU flags causes a pipeline flush.
If the happens inside an inner loop, this has a **huge** performance
penalty.
Unlike other forms of Voodoo, we can neasure this.
Have you?
Erik
--
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
Orcad Express 9: "Its a nice demo but I wouldn't want to use it
on a day-to-day basis" -- me
8:14 p.m.
On Sun, 2007-09-30 at 08:09 +1000, Erik de Castro Lopo wrote:
Jens M Andreasen wrote:
this would be a truly terrible and stupid design.
which i guess is why there actually are VST plugins that do this on
every process() call.
our use of it in Ardour is host-wide, at program startup, which i
believe is the only sensible way to use FTZ or DAZ.
--p
Although you are approximately right in many
parts of this discussion,
you are wrong on the cost of the CPU flags to round twards zero. The
cost is nil.
My memory of this is that changing the FPU flags causes a pipeline flush.
If the happens inside an inner loop, this has a **huge** performance
penalty.
6607
days inactive
6609
days old
linux-audio-dev@lists.linuxaudio.org
7 comments
5 participants
participants (5)
-
Erik de Castro Lopo -
Fons Adriaensen -
Georg Holzmann -
Jens M Andreasen -
Paul Davis