Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7501 discussions

[ANN] The Audio Rollendurchmesserzeitsammler V0.0.1

by Kjetil S. Matheussen

The Audio Rollendurchmesserzeitsammler V0.0.1. http://www.notam02.no/arkiv/src/rollendurchmesserzeitsammler-0.0.1.tar.gz (Sorry for the long text below. I'm not planning to do big announcements of further versions of the collector. There is also more information about how it works, etc., in the README file in the source package.) ABOUT ----- The Audio Rollendurchmesserzeitsammler is a garbage collector which provides a general way to efficiently allocate and use memory inside a realtime audio thread without having to manually free it later. Furthermore, there is no write barrier, no read barrier, no special pointer types or templates (ie. no need to tell the collector exactly where pointers are), no reference counting, cyclic dependencies are detected, and finally it is by default configured to be hard realtime safe. Finally, The Audio Rollendurchmesserzeitsammler can be a drop in replacement for Hans Boehm's conservative garbage collector for C and C++. (Regarding its realtime safiness, I think CPU caches might theoretically play an unpredictable role to screw things up, but my limited observations so far is that it doesn't, or at least doesn't screw up a lot.) GARBAGE COLLECTOR TYPE ---------------------- Short: Snapshot mark-and-sweep. Long: Hard realtime conservative parallel non-moving snapshot-mark-sweep-and-free. PURPOSE ------- This collector might be useful for running high level, high performing, and garbage producing languages such as C#, Clean, Common Lisp, D, Eiffel, Haskell, Java, Oberon-2, OCaml, Scheme or SML directly inside a realtime audio thread doing signal processing. (http://shootout.alioth.debian.org/) It can also be useful for running less high performing programming languages which are not doing signal processing directly but would still be convenient to run inside the realtime audio thread, for example for handling midi events. By replacing the garbage collector in a high level language with the one provided in this package, the language becomes one step closer to be able to do realtime signal processing directly in the audio thread. And in some cases, this might very well be all thats needed too. One example is Stalin, an extremely efficient Scheme compiler. By only replacing Hans Boehm's garbage collector, which Stalin normally is using, Stalin's generated code can now run safely inside a realtime audio thread. See the provided example stalinwrapper.c / graincloud.scm how to do that. The allocator is also so effective, that its not unlikely that in some cases it might make sense using it in a program written in C or C++ as well when doing larger computations. CREDITS ------- The garbage collector uses TLSF for doing memory alloaction and deallocation. TLSF is a memory manager library supporting both bounded allocation time and bounded deallocation time. http://rtportal.upv.es/rtmalloc/ gcconfig.h is copied from Hans Bohems garbage collector. http://www.hpl.hp.com/personal/Hans_Boehm/gc/

17 years, 2 months

Tiny mplayer patch

by Fons Adriaensen

The attached small patch provides somewhat more flexible jack connections for mplayer, e.g. mplayer -ao jack:dest=ardour:port="Audio 2" willl make mplayer connect to the inputs of track "Audio 2". You can also connect to e.g. system:playback_3,4 if you set an alias for them first. When used without 'dest', 'port' behaves as before i.e. it selects an application. But the obvious way to do this now is to use 'dest' of course. Not a perfect solution but it helps. Ciao, -- FA Laboratorio di Acustica ed Elettroacustica Parma, Italia Lascia la spina, cogli la rosa.

17 years, 2 months

[OT]: Technical post at the Music Technology Lab, NUI Maynooth, Ireland

by victor

Apologies for cross posting ======================== The Music Technology Laboratory, NUI Maynooth is looking for a full-time technical officer to support its activities in Computer Music and Audio Technologies. http://humanresources.nuim.ie/technicalofficermusic.shtml For further enquiries, please contact Music.Department(a)nuim.ie ============================== Dr Victor Lazzarini Senior Lecturer, Music Music Technology Lab NUI Maynooth

17 years, 2 months

look：Beautiful China's online store

by Mr.SpOOn

Dear madam/sir: look：Beautiful China's online store I recommend to you a very good shopping site <<www.buying8.com>>. The quality of product is had better, the service is perfect, and price is had better, the speed of the deliver is very fast.There are own warehouse and store, there is customer in the whole world, receive customer very high praise. MSN: buying8(a)hotmail.com Email: buying8(a)hotmail.com Wish we cooperation delectation !

17 years, 2 months

Re: [LAD] vectorization

by Jens M Andreasen

On Thu, 2008-04-17 at 16:14 +0200, Fernando Lopez-Lezcano wrote: > You mean _complete_ binaries? All of the executable replicated several > times with different optimizations inside the package? So your intention > is not to optimize selected portions of the program, but _all_ of it?? No, plase be reasonable :-) One of the original source files holds the inner, hopefully vectorizable loops that eats cpu and may or may not contain ugly kludges to get around the denormals problem unavoidable in cpu's before sse2. > > And place the decision logic for which to use in pre and post install > scripts?? Yes please! (pretty please?) I would naively think that the package consists of object files with say engine.o in several versions. main.o userinterface.o networking.o ... engine.o.586 # plain C, runs everywhere but probably pretty terrible engine.o.sse # vectorized but has some kludges engine.o.sse2 # vectorized and no kludges, works for AMD, recomended! The pre-install script then looks in /proc/cpuinfo and decides which engine to rename to engine.o, links the objects in a jiffy, strips the binary and continues installation. > A downgrade would not affect a current linux system, the kernel > would just load the proper modules for the new hardware and run without > problems. All programs I know of would adjust themselves if necessary. > This might be because you have the least desireable versions of the programs? My all-singing-all-dancing kernel is at least three times bigger than older kernels. This without counting any modules. And it takes forever to figure out that nothing new has happened since last reboot :-| Distributions like Linux-from-Scratch do things differently. Which brings us back to the gunzip/configure/compile/install way of doing things Christian suggested from the start ... I must admit that I hate 'configure' myself. It is darned slow and checks for a lot of stuff that is senseless when you already know the target, and then it most likely just arrives at a decision that some obscure library is missing. Rinse, repeat ... A partially rpm based distribution could at least tell us to install KDE first and automagically do that before continuing to install stuff that depends on that environment. > Why do you think I, as a packager, will have access to all the possible > hardware? Nobody does. I don't. Good question. Who has the hardware and is willing to spend time on compiling and testing other peoples projects? Who would gain anything from this except for the end user? I suppose he/she then is the one to do the lifting, except that he/she probably won't have the guts to up the optimiser to insane levels, nor the experience to verify that the application did not break ... Also it is a lot of wasted time. Some kind of 'man in the middle' would be nice to have around, which is why people are looking at you :-) > > [why did you take the thread off the list?] I did not intend to, it was send TO: me, so the reply-to-list option (ctrl-L) was disabled. It is first now that you mention it that I realize that you also CC'ed the list. Putting it back now :-) > -- Fernando > > --

17 years, 2 months

[ANN] lv2-c++-tools 1.0.0

by Lars Luthman

This software package contains libraries and programs that should make it easier to write LV2 plugins and GUIs. Download it: http://ll-plugins.nongnu.org/hacking.html Read documentation: http://ll-plugins.nongnu.org/dox/lv2-c++-tools/ Or read a nice tutorial: http://ll-plugins.nongnu.org/lv2pftci/ To build and install, run ./configure make su -c 'make install' You can pass some options to configure, e.g. --prefix=/usr to install everything in /usr (the default is /usr/local). This is a development tool, but I'm sending it to the LAU list as well in case there are any not-yet-hackers who would like to start writing effects or synths. It's easy, I promise. Here's the code you would need to write for a simple gain effect: #include <lv2plugin.hpp> #include "gain.peg" class Gain : public LV2::Plugin<Gain> { public: Gain(double rate) : LV2::Plugin<Gain>(p_n_ports) { } void run(uint32_t nframes) { for (uint32_t i = 0; i < nframes; ++i) p(p_out)[i] = p(p_gain) * p(p_in); } }; static int _ = Gain::register_class("http://my.plugin/"); And here's the code you would need for a GUI for a synth plugin with a button that sends a test tone: #include <lv2gui.hpp> #include "mysynth.peg" class MySynthGUI : public LV2::GUI<MySynthGUI, LV2::WriteMIDI<true> > { public: MySynthGUI(const std::string& URI) : m_button("Click me!") { m_button.signal_pressed().connect(mem_fun(*this, &MySynthGUI::send_note_on)); m_button.signal_released().connect(mem_fun(*this, &MySynthGUI::send_note_off)); pack_start(m_button); } protected: void send_note_on() { uint8_t event[] = { 0x90, 0x40, 0x40 }; write_midi(p_midi, 3, event); } void send_note_off() { uint8_t event[] = { 0x80, 0x40, 0x40 }; write_midi(p_midi, 3, event); } Gtk::Button m_button; }; static int _ = MySynthGUI::register_class("http://my.gui/"); See? Trivial. Read more in the tutorial linked above. --ll

17 years, 2 months

Some LV2 news

by Lars Luthman

...for those who do not follow the LV2 mailing list. 1. EVENTS There is an extension for sending arbitrary events to and from plugin ports here: http://lv2plug.in/ns/ext/event#EventPort This extension specifies how to send MIDI events using those ports: http://lv2plug.in/ns/ext/midi#MidiEvent MIDI event support is implemented in Elven, Ingen, lv2_jack_host (and more?) and a couple of experimental plugins (a virtual keyboard, a basic drum machine, some MIDI utilities, some synths). There is no published OSC event type spec yet, but there are experimental hosts that are sending OSC to and from plugins and GUIs using the event ports. 2. UIS Here is an extension that defines a framework for embedded LV2 (G)UIs: http://lv2plug.in/ns/extensions/ui So far there is only a Gtk+ 2.0 GUI type specified, but others would be easy to add if someone writes up a spec for them. This is supported by Elven, Ingen (and more?) and a couple of plugins (e.g. above mentioned virtual keyboard and synths). There are also a bunch of other extensions for port grouping, saving and restoring the internal state of a plugin, and other stuff. See http://lv2plug.in for more information.

17 years, 2 months

cortado (gstreamer) [ot-ish]

by Julien Claassen

Hi Everyone! Sorry, it's not exactly audio itself: But has anyone of you experience with the cortado-java-applet? It's the multimedia-player applet, that's written by the gstreamer guys. The questions I have: 1. Can anyone recommend a certain version of it? - The version I have requires a VERY NEW java. 2. Does anyone know if there are constraints on the size of it? - I planed to put it in the upper left corner of a site. It's supposed to be roughly 20% by 20% of the browser-window. Is that too small? Sorry for asking this, but as a lot of you know, I'm blind and I can't really control, what I'm doing here. Kindest regards and any help is appreciated! Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

17 years, 2 months

Updates

by Fons Adriaensen

Hello all, Some updates on <http://www.kokkinizita.net/linuxaudio/downloads>: jmeters-0.2.0 - VU-meter scale replaced by a new one which does not have the -20dB threshold. Now it will also move for low-level sounds, and fall back much more naturally. - PPM now has the same size as VU. Old one still available as ppm2. - Added options to set jack client name and update rate. - Bugfix for Makefile, PNGs now get installed in $(PREFIX)/share instead of /usr/share. aeolus-0.8.1 - Aeolus-0.8.0 added Midi over Jack support but was announced on the Aeolus list only IIRC. With 0.8.1 it's official. - Major cleanup and bugfixes. - Replaces 0.6.6. as the supported release. ambdec-0.2.0 - Bugfixes, new collection of config files. MCP-plugins-0.4.0 - Major cleanup (after 5 years or so). - Added triple chorus. Same as chorus2 but has three outputs. Pan L,C,R for a nice stereo effect. clthreads-2.4.0 - Cleanup. clxclient-3.6.1 - Cleanup. - Probably fixes a bug that occurs only when running in KDE (windows not repainting when exposed). Many thanks to all who contributed by providing feedback, bug reports and patches. The two libs and ambdec now also have an OSX Makefile and the necessary #ifdefs to make them compile. This is very experimental. I will provide *no* support for this except to OSX developers who can provide the required technical feedback. Ciao, -- FA Laboratorio di Acustica ed Elettroacustica Parma, Italia Lascia la spina, cogli la rosa.

17 years, 2 months

LADSPA plugin behavior and naming, and more general questions

by Justin Smith

As a learning exercise, I made a LADSPA plugin that adds its inputs. I figured it would be reasonable to call such a thing '+'. Some plugin hosts don't like that (I was less surprised by the ones that could not handle the name '<'). This is the LADSPA_Descriptor.Label property. ladspa.h says "Labels must not contain white-space characters.". Is it unreasonable to expect to be able to have symbols as plugin labels, or parts of plugin labels? So this is more of a "what do you think" then a right/wrong answer kind of thing. Also, though ladspa.h does not say I cannot write my plugin library in such a way as to create resources shared by all the instances of my plugins within one host (say, a shared OSC connection?), would that be acceptable? Would that break hosts? What about per plugin GUI? If I just made a Makefile variable for a GUI to launch for a ladspa plugin, if I did not want the overhead of the full DSSI interface (or if I wanted to use the plugin in a non DSSI compatible host), would that be beyond the pale for a LADSPA plugin? Also, now that GMPI seems all but officially dead, does anyone think DSSI will be supplanted (or "disposed of", as its name would imply)? What is the general developer feeling regarding LADSPA/DSSI/LV2? I leave VST out of this list, because I don't think Linux distros can even legally distribute vst.h.

17 years, 2 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