[music-dsp] Intelligent Systems for Audio-based Monitoring Workshop@EANN 2017 in Athens, Greece

2017-03-10 Thread Stavros Ntalampiras 
[please distribute - apologies for multiple postings]


*ISAM 2017**: 1**st** Workshop on Intelligent Systems for Audio-based
Monitoring*
*25-27 August 2017, Athens, Greece*

*https://sites.google.com/site/workshopisam2017/*

*https://conferences.cwa.gr/eann2017/*


***

*Important dates *
Paper submission: *April 20th, 2017 *
Notification of paper acceptance: *May 13th, 2017 *
Camera-ready submission (CCIS): *May 23rd, 2017 *
Early registration: *May 27th, 2017*
Conference Dates: *25-27 August, 2017 *
***

In the recent years, the ever-increasing need in applications depending on
generalized sound recognition technologies has attracted the interest of
the audio processing community. Such applications involve a wide variety of
audio signals ranging from speech, music, and animal vocalizations to
generalized audio events. Hence, it is of paramount importance for the
scientific community to develop novel computational methods for audio
analysis. The main aim of this workshop is to bring together researchers
working in the general field of audio analysis and present their recent
advancements.

*Potential topics include, but are not limited to:*

   - Computational auditory scene analysis Sound event detection and
   recognition
   - Audio source separation and localization
   - Audio-based security systems and surveillance
   - Threats/hazards detection using audio information
   - Security applications and interfaces using audio information
   - Transfer and reinforcement learning for audio signal processing
   - Music information retrieval
   - Biodiversity and environmental monitoring
   - Deep learning for audio applications
   - Methodologies, algorithms and techniques for learning in evolving
   auditory environments
   - Audio for mobile and handheld devices
   - Audio in education Acoustic data processing for the Internet of Things
   and emerging applications
   - Emerging audio technologies (auditory display, interactive sound, and
   new audio interfaces)
   - Wireless acoustic sensor networks and applications
   - Distributed audio signal processing and coding for segmentation, event
   detection and alerting.


*Program chairs *
Stavros Ntalampiras, Politecnico di Milano, stavros.ntalampi...@polimi.it

Iosif Mporas, University of Hertfordshire, i.mpo...@herts.ac.uk
Nicolas-Alexander Tatlas, Piraeus University of Applied Sciences,
ntat...@teipir.gr
Alexandros Lazaridis, Idiap Research Institute, al...@idiap.ch

*All papers should be submitted either in a doc/docx or in a pdf form and
they will be peer reviewed by at least 2 academic referees. *
*Papers should not exceed 12 pages. Contributing authors must follow the **LNCS
Springer*
*
format
guidelines. *
*Papers should be submitted via the **easychair*
*
submission
platform. *


Accepted papers will be presented orally in the EANN 2017 conference and
will be published in a proceedings volume organised by the main EANN 2017
event by Springer in the CCIS "Communications in Computer and Information
Science" series.
Registration fees and benefits for the workshop’s participants are exactly
identical with the ones of the main EANN 2017 event.

*Extended versions of selected papers from the workshop will be peer
reviewed for potential publication in a set of special issues of
high-impact journals.



***
Dr.-Eng. Stavros Ntalampiras
Senior Research Fellow
Politecnico di Milano,
Department of Information, Electronics
and Bioengineering
***
https://sites.google.com/site/stavrosntalampiras/home
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

[music-dsp] 2 postdoc opportunities

2017-03-10 Thread Pierre Alexandre Tremblay 
Dear all

I'm new to this list, I have been recommended to post the following offers 
here. I've been successful in an ERC application and as part of the project, I 
am hiring 2 postdocs, both of which could be of interest to some of you who are 
almost done or just graduated PhDs?

The project is called Fluid Corpus Manipulation and has successfully secured 5 
years of ERC funding, which mean I am hiring 2 postdocs for that period. One is 
a DSP specialist with a strong interest in FFT-processes, the other is a 
practice-based researcher in creative coding, with a strong interest in 
dissemination.

Research Fellow in Real-Time Computer Music Systems - http://hud.ac/c5n

Research Fellow in Creative Coding Practice in Music - http://hud.ac/c5o

There is a temp website at flucoma.org, but most info is in the recruitment 
pack for each post above.

Feel free to pass along to anyone within your networks!

pa
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] IIR filter efficiency

2017-03-10 Thread Nigel Redmon 
Even cheaper—no need to get fancy with TPDF, since the level can be -300 dB or 
so :-D (I’ve done things as simply as toggle sign on 1e-15 once per block)

But watch out for highpass filters and add back in ;-)

> On Mar 10, 2017, at 1:10 AM, Richard Dobson  wrote:
> 
> This might not be possible if one is implementing e.g. a plugin to run in a 
> third-party host - where one does not have full control over the host, nor 
> indeed of fellow plugins. Whereas adding some ~very~ low level TPDF dither to 
> a signal should be close to minimum cost.
> 
> Richard Dobson
> 
> On 10/03/2017 08:29, Stefan Stenzel wrote:
>> That document is from 2002 - today all these suggestions make little
>> sense unless you want your code to run explicitly on a CPU without
>> SSE. The best strategy for avoiding denormals is to enforce the
>> compiler to use SSE and avoid the FPU, then set the
>> Denormals-Are-Zero (DAZ) and Flush-To-Zero (FTZ) flag in the SSE
>> status register.
>> 
>> Stefan
>> 

___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] denormals on ARM processors ?

2017-03-10 Thread Giulio Moro 
The functions here 
https://github.com/BelaPlatform/Bela/blob/master/core/math_runfast.c will allow 
to manipulate "fast" mode for ARM vfp (making it non-IEEE-754 compliant). If 
you are using the NEON SIMD (you should!) then it always flushes to zero (which 
is one of the reasons why NEON is non-compliant) 
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0473m/dom1359731193887.html
 .


  From: Philippe Wicker 
 To: music-dsp@music.columbia.edu 
 Sent: Friday, 10 March 2017, 9:00
 Subject: Re: [music-dsp] denormals on ARM processors ?
   
No code but some tips here:
https://developer.arm.com/docs/dui0801/latest/advanced-simd-programming/when-to-use-flush-to-zero-mode-in-advanced-simd

On 10 Mar 2017, at 09:51, Stéphane Letz  wrote:
Hin

Following the discussion on "IIR filter efficiency » about denormals, what is 
then situation regarding denormals on ARM processors? Is there  the equivalent 
of SSE _mm_setcsr stuff to force the process to switch in FTZ mode ? Any code 
to share to do the same on ARM?

Thanks.

Stéphane Letz
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

   ___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] IIR filter efficiency

2017-03-10 Thread Philippe Wicker 
Well, this is intended to be used on a system where many applications may run 
concurrently and therefore the need to not denormalise may not be universally 
shared. Some applications do want to allow computation on denormals in order to 
get a bit more precision in the result at the expense of a higher cpu cost.

> On 10 Mar 2017, at 10:43, Stefan Stenzel  
> wrote:
> 
> How about *not* calling RESTORE_DENORMALS as a courtesy for the rest of the 
> audio processing chain?
> 
>> On 10 Mar 2017, at 10:28 , Philippe Wicker  wrote:
>> 
>> Yes, it is done that way in the Apple AudioUnit SDK. The code calls 
>> DISABLE_DENORMALS at the beginning of the render routine, and 
>> RESTORE_DENORMALS at the end. Those macros call asm instruction stmxcsr and 
>> ldmxcsr (in AUBase.cpp: line 53).
>>> On 10 Mar 2017, at 10:17, Stefan Stenzel  
>>> wrote:
>>> 
>>> I don’t get it - what prevents you from checking/setting DAZ/FTZ in your 
>>> processing routine?
>>> 
>>> 
 On 10 Mar 2017, at 10:10 , Richard Dobson  wrote:
 
 This might not be possible if one is implementing e.g. a plugin to run in 
 a third-party host - where one does not have full control over the host, 
 nor indeed of fellow plugins. Whereas adding some ~very~ low level TPDF 
 dither to a signal should be close to minimum cost.
 
 Richard Dobson
 
 On 10/03/2017 08:29, Stefan Stenzel wrote:
> That document is from 2002 - today all these suggestions make little
> sense unless you want your code to run explicitly on a CPU without
> SSE. The best strategy for avoiding denormals is to enforce the
> compiler to use SSE and avoid the FPU, then set the
> Denormals-Are-Zero (DAZ) and Flush-To-Zero (FTZ) flag in the SSE
> status register.
> 
> Stefan
> 
> 
 ___
 dupswapdrop: music-dsp mailing list
 music-dsp@music.columbia.edu
 https://lists.columbia.edu/mailman/listinfo/music-dsp
 
>>> 
>>> ___
>>> dupswapdrop: music-dsp mailing list
>>> music-dsp@music.columbia.edu
>>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>> 
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>> https://lists.columbia.edu/mailman/listinfo/music-dsp
> 
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp

___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] IIR filter efficiency

2017-03-10 Thread Stefan Stenzel 
How about *not* calling RESTORE_DENORMALS as a courtesy for the rest of the 
audio processing chain?

> On 10 Mar 2017, at 10:28 , Philippe Wicker  wrote:
> 
> Yes, it is done that way in the Apple AudioUnit SDK. The code calls 
> DISABLE_DENORMALS at the beginning of the render routine, and 
> RESTORE_DENORMALS at the end. Those macros call asm instruction stmxcsr and 
> ldmxcsr (in AUBase.cpp: line 53).
>> On 10 Mar 2017, at 10:17, Stefan Stenzel  
>> wrote:
>> 
>> I don’t get it - what prevents you from checking/setting DAZ/FTZ in your 
>> processing routine?
>> 
>> 
>>> On 10 Mar 2017, at 10:10 , Richard Dobson  wrote:
>>> 
>>> This might not be possible if one is implementing e.g. a plugin to run in a 
>>> third-party host - where one does not have full control over the host, nor 
>>> indeed of fellow plugins. Whereas adding some ~very~ low level TPDF dither 
>>> to a signal should be close to minimum cost.
>>> 
>>> Richard Dobson
>>> 
>>> On 10/03/2017 08:29, Stefan Stenzel wrote:
 That document is from 2002 - today all these suggestions make little
 sense unless you want your code to run explicitly on a CPU without
 SSE. The best strategy for avoiding denormals is to enforce the
 compiler to use SSE and avoid the FPU, then set the
 Denormals-Are-Zero (DAZ) and Flush-To-Zero (FTZ) flag in the SSE
 status register.
 
 Stefan
 
 
>>> ___
>>> dupswapdrop: music-dsp mailing list
>>> music-dsp@music.columbia.edu
>>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>>> 
>> 
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>> https://lists.columbia.edu/mailman/listinfo/music-dsp
> 
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp

___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] IIR filter efficiency

2017-03-10 Thread Philippe Wicker 
Yes, it is done that way in the Apple AudioUnit SDK. The code calls 
DISABLE_DENORMALS at the beginning of the render routine, and RESTORE_DENORMALS 
at the end. Those macros call asm instruction stmxcsr and ldmxcsr (in 
AUBase.cpp: line 53).
> On 10 Mar 2017, at 10:17, Stefan Stenzel  
> wrote:
> 
> I don’t get it - what prevents you from checking/setting DAZ/FTZ in your 
> processing routine?
> 
> 
>> On 10 Mar 2017, at 10:10 , Richard Dobson  wrote:
>> 
>> This might not be possible if one is implementing e.g. a plugin to run in a 
>> third-party host - where one does not have full control over the host, nor 
>> indeed of fellow plugins. Whereas adding some ~very~ low level TPDF dither 
>> to a signal should be close to minimum cost.
>> 
>> Richard Dobson
>> 
>> On 10/03/2017 08:29, Stefan Stenzel wrote:
>>> That document is from 2002 - today all these suggestions make little
>>> sense unless you want your code to run explicitly on a CPU without
>>> SSE. The best strategy for avoiding denormals is to enforce the
>>> compiler to use SSE and avoid the FPU, then set the
>>> Denormals-Are-Zero (DAZ) and Flush-To-Zero (FTZ) flag in the SSE
>>> status register.
>>> 
>>> Stefan
>>> 
>>> 
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>> 
> 
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp

___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] IIR filter efficiency

2017-03-10 Thread Stefan Stenzel 
I don’t get it - what prevents you from checking/setting DAZ/FTZ in your 
processing routine?


> On 10 Mar 2017, at 10:10 , Richard Dobson  wrote:
> 
> This might not be possible if one is implementing e.g. a plugin to run in a 
> third-party host - where one does not have full control over the host, nor 
> indeed of fellow plugins. Whereas adding some ~very~ low level TPDF dither to 
> a signal should be close to minimum cost.
> 
> Richard Dobson
> 
> On 10/03/2017 08:29, Stefan Stenzel wrote:
>> That document is from 2002 - today all these suggestions make little
>> sense unless you want your code to run explicitly on a CPU without
>> SSE. The best strategy for avoiding denormals is to enforce the
>> compiler to use SSE and avoid the FPU, then set the
>> Denormals-Are-Zero (DAZ) and Flush-To-Zero (FTZ) flag in the SSE
>> status register.
>> 
>> Stefan
>> 
>> 
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
> 

___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] IIR filter efficiency

2017-03-10 Thread Richard Dobson 
This might not be possible if one is implementing e.g. a plugin to run 
in a third-party host - where one does not have full control over the 
host, nor indeed of fellow plugins. Whereas adding some ~very~ low level 
TPDF dither to a signal should be close to minimum cost.


Richard Dobson

On 10/03/2017 08:29, Stefan Stenzel wrote:

That document is from 2002 - today all these suggestions make little
sense unless you want your code to run explicitly on a CPU without
SSE. The best strategy for avoiding denormals is to enforce the
compiler to use SSE and avoid the FPU, then set the
Denormals-Are-Zero (DAZ) and Flush-To-Zero (FTZ) flag in the SSE
status register.

Stefan



___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] denormals on ARM processors ?

2017-03-10 Thread Philippe Wicker 
No code but some tips here:

https://developer.arm.com/docs/dui0801/latest/advanced-simd-programming/when-to-use-flush-to-zero-mode-in-advanced-simd
 


> On 10 Mar 2017, at 09:51, Stéphane Letz  wrote:
> 
> Hin
> 
> Following the discussion on "IIR filter efficiency » about denormals, what is 
> then situation regarding denormals on ARM processors? Is there  the 
> equivalent of SSE _mm_setcsr stuff to force the process to switch in FTZ mode 
> ? Any code to share to do the same on ARM?
> 
> Thanks.
> 
> Stéphane Letz
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp

___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

[music-dsp] denormals on ARM processors ?

2017-03-10 Thread Stéphane Letz 
Hin

Following the discussion on "IIR filter efficiency » about denormals, what is 
then situation regarding denormals on ARM processors? Is there  the equivalent 
of SSE _mm_setcsr stuff to force the process to switch in FTZ mode ? Any code 
to share to do the same on ARM?

Thanks.

Stéphane Letz
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] IIR filter efficiency

2017-03-10 Thread Michael Gogins 
Thanks,
Mike

On Mar 10, 2017 7:29 PM, "Stefan Stenzel" 
wrote:

> That document is from 2002 - today all these suggestions make little sense
> unless you want your code to run explicitly on a CPU without SSE.
> The best strategy for avoiding denormals is to enforce the compiler to use
> SSE and avoid the FPU, then set the Denormals-Are-Zero (DAZ) and
> Flush-To-Zero (FTZ) flag in the SSE status register.
>
> Stefan
>
>
>
> > On 10 Mar 2017, at 7:27 , Michael Gogins 
> wrote:
> >
> > Here is much more complete information:
> > http://www.musicdsp.org/files/denormal.pdf
> >
> > Hope this helps,
> > Mike
> >
> > -
> > Michael Gogins
> > Irreducible Productions
> > http://michaelgogins.tumblr.com
> > Michael dot Gogins at gmail dot com
> >
> >
> > On Fri, Mar 10, 2017 at 5:06 PM, Evan Balster  wrote:
> >> Hey, Stephen —
> >>
> >> For best performance, I recommend following Michael's suggestion about
> >> adding some noise to the waveform.  Or use platform-dependent
> techniques to
> >> enable flush-to-zero on the CPU.  Conditionally flushing works, but it
> takes
> >> up cycles — and with filters you often want as much performance as you
> can
> >> get!
> >>
> >> – Evan Balster
> >> creator of imitone
> >>
> >> On Thu, Mar 9, 2017 at 11:11 PM, ChordWizard Software
> >>  wrote:
> >>>
> >>> Hi Michael,
> >>>
> >>> Many thanks, denormal numbers it was.
> >>>
> >>> I have now added a check after each filter calculation point that
> flushes
> >>> small numbers to zero.
> >>>
> >>> With this extra step, the filter now consumes about 30% less time than
> the
> >>> rendering phase, instead of 800% more!
> >>>
> >>> I never knew about this, looks like a real trap, for very little
> benefit.
> >>> If people are looking to squeeze out a few more digits of precision or
> >>> exponent limit, surely the sensible thing is to switch to doubles?
> >>>
> >>> There doesn't seem to be any consistent way to switch this annoying
> >>> "feature" off in standard C++, but at least I am forewarned now, and
> the
> >>> performance benefit hugely outweighs the cost of my messy little hack
> to
> >>> circumvent it.
> >>>
> >>> Thanks for the quick and insightful advice.
> >>>
> >>> Regards,
> >>>
> >>> Stephen Clarke
> >>> Managing Director
> >>> ChordWizard Software Pty Ltd
> >>> corpor...@chordwizard.com
> >>> http://www.chordwizard.com
> >>> ph: (+61) 2 4960 9520
> >>>
> >>>
> >>> ___
> >>> dupswapdrop: music-dsp mailing list
> >>> music-dsp@music.columbia.edu
> >>> https://lists.columbia.edu/mailman/listinfo/music-dsp
> >>>
> >>
> >>
> >> ___
> >> dupswapdrop: music-dsp mailing list
> >> music-dsp@music.columbia.edu
> >> https://lists.columbia.edu/mailman/listinfo/music-dsp
> > ___
> > dupswapdrop: music-dsp mailing list
> > music-dsp@music.columbia.edu
> > https://lists.columbia.edu/mailman/listinfo/music-dsp
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] IIR filter efficiency

2017-03-10 Thread Philippe Wicker 
That’s true. I’ve not been working with the windows compilers since a long time 
but I remember that it wasn’t possible to be 100% sure that the compiler uses 
only SSE instructions. What I’ve been said is that the compiler could always 
decide to mix scalar (i.e. use the FP unit) and the vectored one (SSE). 

Maybe it’s not true anymore?

Phil

Oh, and sorry for the empty message that I mistakenly sent to the list...

> On 10 Mar 2017, at 09:29, Stefan Stenzel  
> wrote:
> 
> That document is from 2002 - today all these suggestions make little sense 
> unless you want your code to run explicitly on a CPU without SSE.
> The best strategy for avoiding denormals is to enforce the compiler to use 
> SSE and avoid the FPU, then set the Denormals-Are-Zero (DAZ) and 
> Flush-To-Zero (FTZ) flag in the SSE status register.
> 
> Stefan
> 
> 
> 
>> On 10 Mar 2017, at 7:27 , Michael Gogins  wrote:
>> 
>> Here is much more complete information:
>> http://www.musicdsp.org/files/denormal.pdf
>> 
>> Hope this helps,
>> Mike
>> 
>> -
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>> 
>> 
>> On Fri, Mar 10, 2017 at 5:06 PM, Evan Balster  wrote:
>>> Hey, Stephen —
>>> 
>>> For best performance, I recommend following Michael's suggestion about
>>> adding some noise to the waveform.  Or use platform-dependent techniques to
>>> enable flush-to-zero on the CPU.  Conditionally flushing works, but it takes
>>> up cycles — and with filters you often want as much performance as you can
>>> get!
>>> 
>>> – Evan Balster
>>> creator of imitone
>>> 
>>> On Thu, Mar 9, 2017 at 11:11 PM, ChordWizard Software
>>>  wrote:
 
 Hi Michael,
 
 Many thanks, denormal numbers it was.
 
 I have now added a check after each filter calculation point that flushes
 small numbers to zero.
 
 With this extra step, the filter now consumes about 30% less time than the
 rendering phase, instead of 800% more!
 
 I never knew about this, looks like a real trap, for very little benefit.
 If people are looking to squeeze out a few more digits of precision or
 exponent limit, surely the sensible thing is to switch to doubles?
 
 There doesn't seem to be any consistent way to switch this annoying
 "feature" off in standard C++, but at least I am forewarned now, and the
 performance benefit hugely outweighs the cost of my messy little hack to
 circumvent it.
 
 Thanks for the quick and insightful advice.
 
 Regards,
 
 Stephen Clarke
 Managing Director
 ChordWizard Software Pty Ltd
 corpor...@chordwizard.com
 http://www.chordwizard.com
 ph: (+61) 2 4960 9520
 
 
 ___
 dupswapdrop: music-dsp mailing list
 music-dsp@music.columbia.edu
 https://lists.columbia.edu/mailman/listinfo/music-dsp
 
>>> 
>>> 
>>> ___
>>> dupswapdrop: music-dsp mailing list
>>> music-dsp@music.columbia.edu
>>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>> https://lists.columbia.edu/mailman/listinfo/music-dsp
> 
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp

___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] IIR filter efficiency

2017-03-10 Thread Philippe Wicker 

> On 10 Mar 2017, at 09:29, Stefan Stenzel  
> wrote:
> 
> That document is from 2002 - today all these suggestions make little sense 
> unless you want your code to run explicitly on a CPU without SSE.
> The best strategy for avoiding denormals is to enforce the compiler to use 
> SSE and avoid the FPU, then set the Denormals-Are-Zero (DAZ) and 
> Flush-To-Zero (FTZ) flag in the SSE status register.
> 
> Stefan
> 
> 
> 
>> On 10 Mar 2017, at 7:27 , Michael Gogins  wrote:
>> 
>> Here is much more complete information:
>> http://www.musicdsp.org/files/denormal.pdf
>> 
>> Hope this helps,
>> Mike
>> 
>> -
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>> 
>> 
>> On Fri, Mar 10, 2017 at 5:06 PM, Evan Balster  wrote:
>>> Hey, Stephen —
>>> 
>>> For best performance, I recommend following Michael's suggestion about
>>> adding some noise to the waveform.  Or use platform-dependent techniques to
>>> enable flush-to-zero on the CPU.  Conditionally flushing works, but it takes
>>> up cycles — and with filters you often want as much performance as you can
>>> get!
>>> 
>>> – Evan Balster
>>> creator of imitone
>>> 
>>> On Thu, Mar 9, 2017 at 11:11 PM, ChordWizard Software
>>>  wrote:
 
 Hi Michael,
 
 Many thanks, denormal numbers it was.
 
 I have now added a check after each filter calculation point that flushes
 small numbers to zero.
 
 With this extra step, the filter now consumes about 30% less time than the
 rendering phase, instead of 800% more!
 
 I never knew about this, looks like a real trap, for very little benefit.
 If people are looking to squeeze out a few more digits of precision or
 exponent limit, surely the sensible thing is to switch to doubles?
 
 There doesn't seem to be any consistent way to switch this annoying
 "feature" off in standard C++, but at least I am forewarned now, and the
 performance benefit hugely outweighs the cost of my messy little hack to
 circumvent it.
 
 Thanks for the quick and insightful advice.
 
 Regards,
 
 Stephen Clarke
 Managing Director
 ChordWizard Software Pty Ltd
 corpor...@chordwizard.com
 http://www.chordwizard.com
 ph: (+61) 2 4960 9520
 
 
 ___
 dupswapdrop: music-dsp mailing list
 music-dsp@music.columbia.edu
 https://lists.columbia.edu/mailman/listinfo/music-dsp
 
>>> 
>>> 
>>> ___
>>> dupswapdrop: music-dsp mailing list
>>> music-dsp@music.columbia.edu
>>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>> https://lists.columbia.edu/mailman/listinfo/music-dsp
> 
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp

___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] IIR filter efficiency

2017-03-10 Thread Stefan Stenzel 
That document is from 2002 - today all these suggestions make little sense 
unless you want your code to run explicitly on a CPU without SSE.
The best strategy for avoiding denormals is to enforce the compiler to use SSE 
and avoid the FPU, then set the Denormals-Are-Zero (DAZ) and Flush-To-Zero 
(FTZ) flag in the SSE status register.

Stefan



> On 10 Mar 2017, at 7:27 , Michael Gogins  wrote:
> 
> Here is much more complete information:
> http://www.musicdsp.org/files/denormal.pdf
> 
> Hope this helps,
> Mike
> 
> -
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
> 
> 
> On Fri, Mar 10, 2017 at 5:06 PM, Evan Balster  wrote:
>> Hey, Stephen —
>> 
>> For best performance, I recommend following Michael's suggestion about
>> adding some noise to the waveform.  Or use platform-dependent techniques to
>> enable flush-to-zero on the CPU.  Conditionally flushing works, but it takes
>> up cycles — and with filters you often want as much performance as you can
>> get!
>> 
>> – Evan Balster
>> creator of imitone
>> 
>> On Thu, Mar 9, 2017 at 11:11 PM, ChordWizard Software
>>  wrote:
>>> 
>>> Hi Michael,
>>> 
>>> Many thanks, denormal numbers it was.
>>> 
>>> I have now added a check after each filter calculation point that flushes
>>> small numbers to zero.
>>> 
>>> With this extra step, the filter now consumes about 30% less time than the
>>> rendering phase, instead of 800% more!
>>> 
>>> I never knew about this, looks like a real trap, for very little benefit.
>>> If people are looking to squeeze out a few more digits of precision or
>>> exponent limit, surely the sensible thing is to switch to doubles?
>>> 
>>> There doesn't seem to be any consistent way to switch this annoying
>>> "feature" off in standard C++, but at least I am forewarned now, and the
>>> performance benefit hugely outweighs the cost of my messy little hack to
>>> circumvent it.
>>> 
>>> Thanks for the quick and insightful advice.
>>> 
>>> Regards,
>>> 
>>> Stephen Clarke
>>> Managing Director
>>> ChordWizard Software Pty Ltd
>>> corpor...@chordwizard.com
>>> http://www.chordwizard.com
>>> ph: (+61) 2 4960 9520
>>> 
>>> 
>>> ___
>>> dupswapdrop: music-dsp mailing list
>>> music-dsp@music.columbia.edu
>>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>>> 
>> 
>> 
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>> https://lists.columbia.edu/mailman/listinfo/music-dsp
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp

___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp