Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7527 discussions

[linux-audio-dev] Linux For Audio Tutorial at AES Convention

by Maarten de Boer

Hello, Yesterday, we gave a Tutorial called "Linux for Audio" at the AES Convention, which took place here in Barcelona. To quote the abstract: "It is obvious that Linux is becoming a real alternative to other well-known operating systems. But, is Linux ready to support all the requirements of the audio industry? In this tutorial, the Linux audio infrastructure will be introduced showing how it compares to and competes with other operating systems, with emphasis on low latency, application interconnectivity, and modularity. In addition, various aspects of this audio infrastructure will be demonstrated, using several promising applications in the Linux audio arena." The tutorial was 2 hours long, and consisted of two parts: a talk and a demo. During the talk we gave several smaller demonstrations. This worked out really well, because it made the final demo much more agile, as we already explained many basic features and operations before. The talk consisted of the following parts: The Linux Operation System (history, distributions, latency), ALSA, Interapplication connectivity (jack, alsaseq), Plugins (LADSPA, DSSI, VST), and the final demo. This demo mimicked a real-life studio situation, with Ardour as the main application. We had some prerecorded material, but also recorded a new bass guitar track on site. We demonstrated basic editting with Ardour, the use of plugins (LADSPA, VST and Jack application inserts), mixing with multiple output channels, automation with an motorized console (Behringer BCF2000), synchronization with Hydrogen and with Rosegarden (connected to fluidsynth), and bouncing the output back to Ardour. We planned to show Jamin as well, but we ran out of time. About 80 people assisted the tutorial, which can be considered quite a lot, taking into consideration that the AES audience seems rather Windows and Mac OS X centered. A quick "raise your hand" survey showed that about 40 percent of our audience were developers. We have the feeling that the tutorial went very well, and that the audience got a good impression of the possibilities of Linux for audio. No real technical problems happened during the demo. We would like to thank all of you who made this possible. That means of course all of the developers, but also the entire community. We had a good time giving this Tutorial, and we hope to have generated some interest in the AES crowd, and given them a good idea of the current state of Linux audio applications. We put the slides at http://iua-share.upf.es/wikis/aes/ and tomorrow we will add some photos. Of course suggestions are welcome! Pau Arumi Maarten de Boer

20 years, 7 months

[linux-audio-dev] Software controller for homemade edrums

by Olivier Guilyardi

Hi, Assembling piezo microphones, cardboard, foam, wood and a cymbal stand, I have just made my first DIY electronic pads. Actually it's electronic percussions, because I will play these mostly with hands. I've found a few sites about DIY "edrums" (1), as well as some detailed documentation about how to build a trigger-to-midi hardware controller (2). But since I started this little project, I've been thinking about plugging the piezo mikes directly into my soundcard inputs. My first tests are very good : the signal is clean, and indicates faithfully how hard the pads get hit. I am now about to code a software controller to : 1 - either interprete the signal and produce midi (or OSC) events 2 - or interprete the signal, and play samples by itself, in a standalone manner (no midi) I tend to prefer the second option, for the following reasons (criticism welcome) : - I want to reduce latency _as_much_as_possible_ (keeping the rythm is hard enough ;-). To me, the midi layer introduces useless buffers - I'd like the whole thing to use minimal resources, so that I can run it on old hardware (simple boxes to be carried in studios and on stage). In this regard, a small tool built upon Alsa, which run without any sound server or midi layer, looks to me as the lightest solution - I don't want to use harware expanders, such as the one that is built into my soundcard. I want to play samples. With midi, I would then need a such tool as Timidity, which is pretty heavy according to my latest tests. Jtrigger seems lighter (http://sparked.zadzmo.org/jtrigger), but it relies on Jack : I like Jack, but it seems too heavy to me, for this specific job. - In regard to clicks and other noises, I believe a lightweight application running on a dedicated barebone Linux system is more reliable than a realtime thread with a complex layer as Jack, especially on slow hardware. Are these good/coherent reasons to you ? Do you have any other advice ? Is there already some software that could help me, or some pieces I could reuse, to achieve any part of this process ? Best regards References : (1) http://edrum.for.free.fr (2) http://www.midibox.org/edrum -- og

20 years, 7 months

[linux-audio-dev] [ANNOUNCE] qjacklam V0.3 with 2 Jack Clients & table Widget

by Karsten Wiese

qjackLaM is a Latency Meter for jack. There are 2 JackClients now: 1 only outputs, the other only reveives. This should cause 0 impact on Jacks graphordering concerning the other clients. Also new: qjacklam measures ALL possible ways by itself and displays the results in a table. Get the source, cvs and fc3-binary via http://developer.berlios.de/projects/qjacklam . have fun Karsten ___________________________________________________________ Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de

20 years, 7 months

[linux-audio-dev] ANN: Oscilloscope plugin 0.2.1

by Lars Luthman

Version 0.2.1 of the Oscilloscope DSSI plugin is now available here: http://www.student.nada.kth.se/~d00-llu/music_dssi.php?lang=en It has fixes for some bugs spotted by Sean Bolton: - The GUI will now actually quit when it receives a /quit command from the plugin host - There will be no /tmp/dssi_shm_tmpfile_* files left behind when the plugin and GUI exits - The Makefile uses pkg-config to get the compiler flags for DSSI, so it should work now even if your DSSI header is installed in a non-standard directory Thanks to feedback from Sean Bolton and Chris Cannam on the DSSI mailing list I know also know that the plugin works with ghostess-20050516 and the latest CVS version of Rosegarden (but not with any releases of Rosegarden). -- Lars Luthman PGP key: http://www.d.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E

20 years, 7 months

[linux-audio-dev] the stack threat - memory management and RT apps

by Christian Schoenebeck

Hi! I guess everybody of you know that allocating memory on the heap at runtime in RT threads is not a good idea. This can easily prevented by user space / application managed memory pools. But whatabout the stack? Even if you try to use the heap for local variables as well, you (usually) won't be able to prevent usage of the stack due to ABI definitions; e.g. on most platforms function arguments will be delivered through the stack. So what can you do to prevent physical pages to be allocated for the stack at RT critical time? Because this would lead to the same problems as calling malloc(), new and co. I read: "Although it is possible to give memory back to the system and shrink a process's address space, this is almost never done." [1] That sounds to me as once physical memory pages were assigned to the virtual stack range (due to stack growth), those physical pages were not be freed even if the virtual stack shrinks (that is the stack pointer increments). Is that true? And what does "almost" mean in this manner? Unfortunately I'm not into the mm internals of Linux yet. If the above claim is true, then we could simply increase the stack for a short time at the beginning of a RT application, e.g. by calling alloca() (maybe not good - dangerous and not portable) or by defining a big array on the stack in a helper function and/or by making that helper function recurse to a certain level to solve the danger of the stack. Anybody with deep Linux mm knowledge around? CU Christian [1] http://www.informit.com/articles/article.asp?p=173438

20 years, 7 months

[linux-audio-dev] sweep-oscillator

by Andrew Gaydenko

Hi! Is there some kind of software with sweep-oscillator functionality (preferably JACK-enabled)? Thanks! Andrew

20 years, 7 months

[linux-audio-dev] Dumb question regarding CMT's ambisonic plugins

by Ivica Ico Bukvic

Hi all, I've posted this one before on the LAU list but unfortunately I've not received any response. Please accept my apologies for cross-posting, but I am hoping that someone on LAD might be able to help me learn more on this particular topic. I would greatly appreciate help in this matter! At any rate, here's the question: I have been messing with the ambisonic plugins provided in the CMT ladspa collection. I am namely looking into a simple implementation of B-format 1ch->4ch encoder. The problem is that I am failing to figure out how to use this on a simple mono (non-encoded) sound input in order to control its diffusion over 4 channels. When running it via Ardour and sending it to 4 separate busses via this plugin, even though the x, y, and z coordinates do affect the output of the 4 channels, they do not conform to the expected 3,4,2,1 output (I presume these correspond to 4 speaker outputs, but I am also having doubts about this as well, so your help in understanding this better would be most appreciated). By now you can see that although I know a bit about ambisonics (namely theory), that I am quite a newb in this area, but for what it's worth I am eager to learn :-). The pd set of plugins pretty much work as expected but they are also designed differently, likely with discrete 4-8 output that can be then patched directly to main outs. In the case of ladspa plugins I am not even sure whether what I am getting is encoded version of a 4-channel stream that then needs to be decoded. Yet, when I tried having: mono sound-> b-format 1ch to 4ch encoder (LADSPA)->4ch to 4ch decoder (LADSPA) -> out That gave me bunch of garbage with two out of 4 channels consistently clipping, so this means that this is probably not the case either... So, to conclude I must be not using the CMT plugins properly and would therefore greatly appreciate it if someone would enlighten me. I am already aware of the theory behind the ambisonics, it's just that I am a bit puzzled how the CMT plugins (if at all) could be used with mono and/or stereo non-encoded streams in order to spatialize them in real-time. I would most appreciate a simple practical example as to how to do this (if such proves to be possible). Thank you very much! Best wishes, Ico

20 years, 7 months

[linux-audio-dev] ALSA Sequencer API - How to Receive Events?

by Sean Don

Hi all. I'd like to receive Midi note events from another Midi Player. But before I attempt to dive into a wad of documentation, I'd like to know if it's even possible under the following situation... 1) I don't have a hardware sequencer; so, I use timidity as an ALSA sequencer, then pmidi a player... timidity -iA -B8,8 -Os & pmidi -p 128:0 <midi file> 2) That plays fine, but how to tap into the events pmidi is sending to 128:0? I've tried modifying sample code such as dump-alsa.c, but no output. Also tried tips at "ALSA related stuffs", but was unable to get "aseqview" to compile. Any tips? Thank you in advance. - Sean http://www.home.unix-ag.org/simon/files/dump-alsa.c http://mitglied.lycos.de/iwai/alsa.html __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new Resources site http://smallbusiness.yahoo.com/resources/

20 years, 7 months

[linux-audio-dev] ANN: Oscilloscope plugin 0.2.0

by Lars Luthman

Here is an oscilloscope DSSI plugin that I've been hacking on the last few weeks: http://www.student.nada.kth.se/~d00-llu/music_dssi.php?lang=en It has two audio input ports and will display the two input signals as two waves in the display. The trigger level and direction is controllable, as well as the amplification and offset for each channel and the time resolution. Note that this plugin will NOT work with jack-dssi-host from version 0.9 of the DSSI package since that does not support audio input ports. It will work with jack-dssi-host or Om from current CVS (I haven't tested it with Rosegarden). Om 0.1.1 and earlier will not work because of an optimisation that breaks this type of plugins. The plugin includes a DSSIUIClient class that might be of interest to plugin UI writers using libsigc++ and Glibmm - it handles all the required communication with the plugin host and exposes public member functions and signals for the UI -> host and host -> UI OSC commands specified in the DSSI RFC. It can also handle the nasty business of setting up an initial shared memory segment for the plugin and the UI (the actual implementation of the shared memory handling is in a separate C file, so it could be useful for people who don't use libsigc ++ and Glibmm or even C++). Source code documentation is here http://www.student.nada.kth.se/~d00-llu/plugins/ll-scope/dox/html/classDSSI… and here http://www.student.nada.kth.se/~d00-llu/plugins/ll-scope/dox/html/dssi__shm… For more details about the plugin, read the README file in the source package. It's all GPL. -- Lars Luthman PGP key: http://www.d.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E

20 years, 7 months

[linux-audio-dev] Re: Best-performing Linux-friendly MIDI interfaces?

by Kjetil Svalastog Matheussen

Paul Davis: > > >what is the 'easiest' MIDI interface to get working under the average > >Linux kernel? what sort of experiences do folks have with getting > >MIDI working (on a programming level) using API's such as (but not > >limited to) ALSA, and MidiShare? > > > >for me so far, MidiShare seems to offer the most direct and usable > >approach .. while ALSA is wraught with complexity and dependencies > >which often seem out of control. i'd like to know what your > >experience, as developers, has been with getting a working MIDI > >subsystem under Linux ... > > i can speak up as someone who has avoided any interactions with the > ALSA sequencer for years because of a similar perception. i recently > converted Tim Thompson's KeyKit from its raw MIDI port-based > implementation under Linux to one that uses the ALSA sequencer (and > adding multiport support along the way). it was suprisingly easy and > obvious, given a simple example (in this case, the "ALSA sequencer > MIDI Port object" that someone contributed to Ardour). even more > gratifying was comparing the code to the keykit implementations for > win32 and CoreMidi. the ALSA sequencer one was smaller, more logical > and less bogged down in details. > Yepp, same experience as you. Before using the alsa seq api myself, it seemed to be horrible complicated. But it really wasn't. Tip: the source for jack-rack by bob ham has some clean alsa-seq code to look at. --

20 years, 7 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