Linux-audio-dev December 2010

linux-audio-dev@lists.linuxaudio.org

65 participants
48 discussions

Re: [LAD] [LAA] Denemo 0.8.22 Release - Free and Open Source Music Notation Editor (Lilypond Frontend & Midi)

by Niels Mayer

On Wed, Dec 8, 2010 at 9:38 AM, Nils <nils(a)hammerfeste.com> wrote: > Denemo 0.8.22 release! > Get it on http://www.denemo.org After a successful "configure" "make" fails with: Making all in doc ./make: line 1: html:: command not found warning: failed to load external entity "/usr/share/xml/docbook/stylesheet/nwalsh/xhtml/docbook.xsl" cannot parse /usr/share/xml/docbook/stylesheet/nwalsh/xhtml/docbook.xsl ./make: line 4: chunk:: command not found warning: failed to load external entity "/usr/share/xml/docbook/stylesheet/nwalsh/xhtml/chunk.xsl" cannot parse /usr/share/xml/docbook/stylesheet/nwalsh/xhtml/chunk.xsl ./make: line 7: pdf:: command not found compilation error: file denemomanual.xml line 3 element article xsltParseStylesheetProcess : document is not a stylesheet ./make: line 9: fop.sh: command not found ./make: line 10: acroread: command not found ./make: line 11: 075: command not found warning: failed to load external entity "/usr/share/xml/docbook/stylesheet/nwalsh/xhtml/profile-docbook.xsl" cannot parse /usr/share/xml/docbook/stylesheet/nwalsh/xhtml/profile-docbook.xsl ./make: line 14: 076: command not found warning: failed to load external entity "/usr/share/xml/docbook/stylesheet/nwalsh/xhtml/profile-docbook.xsl" cannot parse /usr/share/xml/docbook/stylesheet/nwalsh/xhtml/profile-docbook.xsl make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/npm/denemo-git' make: *** [all] Error 2 The issue seems to be hard paths to /usr/share/xml/docbook/stylesheet/nwalsh/xhtml/docbook.xsl which are files that aren't owned by any package on the Fedora platform: gnulem-335-~/denemo-git> yum whatprovides /usr/share/xml/docbook/stylesheet/nwalsh/xhtml/docbook.xsl ... No Matches found -- Niels http://nielsmayer.com

14 years

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

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

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

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

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

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

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

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 December 2010