Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7516 discussions

Re: [LAD] Project proposition: llvm based dsp engine

by Stéphane Letz

> > > Message: 3 > Date: Mon, 06 Dec 2010 14:11:07 +0100 > From: Maurizio De Cecco <jmax(a)dececco.name> > Subject: Re: [LAD] Project proposition: llvm based dsp engine > To: Paul Davis <paul(a)linuxaudiosystems.com> > Cc: The Linux Audio Developers' Mailing List > <linux-audio-dev(a)lists.linuxaudio.org>, llvmdev(a)cs.uiuc.edu > Message-ID: <1291641067-065c11f3c738513db43420e758ad7e5d(a)dececco.name> > Content-Type: text/plain; charset="iso-8859-1" > > Hi, and thanks for the feedback. > >> My own gut feeling on this is that you'd be better off figuring out >> how to do this in the context of Faust, which already does a important >> subset of what you are describing, though notably without (I think) >> the LLVM part. > > Surely a contribution to the discussion by the Faust people would > be welcome; and even more than to the discussion :->. By the way, they > do something with LLVM, but i do not know exactly what (Faust is included > in the list of projects using LLVM). > > I think the interest, if any, would be in having a *low* level > library generic enough to be used by multiple applications, so > to factor the work. It may be that an existing project have internally > a large part of the needed code, though. > >> Note also that hosts which run plugins at the level of LADSPA/LV2, >> VST, AU, DSSI etc are unlikely to be easy candidates for any >> cross-plugin optimization. > > I was actually talking about two different context, reusing existing > binaries, and having cross plugin optimisations for native plugins. > > But, if the plugins are compiled with a different compilation chain > (using the LLVM compiler producing LLVM byte code, so introducing a different > binary format for them), than cross plugin optimisation is possible also for > existing plugins like a LADSPA plugin. > > Would that be worthwhile ? Difficult to know for sure, but it is an interesting > subject to explore. > > Maurizio > I'm quite dubious of any real optimization you would achieve with this kind of approach, using LLVM. AFAIKS LLVM link time optimization allows some kind of inter module inlining or possibly constant propagation (see http://llvm.org/docs/LinkTimeOptimization.html) but I am not sure it would help a lot in our domain. Again staying in the imperative world makes things much more complicated... go functional! Stéphane PS: BTW LLVM is a really nice tool and very interesting things can be done with it, like using LLVM bitcode format as an interchange format for different architectures and using the JIT for dynamic compilation. We can already do that with Faust LLVM backend where we can generate a bitcode binary, then load it and JIT with a generic "LLVM faust plug-in" loader. This would allow the same bitcode object to be produced by the Faust online compiler for instance and be executed on any target machine.

14 years, 11 months

L2Ork seeking additional performance opportunities in Berlin and Paris

by Ivica Ico Bukvic

Apologies for cross-posting. Linux Laptop Orchestra or (L2Ork) is currently in the final stages of planning its debut European tour. While most venues have been already arranged for we are currently in the process of seeking additional performance opportunities in Paris, France as well as Berlin, Germany. Our target dates are May 17-31, 2011 with anticipated stops in Ljubljana, Budapest, Linz, Berlin, Hamburg, Utrecht, Amsterdam, Paris, and Birmingham. If anyone is aware of potential venues in Paris and Berlin and/or contacts that may be able to point us in the right direction, I would greatly appreciate it if you would please email me at your earliest convenience. For additional info on L2Ork please visit http://l2ork.music.vt.edu/main/ Thank you very much! Best wishes, Ivica Ico Bukvic, D.M.A. Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Co-Director, CCTAD CHCI, CS, and Art (by courtesy) Virginia Tech Dept. of Music - 0240 Blacksburg, VA 24061 (540) 231-6139 (540) 231-5034 (fax) ico(a)vt.edu http://www.music.vt.edu/faculty/bukvic/

14 years, 11 months

Project proposition: llvm based dsp engine

by Maurizio De Cecco

I have been looking for a while to LLVM as a possible technology to build a DSP execution engine, providing the runtime flexibility needed by real-time interactive DSP applications (like patcher languages), or by plug-in based processors, and in the same moment the powerful link time optimizations that such a system can provide. Such a task is daunting for a single developer project like mine, but it may become feasible if such engine could be useful for multiple projects, so to become a community initiative (i am sending this mail to the Linux Audio Developers mailing list and to the LLVM mailing list, feel free to send it elsewhere if you find it useful). So, I'll explain in a few lines exactly what i thinking of, and i propose that if anybody is interested in such initiative she/he can contact me directly, and we will see if there is enough interest for actually start something. Of course, i may also miss an existing project on the same field, in this case, let me know :->. The idea is the following: build a tool kit, based on LLVM, to dynamically build the execution chain of DSP applications; almost all DSP applications using plug-ins have something of this kind. This toolkit will be based on code generation and JIT, and should have a flexible architecture so to accomodate multiple plugin API/ABI, to be able to call, from the same execution chain, DSP operation written for different contexts (for example, LADSPA plug-ins, PD objects, and so on). The code generation would allow this integration for a very low run time cost. But the most interesting part is actually providing a definition of native, LLVM compiled, plug-ins, and to use the LLVM link time optimizations for doing things like inlining, loop fusions etc, between different DSP operation; this can provide quite a speed improvement for those chains composed of simple operators. The execution chain should be flexible enough to provide support for multi-rate synchronous data flows, and should include support for multiple threads execution (probably different chains for different threads). To complete the project, let's add a library of DSP operators, a reasonable high level API to use it, and documentation to help the DSP application designer (i find the LLVM learning curve quite steep :). Contact maurizio(a)dececco.name if you are interest in setting up such a project; if enough developers with the right skills and enough interest are found I'll set up a project mailing list to further discuss the subject. Cordially, Maurizio __________ Maurizio De Cecco - Music: http://www.myspace.com/mauriziodececco Blog: http://maurizio.dececco.name/ Software: http://www.jmax-phoenix.org/

14 years, 11 months

Re: [LAD] Project proposition: llvm based dsp engine

by Stéphane Letz

Le 7 déc. 2010 à 13:00, linux-audio-dev-request(a)lists.linuxaudio.org a écrit : > > Message: 6 > Date: Tue, 07 Dec 2010 11:40:08 +0100 > From: Maurizio De Cecco <jmax(a)dececco.name> > Subject: Re: [LAD] Project proposition: llvm based dsp engine > To: linux-audio-dev(a)lists.linuxaudio.org > Message-ID: <1291718408-fa0519db02fe30b9a7fa6ef94f6d44d6(a)dececco.name> > Content-Type: text/plain; charset="iso-8859-1" > > I realised that my yesterday answer miss the point a little, > so here it is a few linse of complement. > > Going back to the Paul comment: > >> I can say for sure that, for example, >> Ardour3 has an object called a Processor whose ::run() method >> encapsulates all DSP done within Ardour, but nevertheless it would be >> more or less impossible to do any kind of optimization that looked >> "across" all the Processors in a signal chain (eg. gain, pan, plugins, >> etc, etc). > > This is exactly the point: what about having a way to build the 'run' methods > for a class of applications (PD have such a method, jMax have such a method, > many others application have such a methods) that *would* allow cross plugin > optimisations for a certain class of plugins (those written or compiled according > to the engine 'native' rules) and being able to use the other plugins keeping the > glue code run time cost very low thanks to dynamic code generation. > > Essentially a generic basic infrastructure using LLVM code generation and optimisation > capabilities. > > And by the way, i am not sure to understand the reference to Faust, that is one of the > language/system used to define and assemble DSP algorithms, and to generate plugins, > but it is not a generic container for DSP executions, AFAIK. > > Maurizio > Doing "cross plugin optimisations" is something that can be done at the Faust source code level, where sophisticated optimization and code reorganisation can be done because we stay at a pure functional signal level, thus avoiding all the complex issues related to state management. If you want to combine plug-ins coded in any kind of imperative language, then some really hairy issues are coming quite rapidly. Stéphane

14 years, 11 months

Harmonic generator and transfer function

by Andrew Gaydenko

How does Steve Harris' Harmonic generator LADSPA plugin work? I mean relation between controls (concrete harmonics levels) and transfer function Vout = Vin(1 + a*Vin + b*Vin^2 + ...)

14 years, 11 months

Is there a Linux Software Mixer?

by Rory Filer

Hi All I think I know the answer to this, but I was wondering if it's possible to mix two separate audio sources in software. I'd like to be able to play announcement-type audio atop the currently playing main track. An example might be when driving down the Autobahn and a traffic report temporarily pre-empts whatever it is you are listening to. In my case, though, I'd prefer to keep the main audio playing, but at a very low volume level compared to the short announcement.. My setup is a roll-your-own embedded Linux distro with kernel 2.6.28. I'm using Alsa SoC audio driving an I2S output on my Marvell processor (which is now working just fine, BTW). The I2S signals feed an FM transmitter chip which is broadcasting audio to a nearby FM receiver. The FM chip only has the one input so no mixing possible within that part. Anyhow, considering I only have a single I2S output, seems to me that I'd need to do the mixing somewhere upstream of that serial port within the Linux machine. But there is no special hardware for this and I think the answer is "no, there is no way to mix two separate audio tracks without a DSP and another device driver". But I thought I'd ask just the same. Regards, Rory

14 years, 11 months

jackd, harddisks and live performance

by David Griffiths

Hi all, I don't know if this is a known issue or something fixed in recent kernels, but I recently found a fix for a problem I was having with my harddisk spinning down in live performances, and then loading samples from disk: http://www.pawfal.org/dave/blog/2010/11/jackd-performances-and-harddisks/ Also, while I'm here, this was the performance in which I tested the fix (slub livecoding at Piksel a couple of weeks ago): http://giss.tv/dmmdb//player.php?ID=1450&mode_clip&autoplay=no&baseurl=http… cheers, dave

14 years, 11 months

[ANN] QjackCtl 0.3.7 released!

by Rui Nuno Capela

JACK Session managerism... This might well be ahead of its time. And probably is. JACK session infrastructure and its promised functionality is still dormant in subversion source pits. However, good news are, no matter which flavor you pick, either JACK1 (>= 0.119.2) or JACK2 (>= 1.9.7), both already do it all to the promise. However still on their respective SVN trunks though. Maybe this very announcement will get that all loose and out of the dorm ;) At least, I'm trying. Meanwhile and until that ever happen, QjackCtl will be already here even though its JACK Session manager(istic) features will be just lurking to get out of redundancy. Fact is, this new source won't do much better than that of good old Patchbay, if compiled with existing JACK package distributions (latest are 0.118.0 and 1.9.6, respectively). Nor even close. Actually, only when it gets ever compiled and built against a current JACK Session API it will take off. Fly high or low, you may ask. Well, may I say, it will only fly as high as many Linux audio application developers will do to embrace the daunting trouble of adding a few dozen lines of source code to their creatures. And to their help, chances are that Torben Hohn already has all the starters ready (ask torbenh on #jack @ irc.freenode.net; maybe he still has some fresh git repo/patch on the fridge:). Then again, this very announcement is being kind of a heads-up. Avast ye LADs! Anyway, there are a few new tricks this old dog have been taught, besides putting the carriage before the horses, nevertheless... :) QjackCtl 0.3.7 has been released! That's it. Well, the uber-procrastinator sometimes gets over it. Sometimes :) Maybe there's a fine distinction between elegant procrastination and being just lazy. Tradition still rules: lazy enough to procrastinate no more :) Website: http://qjackctl.sourceforge.net Project page: http://sourceforge.net/projects/qjackctl Downloads: - source tarball: http://downloads.sourceforge.net/qjackctl/qjackctl-0.3.7.tar.gz - source package (openSUSE 11.3): http://downloads.sourceforge.net/qjackctl/qjackctl-0.3.7-1.rncbc.suse113.sr… - binary packages (openSUSE 11.3): http://downloads.sourceforge.net/qjackctl/qjackctl-0.3.7-1.rncbc.suse113.i5… http://downloads.sourceforge.net/qjackctl/qjackctl-0.3.7-1.rncbc.suse113.x8… Weblog (upstream support): http://www.rncbc.org License: QjackCtl is free, open-source software, distributed under the terms of the GNU General Public License (GPL) version 2 or later. Change-log: - Session widget has session save type preserved as well. - Connections and the new Messages/Status widgets now have their last open tab preserved across program run-cycles. - Connections and Patchbay widgets have been finally given up on an old feature request: an Expand All items button. - A significant UI layout has been made: the Messages and Status widgets were merged into one, giving space to the brand new Session wigdet to be easy accessible from the main panel control window. - libX11 is now being added explicitly to the build link phase, as seen necessary on some bleeding-edge distros eg. Fedora 13, Debian 6. (closing bug #3050915). - Input/Output latency options were missing but now finally enabled for the firewire back-end. - General standard dialog buttons layout is now in place. - Avoid pre-loading a stalled patchbay definition filename and its nagging error on startup (fixes bug #3017078). - Client connection retrial logic scrapped. Being a leftover from early ages, when machines were slower and JACK server startup times were longer... now, if it can't connect first time as client, it will tear down the server whether it's starting up still or not at all. (cf. Setup/Settings/Start Delay for the rescue). - Server name is finally part of the server settings presets, thanks to Fons Adriaensen for the heads-up. - As a workaround regarding issues switching jack2's backends, Robin Gareus sends us yet another D-Bus metho slot: "preset", (dbus-send --system / org.rncbc.qjackctl.preset string:PRESET). Thanks again. - Another D-Bus interface slot makes it through implementation: "quit" (eg. usage: dbus-send --system / org.rncbc.qjackctl.quit). Besides, there's also these new JACK session management actions which were being overlooked as well: "load", "save", "savequit" and "savetemplate" are also available as D-Bus method slots. - Make sure that Patchbay socket names are unique when adding or copying, fixing previous patch by Dominic Sacré. - JACK version is now being shown on the About box (jack2). - Slight Connections widget behavioral change: (dis)connecting a client (from) to one single port, (dis)connections will be applied in sequence from (to) all client output ports to (from) as many input ports there are in below, one by one (satisfying a 5 year old request from Yann Orlarey, thanks:). - JACK session support is being introduced. - Ignore first XRUN occurrence option dropped from statistics. - Initial widget geometry and visibility persistence logic has been slightly revised as much to avoid crash failures due to wrong main widget hidden state. - Double-quotes are now being added to device names which include blank characters and were rendering invalid all command line invocation of the classic JACK server (eg. specially due for Portaudio device names on Windows). - Transport play (rolling) status is now being guarded to avoid backfiring from extraneous transport state changes. - General source tree layout and build configuration change. - Italian (it) translation added (by Sergio Atzori). - Post-shutdown script invocation logic slightly refactored in attempt to enforce its execution on application quit. Enjoy! -- rncbc aka Rui Nuno Capela rncbc(a)rncbc.org

14 years, 11 months

Xsynth-DSSI experimental hack

by Gordon JC Pearce

Hi all, In keeping with the usual Xsynth-DSSI hackery I like to do (since it makes such an awesome experimental base) I'd like to present my latest horrible unlistenable noise generator: http://www.gjcp.net/~gordonjcp/xsynthhack.ogg Warning: only the voice generation code has been changed. This will overwrite or otherwise badly affect an existing install of Xsynth-DSSI. Be careful! http://www.gjcp.net/~gordonjcp/xsynth-dssi-0.9.4.tar.gz So what's different about it? Well, the minblep band-limited oscillators have been replaced by Tomisawa sine-feedback oscillators. These resemble "operator 4" in a DX21 or other four-op FM synth, in that by applying FM feedback around a sine function it starts to approximate a sawtooth wave. If you take two sawtooth waves, offset the phases, and subtract, you get a squarewave. By varying the offset, you vary the pulsewidth. Now here's the clever bit - I've modified things slightly so that the two Tomisawa generators can run at different speeds. So, by offsetting the frequencies you get either a deep PWM squarewave or a kind of "supersaw"-type sound. By varying the amount of modulation (beta) you can determine the "shape" of the waveform. So how are the oscillator controls affected? Pitch remains the same. Waveshapes are Sine (as you'd expect), Tri (saw with not much beta, really), Saw up and down are both just saw, Square (adjustable pulsewidth), Square with adjustable drift, and Saw with adjustable drift. Pitch mod and sync don't currently work. I don't know if sync can be made to work, without introducing aliasing. Have a play and let me know how you get on. Gordon MM0YEQ

14 years, 11 months

What do you do for a living?

by Kris C

Hi all, I understand that a lot of you develop for free software and are passionate at what you do. But how do you pay the bills? What do you do for a living? Are you a student? Do you do software development just as a hobby, or do you want to make a living doing this kind of work? The reason I ask this is because I am curious about what kind of backgrounds a free software developer has. As for me, I am a student majoring in Music and minoring in Computer Science. I got the idea of writing this email, actually, because Google had an internship panel at my school. Google just loooooves open source and those involved. It sounds like Google has quite a friendly and cooperative working atmosphere, and they treat their employees very well. Yeah, I'd like to work for Google, but who doesn't right? :) -Kris

14 years, 11 months

Jump to page:

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