[LAD] is this a compiler issue??

[Conrad Berhörster]

Hello all, 

i have written a channel class, which collects data from (file) sources and 
copies it to a buffer. Jack will get this buffer and put it into his streams. 
So far, I think, this is a normal design with the following code

for (unsigned int n = 0; n < nframes; ++n)
{
   pBuffer[n] += pFrames[n];
   pBuffer[n]  *= volume;
}

i know, it's not really optimized. But it works as an example. as you can 
think, pBuffer and pFrames are float* and volume is also a float. 

now it happens, when the volume is 0, after 3-5 seconds, the CPU will run into 
100%. 

a workaround is the following before the loop 

if(volume < 0.001)
volume = 0.001;

But i try to understand, what happens here. Is the compiler overoptimizing 
zeros. 
compiler is:  $g++ -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-
c++,treelang --prefix=/usr --enable-shared --with-system-zlib --
libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --
enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --
enable-libstdcxx-debug --enable-mpfr --with-tune=i686 --enable-
checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)


what puzzles me is, that this doesn't happen on my double core system. 

Any ideas. Thanks c~
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] is this a compiler issue??

[Tim Goetze]

[Conrad Berhörster]
>i have written a channel class, which collects data from (file) sources and 
>copies it to a buffer. Jack will get this buffer and put it into his streams. 
>So far, I think, this is a normal design with the following code
>
>for (unsigned int n = 0; n < nframes; ++n)
>{
>  pBuffer[n] += pFrames[n];
>  pBuffer[n]  *= volume;
>}
>
>i know, it's not really optimized. But it works as an example. as you can 
>think, pBuffer and pFrames are float* and volume is also a float. 
>
>now it happens, when the volume is 0, after 3-5 seconds, the CPU will run into 
>100%. 
>
>a workaround is the following before the loop 
>
>   if(volume < 0.001)
>   volume = 0.001;
>
>But i try to understand, what happens here. Is the compiler overoptimizing 
>zeros. 

It'd be a lot more helpful to see the full source but from what you're 
writing I'd be willing to bet you're encountering denormals.

Cheers, Tim___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] is this a compiler issue??

[Conrad Berhörster]

Hello Tim, 

On Wednesday 19 August 2009 12:37:36 Tim Goetze wrote:
>
> It'd be a lot more helpful to see the full source but from what you're
> writing I'd be willing to bet you're encountering denormals.

geeh, good point. So there is no opponent in betting with you ;=) 

anyway, as i have a quick read of http://ardour.org/node/139, my code with the 
if wasn't a workaround, it is the solution, as long as the CPU isn't a SSE, 
right?

bye c~


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] is this a compiler issue??

[Jens M Andreasen]

#include  

#define CPUID(f,ax,bx,cx,dx) __asm__ __volatile__ \
("cpuid": "=a" (ax), "=b" (bx), "=c" (cx), "=d" (dx) : "a" (f))

// denormal protection

static int  set_DAZ_and_FTZ(int /*bool*/ on)
{
   int sse_level = 0;
   
   if(on)
   {
  unsigned long ax, bx, cx, dx;
  
  CPUID(0x00,ax,bx,cx,dx);
  CPUID(0x01,ax,bx,cx,dx);

  if (dx & 0x0200) 
  {
 sse_level = 1;  
 // set FLUSH_TO_ZERO to ON and
 // set round towards zero (RZ)
 _mm_setcsr(_mm_getcsr() | 0x8000|0x6000);

 if (dx & 0x0400) 
 {
sse_level = 2;
  
if (cx & 0x0001) 
{
   sse_level = 3;
   // set DENORMALS_ARE_ZERO to ON
   _mm_setcsr(_mm_getcsr() | 0x0040); 
}
// we should have checked for AMD K8 without SSE3 here:
// if(AMD_K8_NO_SSE3) 
// .. but I can't recall how to that :-/
 }
  }
   } else  
  // clear underflow and precision flags 
  // and set DAZ and FTZ to OFF 
  // and restore round to nearest (RN)
  _mm_setcsr(_mm_getcsr() & ~(0x0030|0x8000|0x0040|0x6000));
   
   return sse_level;
}


On Wed, 2009-08-19 at 12:37 +0200, Tim Goetze wrote:
> [Conrad Berhörster]
> >But i try to understand, what happens here. Is the compiler overoptimizing 
> >zeros. 
> 
> It'd be a lot more helpful to see the full source but from what you're 
> writing I'd be willing to bet you're encountering denormals.
> 
> Cheers, Tim


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] is this a compiler issue??

[Fons Adriaensen]

On Wed, Aug 19, 2009 at 11:52:15AM +0200, Conrad Berhörster wrote:

> for (unsigned int n = 0; n < nframes; ++n)
> {
>  pBuffer[n] += pFrames[n];
>  pBuffer[n]  *= volume;
> }
> 
> i know, it's not really optimized. But it works as an example. as you can 
> think, pBuffer and pFrames are float* and volume is also a float. 
> 
> now it happens, when the volume is 0, after 3-5 seconds, the CPU will run 
> into 
> 100%. 
> 
> a workaround is the following before the loop 
> 
>   if(volume < 0.001)
>   volume = 0.001;

You are getting 'denormals' which are floating point
values that are not representable in the normal format.
In that case the FP processor will raise an exception
and the calculation is done in software instead, which
takes lots of CPU.

But this should not happen if the volume is exactly
zero, but when it is very close to it.

Anyway you should use somehting like

if (volume < 1e-10f) volume = 0;
for ( )
{
}

or even better:

if (volume < 1e-10f)
{
memset (pBuffer, 0, nframes * sizeof (float));
}
else
{
for () // etc.
}

If you still have this problem with the volume set
to exactly zero, then it is created not in the code
you've shown but by later parts of your processing.

Ciao,


-- 
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] is this a compiler issue??

[Tim Goetze]

[Conrad Berhörster]
>On Wednesday 19 August 2009 12:37:36 Tim Goetze wrote:
>>
>> It'd be a lot more helpful to see the full source but from what you're
>> writing I'd be willing to bet you're encountering denormals.
>
>geeh, good point. So there is no opponent in betting with you ;=) 
>
>anyway, as i have a quick read of http://ardour.org/node/139, my code with the 
>if wasn't a workaround, it is the solution, as long as the CPU isn't a SSE, 
>right?

Again, that is awfully hard to tell without seeing the full source. ;)

If you're coding for public consumption, it's probably better to 
provide a CPU-agnostic solution anyway.  That'll be either flushing 
very small values to zero "by hand" or injecting inaudible noise.

Cheers, Tim___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] is this a compiler issue??

[Conrad Berhörster]

Hello Tim, 

On Wednesday 19 August 2009 15:48:58 Tim Goetze wrote:
> [Conrad Berhörster]
>
> >On Wednesday 19 August 2009 12:37:36 Tim Goetze wrote:
> >> It'd be a lot more helpful to see the full source but from what you're
> >> writing I'd be willing to bet you're encountering denormals.
> >
> >geeh, good point. So there is no opponent in betting with you ;=)
> >
> >anyway, as i have a quick read of http://ardour.org/node/139, my code with
> > the if wasn't a workaround, it is the solution, as long as the CPU isn't
> > a SSE, right?
>
> Again, that is awfully hard to tell without seeing the full source. ;)
i have used the afternoon to do some testing and reviewing my code.  
Additionally i have read some things about denormals and SSE. It seems, that 
the Problem only obtain on the AMD processor, which is a different machine as 
my developing machine.  

I try to understand the code, Jens had send. I found out, that it isn't the 
volume parameter - it happened when i use only  the sample at standard volume. 

to be continued... 

thanks c~


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] Auto-wah plugin

[hollunder]

On Tue, 18 Aug 2009 15:13:36 +0100 (BST)
"james morris"  wrote:

> 
> On 17/8/2009, "Fons Adriaensen"  wrote:
> 
> >hi all,
> >
> >In between smashing flies that came sitting on my hands while
> >typing, and taking cold showers (we have some heath wave here)
> >I wrote an auto-wah LADSPA plugin. It's available from the
> >usual place:
> >
> >
> >Since I'm not a guitarist I'll need user feedback to improve it.
> >
> >Enjoy !
> 
> Hi Fons,
> 
> Just curious, why did you not write an LV2 plugin?
> 
> And err, the URL does not work :(
> 
> James.

This is because there's already a new version:
http://www.kokkinizita.net/linuxaudio/downloads/WAH-plugins-0.0.2.tar.bz2

Philipp
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] is this a compiler issue??

[Chris Cannam]

On Wed, Aug 19, 2009 at 4:42 PM, Conrad
Berhörster wrote:
> Additionally i have read some things about denormals and SSE. It seems, that
> the Problem only obtain on the AMD processor

My impression was that Intel CPUs slow down more than AMDs for
denormal handling. But my experience is quite limited, my memory is
not always the best, and I haven't had an AMD for a few years. Am I
wrong?


Chris
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] is this a compiler issue??

[Conrad Berhörster]

Hello Fons, 

On Wednesday 19 August 2009 14:34:45 Fons Adriaensen wrote:
>
> if (volume < 1e-10f)
> {
> memset (pBuffer, 0, nframes * sizeof (float));
> }
> else
> {
> for () // etc.
> }
this is a cool trick to save some CPU. thanks for that hint. 

>
> If you still have this problem with the volume set
> to exactly zero, then it is created not in the code
> you've shown but by later parts of your processing.
>

the rest i will answer in a forthcoming mail very soon. 

bye c~

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] is this a compiler issue??

[Jens M Andreasen]

On Wed, 2009-08-19 at 17:42 +0200, Conrad Berhörster wrote:

> I try to understand the code, Jens had send. I found out, that it
> isn't the volume parameter - it happened when i use only the sample at
> standard volume. 
> 

Oh, sorry:

-8<--
 MAN static int  set_DAZ_and_FTZ(int /*bool*/ on);

 When called with a non-zero argument at program start, kills bugs dead
 arising from denormals by telling the processor to ignore them at best 
 of its ability.

 Returns: SSE level on success, or zero if processor is very old.

 Caveats: Intel architecture only.

  


> 
> 
> to be continued... 
> 
> 
> 
> thanks c~
> 
> 
> 
> 
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev