Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7535 discussions

by Stéphane Letz

> > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 25 Jul 2011 12:04:06 +0200 > From: Maurizio De Cecco <jmax(a)dececco.name> > Subject: Re: [LAD] GCC Vector extensions > Cc: linux-audio-dev(a)lists.linuxaudio.org > Message-ID: <4E2D3F96.2010206(a)dececco.name> > Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" > > Short resume of my initial post: i found that using the gcc vector > extensions induced a 2x slow down using gcc, and a 4x speed up in clang. > > I made more tests, isolating a small code example, on Mac OS and Ubuntu, > and i found out the origin of the problem, even if i do not know what > exactly happening. > > My original test used vectors of float of size 8; the gcc vector > extension documentation says that if the vector size do not match the > hardware vector size, the code is synthesized in some way. > > With a vector size of 8 i found the above results under Mac OS X, using > clang and gcc4.2, and under Ubuntu 11.04, using clang and gcc4.5.2. > > When i move to a vector size of 4, things go better; clang slow down wrt > the size of 8 of around 2x, and gcc obtains the same result; the > interesting point is that gcc obtains essentially the same speed with > and without vector extensions, meaning probably that the compiler is > good enough in vectorizing the code, at least in the the test cases i used. > > I include the code, results and scripts to run the tests in a small zip > if anybody want to make other tests; the test code compute an arbitrary > vector computation (essentially 100 million multiply add), starting from > a seed given as argument. > > The code is modeled around the way jmax compute, i.e. one vector > operation at a time on vectors passed by pointers, and it is not > designed to be the fastest possible code to implements this computation. > > Thanks for the help, > > Maurizio You should really give the produced assembly code in each test case. Stephane

14 years, 6 months

[LAD] [LAA] [ANN] release gxtuner-1.0

by hermann

Hello I like to announce the first release of gxtuner, a simple, small and lightweight guitar/bass tuner for jack. gxtuner comes with a analogue like interface (scale), show the tune (char) and the accumulated frequency (Hz) and is licensed under the GPL. It's a break out of the guitarix tuner module, you can download it here: http://sourceforge.net/projects/guitarix/files/gxtuner/gxtuner-1.0.tar.bz2/… have fun hermann

14 years, 6 months

[LAD] remove snd dummy

by Christoph Kuhr

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi list, i compiled the alsa sources with the dummy otion, now finished using it, how do i get rid of it? i tried to compile the sources without the dummy otion, but it didnt work. (perhapes with an ice1724 option?) i completley removed the alsa packages and reinstalled them without any effort. lsmod doesnt show any snd module... im using natty with lowlatency kernel (11.04 + 2.6.38lowlatency) and an ice1724 chip thanks in advance regards Ck - -- PGP Key ID 0x528422c1; PGP Public Key / PGP Key verification: pgp.mit.edu pgp.zdv.uni-mainz.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOJ/OKAAoJEBra75lShCLBUgoIALVE0FCz+VCgAr4XelbbMENV w355Ckvhu0oYAtx2fGqcbKZoFM2IDnXCC7RXXsiX+EyYv9kAy/E5fRFcYbzXN6Kp Qgt08nUJvdrX2GlVeuWpvCDYP4RY8cjhk0lHyWFIKc88jKCvB/OB+LvPTQPdcN++ 85FEeS6mYGZJupIy2mMLFivLIYH0jdG8VMb4B+fxchBMCNMqfPRCYilK0uC6RwZ5 2gFdS2rb/MTj3lC5r2cU10x6zM9tB4CpnGz11mleN9RlKA2EtV/myKDBn58TXcUq tNDLMeqyahH5JB1ACKMuBA4iYEs+z65ASaH/0bU1BgSSEVoaACKmtykRkequ6cQ= =HJAx -----END PGP SIGNATURE-----

14 years, 6 months

[LAD] Alan Ernest "Cal" Calvert dies at 61

by Gabriel Beddingfield

Friends: Cal, the lead developer of Yoshimi, passed away on July 2 in Victoria, Australia. http://tributes.couriermail.com.au/obituaries/couriermail-au/obituary.aspx?… While this was not unexpected, we're all very sad to see him go. I'm doubt that his family has any idea what he meant to us. If anyone has an idea on how we can show our appreciation, please share it. -gabriel

14 years, 6 months

[LAD] Sad News

by Folderol

We lost 'Cal', the developer of Yoshimi on the second of July. http://tributes.couriermail.com.au/obituaries/couriermail-au/obituary.aspx?… He had been fighting cancer for several years. -- Will J Godfrey http://www.musically.me.uk Say you have a poem and I have a tune. Exchange them and we can both have a poem, a tune, and a song.

14 years, 6 months

[LAD] lv2 extension bugs

by Lieven Moors

Just a quick question. Is there a bug tracker for lv2 extensions? Couldn't find it... greetings, lieven

14 years, 6 months

[LAD] A couple of requests to some who posted new projects in LAA

by Michael Bechard

Sorry for the general-purpose nature of this post, but a couple of new posts in LAA recently piqued my interest, but I am unable to find out how to contact those developers directly with my inquiries/suggestions, so here goes (I tried posting replies in LAA, but no luck): RE: Grainmap v0.1 I'm interested in compiling and using this, but it requires gtkmm v3.0. I know at least the latest Ubuntu stable release doesn't have that version, so I was curious why the dependency on such a recent version of gtkmm? RE: spectmorph v0.2.0 I'm interested in compiling and using this as well, but there's a dependency on BSE v.7.2. All I want to compile is the Jack client app, so I don't see why this dependency is needed. I looked over the Makefile but couldn't find a target for just the jack client (very possible I just missed it though). Thanks, Michael Bechard

14 years, 6 months

[LAD] [ANN] FAUST 0.9.43 released

by Orlarey Yann

GRAME - Centre National de Creation Musicale - is happy to announce the release of FAUST 0.9.43, a programming language specifically designed to develop audio plugins and applications. This version provides a major reorganization of the architecture system for better modularity and Open Sound Control (OSC) support. The code generation has been improved and the compiler offers new output possibilities for example the complete graph of the internal signal expressions as a .dot (graphviz) file. The libraries and the examples have been extended: Julius Smith's libraries provides several new filters and effects (including various reverbs) and Romain Michon has ported the Synthesis Tool Kit (STK) to FAUST. ------------- About FAUST : ------------- FAUST (Functional Audio Stream) is a functional programming language specifically designed for real-time signal processing and synthesis. A distinctive characteristic of FAUST is to be fully compiled. The FAUST compiler translates DSP specifications into very efficient C++ code that works at sample level. It targets high-performance signal processing applications, libraries and audio plug-ins for a variety of audio platforms and standards. A same FAUST specification can be used to easily generate native JACK or ALSA applications, as well as CSOUND, LADSPA, MAX/MSP, PD, Q, SC and VST plugins. The Faust distribution can be downloaded at: http://sourceforge.net/projects/faudiostream The GIT repository can be cloned with the following command : git clone git://faudiostream.git.sourceforge.net/gitroot/faudiostream/faudiostream faust Two mailing lists are available: https://lists.sourceforge.net/lists/listinfo/faudiostream-devel https://lists.sourceforge.net/lists/listinfo/faudiostream-users In order to test FAUST without installing it, please refer to the Online Faust Compiler (requires firefox): http://faust.grame.fr ======================== WHAT'S NEW ============================== ---------- Compiler : ---------- - Improved loop separation algorithm - Improved SVG block-diagrams (useless cables removed, inverters, etc.) - Better handling of search path and default directories - Range of input audio signals widened to (-inf,+inf). - New -cn <name> (or --class-name <name>). It allows to specify the name of the dsp class to be used instead of mydsp - New -sg (--signal-graph) option to draw a graph of all internal signal expressions as a .dot (graphviz) file. - Several bug correction in type system and faster type system inference algorithm ----------- Libraries : ----------- - effects.lib : - new moog VCF implementation - auto-wah effect - passive non-linear allpass filters - several new reverbs implementations based on feedback delay networks including Zita Rev1 - square Rectangular Digital Waveguide Mesh - filter.lib : - new ladder/lattice allpass filters - Regalia-Mitra second order peaking equalizer section ---------- Examples : ---------- - several new reverb examples - Synthesis Tool Kit (STK) with many examples ported to Faust: WIND INSTRUMENTS - A simple clarinet (clarinet.dsp), - A clarinet with a tone hole model (blowHole.dsp), - A flute (flutestk.dsp), - A pan-flute (flute.dsp), - A brass instrument that can be used as a trumpet, a trombon, a french horn, etc. (brass.dsp), - A simple saxophone (saxophony.dsp), - A bottle where it is possible to blow threw the neck to make sound (blowBotle.dsp). STRING INSTRUMENTS - An acoustic finger bass (bass.dsp), - A bowed string instrument that can be used as a cello, a violin, etc. (bowed.dsp), - A simple sitar (sitar.dsp), - A nonlinear extended Karplus-Strong (NLFeks.dsp). KEYBOARDS INSTRUMENTS - A piano that uses commuted waveguide synthesis (piano.dsp), - An harpsichord (harpsi.dsp). PERCUSSION INSTRUMENTS - A tibetan bowl (tibetanBowl.dsp), - A wooden bare (uniBar.dsp), - An iron bare (tunedBar.dsp), - A glass bare (glassHarmonica.dsp), - A set of percussion instruments that use modal synthesis (modalBar.dsp). OTHER - A voice synthesizer (voiceForm.dsp), - A FM synthesizer that uses an nonlinear allpass filter (NLFfm.dsp). ---------- Tools : ---------- - faust2ladspa - faust2dssi - faust2supercollider - faust2sig - faust2sigviewer -------------------- Architecture files : -------------------- - Redesign of architecture files for better modularity. - Open Sound Control (OSC) support added to several architecture files. - Knobs added to GTK architectures - Architecture's licenses updated - Improved file format to save and restore applications settings - Revised Core Audio architecture - DSSI architecture added - netjack architecture allowing remote audio processing over LAN - AVOIDDENORMALS support added for puredata, ladspa and other plugins - support for group tooltip via new declare(0, ...) mechanism ---------------- Acknowledgments: ---------------- Many persons have been contributing to the FAUST project by providing code for the compiler, architecture files, libraries, examples, documentation, scripts, bug reports, ideas, etc. I would like to thank them and especially: Fons Adriaensen, Tim Blechmann, Tiziano Bole, Baktery Chanka, Thomas Charbonnel, Damien Cramet, Etienne Gaudrin, Albert Graef, Stefan Kersten, Victor Lazzarini, Matthieu Leberre, Mathieu Leroi, Kjetil Matheussen, Hermann Meyer, Remy Muller, Sampo Savolainen, Nicolas Scaringella, Stephen Sinclair, Travis Skare, Julius Smith, Michael Wilson, as well as my colleagues at GRAME, in particular : Dominique Fober, Stephane Letz and Romain Michon, and from the ASTREE project : Karim Barkati (IRCAM), Jerome Barthelemy (IRCAM), Alain Bonardi (IRCAM), Raffaele Ciavarella (IRCAM), Pierre Jouvelot (Mines/ParisTech), Alexander Mihalic (U. Saint-Etienne), Laurent Pottier (U. Saint-Etienne) Yann Orlarey GRAME

14 years, 6 months

Re: [LAD] GCC Vector extensions

by Stéphane Letz

> > On 07/20/2011 10:27 AM, Maurizio De Cecco wrote: >> I am playing around with GCC and Clang vector extensions, on Linux and >> Mac OS X, and i am getting some strange behaviour. >> >> I am working on jMax Phoenix, and its dsp engine, in its current state, >> is very memory bound; it is based on the aggregation of very small >> granularity operations, like vector sum or multiply, each of them >> executed independently from and to memory. >> >> I tried to implements all this 'primitive' operations using the vector >> types. >> >> On clang/MacOSX i get an impressive improvement in performance, >> around 4x on the operations, even just using the vector types for >> copying data; my impression is that the compiler use some kind of vector >> load/store instruction that properly use the available memory bandwidth, >> but unfortunately i do not know more about the x86 architecture. >> >> On gcc/Linux, (gcc 4.5.2) the same code produce a *slow down* of around >> 2.5x. >> >> Well, anybody have an idea of why ? >> >> I am actually running linux (Ubuntu 11.04) under a VMWare virtual >> machine, i do not know is this may have any implications. > > Maybe. A better comparison would be: clang/Linux vs. gcc/Linux and > clang/MacOSX vs gcc/MacOSX compiled binaries. > > Also as Dan already pointed out: gcc has a whole lot of optimization > flags which are not enabled by default. try '-O3 -msse2 -ffast-math'. > '-ftree-vectorizer-verbose=2' is handy while optimizing code. > > have fun, > robin Or you can use LLVM to *directly* generate vector code, as in the following example, result of some experiments done with Faust and it's LLVM backend: block_code8: ; preds = %block_code8.block_code8_crit_edge, %block_code3 %20 = phi float* [ %15, %block_code3 ], [ %.pre11, %block_code8.block_code8_crit_edge ] %21 = phi float* [ %14, %block_code3 ], [ %.pre10, %block_code8.block_code8_crit_edge ] %22 = phi float* [ %16, %block_code3 ], [ %.pre9, %block_code8.block_code8_crit_edge ] %indvar = phi i32 [ 0, %block_code3 ], [ %indvar.next, %block_code8.block_code8_crit_edge ] %nextindex1 = shl i32 %indvar, 2 %nextindex = add i32 %nextindex1, 4 %23 = sext i32 %nextindex1 to i64 %24 = getelementptr float* %22, i64 %23 %25 = getelementptr float* %21, i64 %23 %26 = bitcast float* %25 to <4 x float>* %27 = load <4 x float>* %26, align 1 %28 = getelementptr float* %20, i64 %23 %29 = bitcast float* %28 to <4 x float>* %30 = load <4 x float>* %29, align 1 %31 = fadd <4 x float> %27, %30 %32 = bitcast float* %24 to <4 x float>* store <4 x float> %31, <4 x float>* %32, align 1 %33 = icmp ult i32 %nextindex, %18 br i1 %33, label %block_code8.block_code8_crit_edge, label %exit_block6 In this block float* arrays are loaded, then "bitcast" in vector of 4 floats, the vector of 4 float is loaded, then manipulated with LLVM IR vector version of add, mult...etc... then stored. The LLVM IR is still generated to use the "conservative" "align 1" option since it can not yet be sure data is always aligned. The result SSE code with then use the MOVUPS (Move Unaligned Packed Single-Precision Floating-Point Values). The next steps is to generated stuff like: %27 = load <4 x float>* %26, align 4 so that MOVAPS (Move Aligned Packed Single-Precision Floating-Point Values) is used instead. We already see so nice speed improvements, but the Faust vector LLVM backend version is still not yet complete... Stéphane

14 years, 6 months

[LAD] realtime kernel based on linux-3.0-rc7

by Robin Gareus

For all here who don't follow the kernel lists.. Thomas Gleixner has announced a new version of the real-time patch: https://lkml.org/lkml/2011/7/19/309 Even though most of the pro-audio-relevant preemt-rt patches are already mainline since 2.6.39, this is still very interesting mostly because: > What's new in 3.0-rt ? > > - No more split soft interrupt threads. We need to analyze whether > this is a good decision. > > - softirq handling from the end of interrupt threads and on all > thread sites where a nested local_bh disabled section ends > ... ..and this latency plot is stunning: https://www.osadl.org/Latency-plot-of-system-in-rack-4-slot.qa-latencyplot-… enjoy, robin

14 years, 6 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev