Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7513 discussions

[linux-audio-dev] code in different files affects speed?

by Paul Davis

does anyone here know if splitting code across different files, or for that matter, reordering the layout of one source file so that functions called together are now "far apart" can actually affect execution speed? --p

22 years, 9 months

[linux-audio-dev] Plugin server (Re: [vst-plugins] Re: [a bit OT] gcc as a cross compiler for VST?

by Kjetil S. Matheussen

Please follow-up this discussion to LAD. On Sun, 8 Dec 2002, Paul Davis wrote: > >> the situation, as i said before, is miserable. we just don't have a > >> situation in linux where a single point of control can say "*this* is > >> the GUI toolkit you will use". X is clearly the standard, but its not > >> a toolkit (see below) that anyone can feasibly use alone. > >> > >I have asked you this two times allready, but I'm trying for a third time > >now. Why do you need this functionality? Unix is built from the ground > >to support multiple processes running at the same time, and therefore does > >it very well, at least linux does. And unix has things as sockets, pipes, > >semaphores and shared memory. WHY do you need to run everything from the > >same process? I only see disatvantages by doing that, exept that it > >uses a tiny bit more memory, but thats it. Please explain to me... > > because when running a real-time low-latency audio system, the cost of > context switches is comparatively large. if you've got 1500usecs to > process a chunk of audio data, and you spend 150usecs of it doing > context switches (and the cost may be a lot greater if different tasks > stomp over a lot of the cache), you've just reduced your effective > processor power by 10%. > I dont believe you. I just did a simple context-switching/sockets test after I sent the last mail. And for doing 2*1024*1024 context syncronized switches between two programs, my old 750Mzh duron uses 2.78 seconds. That should about 1.3usecs per switch or something. By having a blocksize of lets say 128 bytes, that means that by 25 minutes of 44100Hz of sound processing, 2.78 seconds is used for context switching. Not much. I'm not talking about jack tasks, I'm talking about doing a simple plug-in task inside a standalone program, the way the vst server works. I believe the advantages of making a proper plug-in server with an easy-to-use library binding "plug-ins" and hosts are large: 1. Stability. A Host can not crash, the server can not crash. Just the plug-in can crash. 2. Runs better on multiprocessor machines. (At least I think so) 3. Ease-of-use. By extending the interface with a library, common tasks as finding lists of plugins, loading plug-ins and GUI is available as functions ready to use. 4. A "plugin" is a program, which means that it can choose whatever GUI system it wants. Ladspa plug-ins can use guis. 5. All sorts of plugins can be supported by one such system, vst, ladspa, DX, maya, etc. 6. By making a simple wrapper, all ladspa plugins can automaticly be available as a "plugin" server "plugin", serving GUI. --

22 years, 9 months

Re: [linux-audio-dev] Vischeck

by Stefan Nitschke

>From: Anthony <avan(a)uwm.edu> >... >RTsynth it is impossible for me to tell whether a given synth is on or >off. That pixmap LED seems like a good idea, but maybe blue would be >better ;) ... Thank you for the hint! I will fix it in upcoming versions :) - Stefan _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

22 years, 9 months

[linux-audio-dev] Vischeck

by Anthony

http://www.vischeck.com/vischeck The above link allows you to upload an image or parse a webpage thru some software written at stanford that imitates what a colour blind person would see. It may be worth the time for you GUI designers to run a screenshot in it and see what 1/10 people see. Case in point: In RTsynth it is impossible for me to tell whether a given synth is on or off. That pixmap LED seems like a good idea, but maybe blue would be better ;) Not that I'm picking on RTsynth. Web page designers may want to also look at this, although the linux webpage community usually does a good job. --ant

22 years, 9 months

Re: [linux-audio-dev] Plugin APIs (again)

by John Lazzaro

> David Olofson <david(a)olofson.net> writes: > > Yes - but we're not talking about MIDI here. We *may* require that > events are never lost, and even that it's not legal to send two > identical events in line to an event port, unless you really mean > something else than to set a controller to the same value twice. Think ahead about how these sorts of requirements will be enforced: will they be a "law of nature" (code checks to see if an app broke the law, and takes action, like nature takes action when you try to change the current flowing through an inductor :-), or will it be unchecked by code? If its the latter, you can get into this mode where everyone has extra checking and work-around code, to handle impolite API users who aren't obeying the requirements. ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro -------------------------------------------------------------------------

22 years, 9 months

Re: [linux-audio-dev] Plugin APIs (again)

by John Lazzaro

> David Olofson writes: > > The point I think you're missing is that a "control change" event is > *exactly* the same thing as a "voice start" event on the bits and > bytes level. Lossy MIDI filters will prune away two MIDI Control Change commands in a row for the same controller value with the same data value, apart from controller numbers (like All Notes Off) whose semantics have meaning in this case. And the assumption underlying the behavior of these filters are present in subtle ways in other MIDI gear and usages too. For example, a programming language that presents an array with 128 members, holding the last-received (or default) value of each MIDI controller, presents an API that implicitly does this filtering, no matter how frequently the program samples the array. ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro -------------------------------------------------------------------------

22 years, 9 months

[linux-audio-dev] The global API namespace

by David Olofson

Just wondering how the h*ll you're supposed to name functions and types when all sensible naming conventions seem to be reserved by POSIX and other authorities... How about this for Audiality: Functions: a_whatever() Types: at_whatever I bet *some* lib is using a_* and/or at_*, but I have yet to find it. Besides, it doesn't look like a great idea to use both a_* and at_* for a single project - but *_t is reserved, and I don't like Capitalization in public APIs. Maybe I can make an exception, though... A_* and AT_* or something? Then again, most compilers can tell types from functions without throwing too much bogus messages at the user, so one might get away with a single prefix and simply remove the _t everywhere. //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 -' .- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture | `----------------------------> http://www.linuxdj.com/maia -' --- http://olofson.net --- http://www.reologica.se ---

22 years, 9 months

Re: [linux-audio-dev] Re: [Jackit-devel] 2.4.20-rc1�� + lowlat +preempt + alsa + jack = dead computer

by delire

audality looks good. we are currently using fmod <http://fmod.org> for a large games based arts project that sadly had to be win32 due to the nature of out middleware sponsorship <http://selectparks.net/acmipark.htm> currently i am using the <http://nevrax.org> NeL engine and hope to integrate fmod. i am however interested as to whether or not audality will at some point support www streaming. also, i've just ordered linux for ps2 dev kit.. looks like fun ;) julian oliver http://www.selectparks.net > On Saturday 07 December 2002 03.58, Fernando Pablo Lopez-Lezcano > wrote: > > > Where are the lowlat and preempt patches for 2.4.20? > > > > Not on the net at this point. I have been hand tweaking the > > originals to patch cleanly (trying to fix the failing chunks). I > > can email them to you, use at your own risk :-) > > I would be interested in trying your version of the patches. Please > mail! :-) > > > BTW, I applied the 2.4.19 LL patch to 2.4.20, and got a few rejects > in the file system area, which I have not investigated further. > (Seems to be a lot of changes around there...) Performance is "ok" > under X and proc stress, but I get countless latencies in the whole > range up to some 6-8 ms as soon as I start stressing the disk. (This > is *with* DMA enabled, of course.) > > Haven't tried preempt yet. > > > As to freezing, I've only managed to do that once - and IIRC, that > was when trying to instantiate a synth in MusE while Ardour was > running in the background. No useful info about what actually > happened, and I haven't tested that combination any further. > > Are you certain your freeze is actually happening in kernel space? > Tried using watchdog with "ping-pong" between highest and lowest > priority SCHED_FIFO threads? (BTW, we should have a watchdog anyway, > probably integrated with givertcap or something.) > > > //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 -' > .- M A I A -------------------------------------------------. > | The Multimedia Application Integration Architecture | > `----------------------------> http://www.linuxdj.com/maia -' > --- http://olofson.net --- http://www.reologica.se --- > > --

22 years, 9 months

[linux-audio-dev] lrdf version 0.1.2

by Steve Harris

http://plugin.org.uk/lrdf/ Applied patches from Richard Bown, making it c++ friendly and fixing some const-isms. liblrdf is a library for handling RDF (http://www.w3.org/RDF/) descriptions of LADSPA (and potentially other format) plugins. It allows grouping of plugins into trees for user slection and finer description of plugins and ports than the .so format allows (for example to indicatate textual equivalents of integer port values). It also provides named and described defaults and presets, metadata and general semnatic goodness. examples/example.rdf contains a slighly out of date description of my plugins. There are some example programs that show how the API works. - Steve

22 years, 9 months

[linux-audio-dev] ANN: swh-plugins 0.3.3

by Steve Harris

http://plugin.org.uk/releases/0.3.3/ Me again :) Sorry to release again so soon, but quite a few people have asked me for the improved Bode shifter, and everyones always after more pitch shifting options so I decided to release again. I've added a more sophisticated Bode shifter and made quality, speed and channel separation improvements to the old one. The outputs may even be labelled correctly now ;) I've also added an AM pitch shifter, which is pretty fast and for certain source material it actually gives reasonable sounding results, much to my supprise. Pitch shifter: http://plugin.org.uk/ladspa-swh/docs/ladspa-swh.html#id1433 Frequency shifter: http://plugin.org.uk/ladspa-swh/docs/ladspa-swh.html#id1431 Enjoy, Steve

22 years, 9 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