Linux-audio-dev February 2003

linux-audio-dev@lists.linuxaudio.org

97 participants
92 discussions

by Bob Ham

Hi all, LADCCA, the session management system for jack and alsa sequencer applications on linux is now at version 0.3. After about a month of gentle fiddling, it now seems to work quite well. As an example, I managed to run muse, 2 standalone copies of iiwusynth and 2 copies of jack rack, save it with the server, close all the apps and restore it nearly perfectly (I say "nearly" as muse likes to control alsa ports and connections.) It's certainly coming along. Quite a few people have mentioned that they don't have a recent version of alsa and so no alsa.pc file in order for pkgconfig to detect it. This time, I've included an alsa.pc in the tarball. Obviously, inspect it first and make sure the prefix is ok and it's all kosher. * Added the facility to run restored apps in a terminal using xterm, and added the CCA_Terminal client flag for clients that need a terminal to operate. * much improved jack and alsa listeners in the server * quite a few compilation and bug fixes and whatnot http://pkl.net/~node/ladcca.html Bob -- Bob Ham <rah(a)bash.sh>

23 years

[linux-audio-dev] Re: [Jackit-devel] usetsched: RT-priority changer library

by Takashi Iwai

At Wed, 05 Feb 2003 13:07:59 -0500, Paul Davis wrote: > > >i wrote a small helper library which allows applications to change > >their realtime-priority without having root privilege. > > > >the method is similar like utempter library: the library forks and > >execs the checker program which is set as setuid-root. then the > >checker proves the invoking application and user (group or host) is > >registered in the list, and if it's ok, changes the RT-priority of the > >process. since each user and each application is tested, it's more > >secure. the advantage is also that no special kernel patches are > >necessary. > > takashi - this isn't enough for most apps, because they need to use > mlockall(2) as well. i don't think there is anyway to get the > priviledge for this without either have an euid of 0 or have the > relevant capabilities. yes, that's true. and it's also correct that mlock() can be achieved only via root-priv or CAP_IPC_SHM capability, unfortunately. the merit of my library is, however, that at least the RT-priority can be changed even with a normal kernel in a more secure way. that's what it's for. the importance of sched_setscheduler() is bigger than mlock() usually. but if you need really reliable operation, you must take a root-priv. btw, the similar mechanism can be applied to the case with capabilities. the sched_setscheduler() and mlock() wrappers call the helper to change the capability of the caller process (with a certain permission check) automatically if no capapbility was given. Takashi

23 years

[linux-audio-dev] newest audio server for Linux (yep, yet another)

by Phil Burk

> Bjarne Stroustrup who said something along the > lines of "Every use of a define is an instance of a programmer not > programming correctly." Gee, thanks. But Bjarne Stroustrup was probably writing about C++, which allows constants to be associated with a class: const double Synth::DEFAULT_FRAME_RATE = 44100.0; For C++, this construct is preferable to using a #define because the scope is limited to the class and would not conflict with, for example: const double Video::DEFAULT_FRAME_RATE = 30.0; That is a great feature of C++ but PortAudio is using 'C' not C++. So I think our only choices are #define and enum. PortAudio uses both. http://www.portaudio.com/docs/v19-doxydocs/portaudio_8h.html Are enums better than #defines?? I am always trying to improve my 'C' chops so I am open to suggestions. Phil Burk > > > > Imagine being able to write to an API as simple and well-designed as > > > > this: <http://www.portaudio.com/docs/v19-doxydocs/portaudio_8h.html> > > > > > > Just out of interest, why are paNoDevice, paFloat32, etc, defines > > > instead of const values? > > > > I don't really know. Isn't that kind of a six/half-dozen detail? > > Probably. I think it was Bjarne Stroustrup who said something along the > lines of "Every use of a define is an instance of a programmer not > programming correctly." But I was just wondering if it was some > portability thing or something. > -- > Bob Ham <rah(a)bash.sh>

23 years

[linux-audio-dev] usetsched: RT-priority changer library

by Takashi Iwai

Hi, i wrote a small helper library which allows applications to change their realtime-priority without having root privilege. the method is similar like utempter library: the library forks and execs the checker program which is set as setuid-root. then the checker proves the invoking application and user (group or host) is registered in the list, and if it's ok, changes the RT-priority of the process. since each user and each application is tested, it's more secure. the advantage is also that no special kernel patches are necessary. the changes needed for applications are only - add the following: #define WRAPPER_USETSCHED #include <usetsched.h> - link with -lusetsched i've tested (modified) jack and timidity. so far, it looks working fine. the detailed info is found at http://www.alsa-project.org/~iwai/usetsched/index.html the jack-patch is being prepared now. will be ready tomorrow. ciao, Takashi

23 years

RE: [linux-audio-dev] newest audio server for Linux (yep, yet ano ther)

by STEFFL, ERIK (SBCSI)

> -----Original Message----- > From: Bob Ham [mailto:rah@bash.sh] > > On Wed, 2003-02-05 at 00:26, Josh Haberman wrote: > > On Tue, 2003-02-04 at 13:41, Bob Ham wrote: > > > On Tue, 2003-02-04 at 20:47, Josh Haberman wrote: > > > > > > > Imagine being able to write to an API as simple and > well-designed as > > > > this: > <http://www.portaudio.com/docs/v19-doxydocs/portaudio_8h.html> > > > > > > Just out of interest, why are paNoDevice, paFloat32, etc, defines > > > instead of const values? > > > > I don't really know. Isn't that kind of a six/half-dozen detail? > > Probably. I think it was Bjarne Stroustrup who said > something along the > lines of "Every use of a define is an instance of a programmer not > programming correctly." But I was just wondering if it was some > portability thing or something. I think the basic idea is not to use preprocessor for programming... erik

23 years

[linux-audio-dev] newest audio server for Linux (yep, yet another)

by Ivica Bukvic

Kidding aside, this may prove to be so ubiquitous that it will quickly overshadow all other implementations. It's the MAS audio server that is going to be implemented into the X server itself and will be network-transparent. Slashdot just posted a news blurb on it: http://slashdot.org/article.pl?sid=03/02/03/2137213 For more info see: http://www.mediaapplicationserver.net/indexframes.html Any ideas if this will be also good for pro-audio stuff? Ivica Ico Bukvic, composer, multimedia sculptor, programmer, webmaster & computer consultant http://meowing.ccm.uc.edu/~ico ============================ "To be or not to be" - Shakespeare "To be is to do" - Socrates "To do is to be" - Sartre "Do be do be do" - Sinatra "2b || ! 2b" - ? "I am" - God

23 years

[linux-audio-dev] PTAF link and comments

by David Olofson

Here's that PTAF document that Ohm Force brought to Anaheim: http://freezope2.nipltd.net/ldesoras/files/ptaf-2003.01.23.pdf I've read some parts of it, and browsed all of it, and here are some initial reflections of mine: * Three states; created, initialized and activated. This may be useful if plugins have to be instantiated for hosts to get info from them. Why not just provide metadata through the factory API? * Bypass mode seems to be a good idea for stereo->surround. * Assuming that audio and sequencer stuff is in different threads, and even have plugins deal with the sync sounds like a *very* bad idea to me. * GUI code in the same binaries is not even possible on some platforms. (At least not with standard toolkits.) * Using tokens for control arbitage sounds pointless. Why not just pipe events through the host? That turns GUI/DSP interaction into perfectly normal control routing. * Why use C++ if you're actually writing C? If it won't compile on a C compiler, it's *not* C. * I think the VST style dispatcher idea is silly. A table of function pointers, with a bunch of reserved NULLs would be simpler, faster and just as extensible for all practical matters. * Is using exceptions internally in plugins safe and portable? * Specifying the maximum string length when asking for strings seems nice in some ways... * UTF-8, rather than ASCII or UNICODE. * Hosts assume all plugins to be in-place broken. Why? * No mix output mode; only replace. More overhead... * Only mono buffers. (Good.) * Buffers 16 byte aligned. Sufficient? * Events are used for making connections. (But there's also a function call for it...) * Audio quality control. (Nice scalability feature.) * Plugin input->output latency. * Host process return->audible output latency. * Tail size. (Can be unknown!) * Process mode: Mixed/RT/Off-Line. * Plugins send events specifically to the host... * Events are delivered in arrays, just like in VST. * "Clear buffers" call. Does not kill active notes... * Timestamps are in audio frames. * Events are always for the current block. * Ramping API seems awkward... * Ramping cannot run accross blocks. * It is not specified whether ramping stops automatically at the end value, although one would assume it should, considering the design of the interface. * Note IDs are just "random" values chosen by the sender, which means synths must hash and/or search... * Hz is not a good unit for pitch... * Why both pitch and transpose? * Why [0, 2] ranges for Velocity and Pressure? * Note On/Off/End confuse note on/off with context management. * TimeChange: tempo, ts numerator, ts denominator. * TransportJump: sample pos, beat, bar. (Why not just ticks?) * PlaybackChange: stopped/running * Plugins (not hosts) maintain parameter sets/presets. * Parameter sets for note default params? Performance hack - is it really worth it? * Why have normalized parameter values at all? (Actual parameter values are [0, 1], like VST, but then there are calls to convert back and forth.) * The "save state chunk" call seems cool, but what's the point, really? * Just realized that plugin GUIs have to disconnect or otherwise "detach" their outputs, so automation knows when to override the recorded data and not. Just grabbing a knob and hold it still counts as automation override, even if the host can't see any events coming... (PTAF uses tokens and assumes that GUI and DSP parts have some connections "behind the scenes", rather than implementing GUIs as out-of- thread or out-of-process plugins.) //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! --------------------------------. | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---------------------------> http://olofson.net/audiality -' --- http://olofson.net --- http://www.reologica.se ---

23 years

[linux-audio-dev] PTAF Specs

by Steve Harris

OK, I've read the more thoroughly now. On page 23 you have a list of properties (ie. metadata), some of these should be per-port, and the generic ones (name, authors etc.) should probably follow the qualified dublin core standard. http://dublincore.org/ It makes sense to me that versions should follow the library versioning convention, so that hosts could do substitution where appropriate. The denormal numbers stuff seems a bit low level, I'm not away of any operations you can do on denormal numbers without incurring penalty (maybe delay with no gain, but thats stetching it a bit). Also DC offset, shouldn't the plugin be expected to kill its own DC offset if its desired? There is a standard for describing this kind of structural metadata as well as classifications, but I've gone on about it a lot before (and implemnented support for LADSPA), so I'm not going to mention it here again or the LAD regulars will lynch me :) I wont talk about the VVID voice allocation scheme, because I think David can describe it better. Overall PTAF is supprisingly similar to XAP (which is encouraging), there are just some differences in emphasis. Us LAD people tend to be simplecity freaks. I think its one of the really good things about LADSPA. - Steve

23 years

[linux-audio-dev] [ANN] Bandlimited LADSPA Oscillator Plugins ('BLOP') v0.2.6

by Mike Rawes

BLOP is a set of LADSPA plugins - after way too long, it's up to v0.2.6 Website: http://blop.sf.net This release includes: * Full RDF metadata, for use with liblrdf * Bandlimited oscillators (no aliasing noise) Sawtooth Square Variable width pulse Variable slope triangle Improved performance and quality (fixed some stupid mistakes) over v0.2.5 4 Pole Moog-type resonant filter Tuned, stable LADSPA version of this filter: http://musicdsp.org/archive.php?classid=3#26 Two ADSRs Single gate with variable threshold Gate + Trigger variant (New since v0.2.5) Analogue-Style Step Sequencer (New since v0.2.5) Random wave generator, amplifier, 1V/Octave->Hz convertor ('fmod') and a few other useful things. Enjoy, Mike __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com

23 years

[linux-audio-dev] watchdog timeout on realtime operation

by Son of Zev

Hi On loading MusE with the -R option I get this error after a few seconds allan@littlewolf2 allan]$ muse -R Loading required GL library /usr/X11R6/lib/libGL.so.1.2 no locale <muse_en_GB>/</usr/share/muse/locale> ALSA port add: <MIDI 0-0>, 64:0 flags 3 0x7f Track: unknown tag <record> at line 236 ReadEvent: warning: event not in part: 0 - 12288 -12288, discarded WatchDog: fatal error, realtime task timeout (12326,0-3) - stopping all services Any suggestions? DO I just need to recompile a kernel without the software watchdog or is it something else? cheers Allan Klinbail

23 years

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

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 February 2003