From fons at kokkinizita.net Mon Jan 1 16:52:17 2007 From: fons at kokkinizita.net (Fons Adriaensen) Date: Mon Jan 1 16:53:55 2007 Subject: [linux-audio-dev] 2007.. In-Reply-To: <1167567054.11085.2.camel@localhost.localdomain> References: <20061230233732.GC5838@linux-1.site> <4597018E.7050708@t-online.de> <200612310225.40207.ce@christeck.de> <1167567054.11085.2.camel@localhost.localdomain> Message-ID: <20070101215217.GA5905@linux-1.site> On Sun, Dec 31, 2006 at 01:10:54PM +0100, Alberto Botti wrote: > Il giorno dom, 31/12/2006 alle 02.25 +0100, Christoph Eckert ha scritto: > > > Congrats for the new job! Hope you'll enjoy yourself in Italy. :) See > > > you in Berlin. > > > > of even better in Italy - will there be a LAD-party?!? > > Why not? :) No parties, but once I'm installed permanently (planned early March) passing LAD members are welcome for a grappa, wine or beer. I wonder, are there many Italian members on this list ? Also, what's happening in Italy in the field of electro-acoustic music ? I know the about the Centro Tempo Reale in Firenze but little more... -- FA Lascia la spina, cogli la rosa. From mobarre at gmail.com Tue Jan 2 05:24:23 2007 From: mobarre at gmail.com (Marc-Olivier Barre) Date: Tue Jan 2 05:26:00 2007 Subject: [linux-audio-dev] 2007.. In-Reply-To: <20070101215217.GA5905@linux-1.site> References: <20061230233732.GC5838@linux-1.site> <4597018E.7050708@t-online.de> <200612310225.40207.ce@christeck.de> <1167567054.11085.2.camel@localhost.localdomain> <20070101215217.GA5905@linux-1.site> Message-ID: <3c808a150701020224i785c46f8g54e49a69f2a976db@mail.gmail.com> On 1/1/07, Fons Adriaensen wrote: > On Sun, Dec 31, 2006 at 01:10:54PM +0100, Alberto Botti wrote: > > No parties, but once I'm installed permanently (planned early March) passing > LAD members are welcome for a grappa, wine or beer. > I wonder, are there many Italian members on this list ? Also, what's happening > in Italy in the field of electro-acoustic music ? I know the about the Centro > Tempo Reale in Firenze but little more... > Well I could enjoy a week-end in Italy... Likewise, If you would like to spend some time in Paris, You're quite welcome ;-) __________________ Marc-Olivier Barre, Markinoko. From nescivi at gmail.com Wed Jan 3 10:26:47 2007 From: nescivi at gmail.com (nescivi) Date: Wed Jan 3 10:27:06 2007 Subject: [linux-audio-dev] Happy LAC2007! Message-ID: <200701031626.46949.nescivi@gmail.com> Happy new year to you all! I just wanted to remind you all that the deadline (8th of January) for the LAC2007 is getting nearer, so now is the time to still write that paper, mail that cd, or make that proposition for that tutorial. Detailed info: http://www.kgw.tu-berlin.de/~lac2007/index.shtml Sincerely, On behalf of the Linux Audio Conference 2007 Orga Team, Marije Baalman From game_core at o2.pl Wed Jan 3 16:28:21 2007 From: game_core at o2.pl (kind king knight) Date: Wed Jan 3 15:28:58 2007 Subject: [linux-audio-dev] Simple music sequencer/sample player (drummmachine?) Message-ID: <1167859701.6663.0.camel@localhost.localdomain> I need a framework of a sequenced sample player. This is becouse I want to start my own project, and don't want to invent everything from scratch. Ofcourse there is lot of this kind opensource applications, but I need the simplest. - It should use only /dev/dsp - the sequence should be in a form of an char array, where the bits decide what voice to play. For egzample: seq[]={1,0,0,0,2,0,1,3,0,3,1,0,2,0,1,0} seq[0]==1 means that in first step should be played only the first sample (bassdrum),seq[1]==0 means pause (no sample), seq[4]==2 second voice (snare), and seq[7]==3 means snare +bass drumm. - I need to understand how the sequence procesing, and sound mixing is done in real time, and how the gaps betwen sounds should be iplemented. - the samples should be held in raw arrays (16 of 8 bit), eventualy downloadable from hdd. - a simple dsp like lp-filter would be nice to see, becouse i am curios how the time needed to proces the signal should be counted into the latency (and buffer size). - there is also a need for bpm clock. - a simple interpolation would be nice. Ok. I think that this is all! :P Or wait!!!!! I have a better idea! I there a way to make those things using for example libmikmod? I would like to start a music program for live mixing of mod, and xm modules (plaing, and muting chanels, realtime patterns changing, looping sequences). If someoune is interested in helping, I am open for sugestions. From paul at linuxaudiosystems.com Wed Jan 3 15:45:31 2007 From: paul at linuxaudiosystems.com (Paul Davis) Date: Wed Jan 3 15:46:48 2007 Subject: [linux-audio-dev] Simple music sequencer/sample player (drummmachine?) In-Reply-To: <1167859701.6663.0.camel@localhost.localdomain> References: <1167859701.6663.0.camel@localhost.localdomain> Message-ID: <1167857131.2907.542.camel@localhost.localdomain> On Wed, 2007-01-03 at 16:28 -0500, kind king knight wrote: > I need a framework of a sequenced sample player. This is becouse I want > to start my own project, and don't want to invent everything from > scratch. Ofcourse there is lot of this kind opensource applications, but > I need the simplest. > - It should use only /dev/dsp /dev/dsp represents a deprecated interface. moreover, what happens when someone wants to route the output of your cool, modified mod player through FreqTweak or jack_convolve? pro audio/music apps need JACK.... or at least their users do. > - the samples should be held in raw arrays (16 of 8 bit), eventualy > downloadable from hdd. hopefully thats "16 or 8". From _ at whats-your.name Wed Jan 3 16:09:57 2007 From: _ at whats-your.name (carmen) Date: Wed Jan 3 16:09:05 2007 Subject: [linux-audio-dev] Simple music sequencer/sample player (drummmachine?) In-Reply-To: <1167857131.2907.542.camel@localhost.localdomain> References: <1167859701.6663.0.camel@localhost.localdomain> <1167857131.2907.542.camel@localhost.localdomain> Message-ID: <20070103210957.GB8945@replic.net> On Wed Jan 03, 2007 at 03:45:31PM -0500, Paul Davis wrote: > On Wed, 2007-01-03 at 16:28 -0500, kind king knight wrote: > > I need a framework of a sequenced sample player. This is becouse I want > > to start my own project, libzzuvb is probably closest to what you describe. you could also hack together dino|seq24 with chionic|specimen, anything heftier (eg, wired, LMMS, hydrogen) is likely to be more annoynig to extract and don't want to invent everything from > > scratch. Ofcourse there is lot of this kind opensource applications, but > > I need the simplest. > > - It should use only /dev/dsp > > /dev/dsp represents a deprecated interface. > > moreover, what happens when someone wants to route the output of your > cool, modified mod player through FreqTweak or jack_convolve? > > pro audio/music apps need JACK.... or at least their users do. zzub only uses portaudio, which has a horrible track record with connecting to jack.. although i guess theyve imported the portaudio tree and applied some patches that might help..i dont knmow, aldrin has failed to compile here for some time.. (since v0.2 or so) > > > - the samples should be held in raw arrays (16 of 8 bit), eventualy > > downloadable from hdd. > > hopefully thats "16 or 8". > > > From game_core at o2.pl Wed Jan 3 18:32:59 2007 From: game_core at o2.pl (kind king knight) Date: Wed Jan 3 17:32:55 2007 Subject: [linux-audio-dev] Simple music sequencer/sample player (drummmachine?) Message-ID: <1167867179.6946.12.camel@localhost.localdomain> >libzzuvb is probably closest to what you describe. you could also hack together dino|seq24 with chionic|specimen, anything heftier (eg, wired, LMMS, hydrogen) is likely to be more annoynig to extract Those programs are to complicated. I need a toy to learn from it (it should be simple, but written using good techniques). I tough more about something like Hammerhead ( http://www.threechords.com/hammerhead/ ), or even something easier (no gui, one soucefile). >/dev/dsp represents a deprecated interface. >moreover, what happens when someone wants to route the output of your >cool, modified mod player through FreqTweak or jack_convolve? Like I said, I want to learn from it, so I don't need a complicated soundserver support (but I don't say that I won't ever use it). If there isn't such program, then maybe someone could write it for me :D. From david at olofson.net Thu Jan 4 09:47:40 2007 From: david at olofson.net (David Olofson) Date: Thu Jan 4 09:49:14 2007 Subject: [linux-audio-dev] Simple music sequencer/sample player (drummmachine?) In-Reply-To: <1167867179.6946.12.camel@localhost.localdomain> References: <1167867179.6946.12.camel@localhost.localdomain> Message-ID: <200701041547.40352.david@olofson.net> On Thursday 04 January 2007 00:32, kind king knight wrote: [...] > Those programs are to complicated. I need a toy to learn from it (it > should be simple, but written using good techniques). I tough more > about something like Hammerhead ( > http://www.threechords.com/hammerhead/ ), or > even something easier (no gui, one soucefile). Well, it's not a single file, it's got a very minimalistic tracker style GUI, and it's using SDL, but it does what it does in about the simplest but (hopefully) correct way: http://olofson.net/mixed.html (DT-42) http://olofson.net/download/DT-42-0.1.0.tar.gz > >/dev/dsp represents a deprecated interface. > > >moreover, what happens when someone wants to route the output of > >your > >cool, modified mod player through FreqTweak or jack_convolve? > > Like I said, want to learn from it, so I don't need a complicated > soundserver support (but I don't say that I won't ever use it). Well, either way, DT-42 uses the SDL audio API. (Which is a lot easier to deal with than OSS or ALSA.) Like JACK and any other serious audio API, this API is callback based. There are some remaining, interesting issues that need fixing. For example, quantization during real time recording (which has to deal with arbitrary audio latency) doesn't really do what it's supposed to. It always rounds down, because the looping implementation isn't safe with recording with "negative delays". (To push a note forward, you'd have to run ahead of the sequencer, looking for loop commands and stuff, or you could end up putting the note some place the sequencer will actually never go.) Another issue is the locking of the sequencer that is done when the GUI messes with things. To make it totaly real time safe, one has to use a different approach. As it is, you might end up with the GUI having a "hickup" while holding the lock that prevents the real time thread from running... Figuring out how to do these things properly might be a good exercise. ;-) > If there isn't such program, then maybe someone could write it for > me :D. Way ahead of you...! :-D I wrote DT-42 almost exactly a year ago. //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --' From contact at leonard-ritter.com Thu Jan 4 15:51:26 2007 From: contact at leonard-ritter.com (Leonard Ritter) Date: Thu Jan 4 15:51:37 2007 Subject: [linux-audio-dev] Simple music sequencer/sample player (drummmachine?) In-Reply-To: <20070103210957.GB8945@replic.net> References: <1167859701.6663.0.camel@localhost.localdomain> <1167857131.2907.542.camel@localhost.localdomain> <20070103210957.GB8945@replic.net> Message-ID: <1167943886.9733.56.camel@localhost> On Wed, 2007-01-03 at 16:09 -0500, carmen wrote: > zzub only uses portaudio, which has a horrible track record with connecting to jack.. although i guess theyve imported the portaudio tree and applied some patches that might help..i dont knmow, aldrin has failed to compile here for some time.. (since v0.2 or so) for libzzub 0.1, we replaced portaudio entirely with rtaudio. -- Leonard Ritter -- Freelance Art & Logic -- http://www.leonard-ritter.com From beachnase at web.de Thu Jan 4 17:30:06 2007 From: beachnase at web.de (Frank Neumann) Date: Thu Jan 4 17:33:03 2007 Subject: [linux-audio-dev] Simple music sequencer/sample player (drummmachine?) In-Reply-To: <200701041547.40352.david@olofson.net> References: <1167867179.6946.12.camel@localhost.localdomain> <200701041547.40352.david@olofson.net> Message-ID: On Thu, 4 Jan 2007 15:47:40 +0100 David Olofson wrote: > Well, it's not a single file, it's got a very minimalistic tracker > style GUI, and it's using SDL, but it does what it does in about the > simplest but (hopefully) correct way: > > http://olofson.net/mixed.html (DT-42) > http://olofson.net/download/DT-42-0.1.0.tar.gz [..] > Way ahead of you...! :-D I wrote DT-42 almost exactly a year ago. Hey, that's a *nice* little app :-). What about adding JACK audio&transport control? Ah, it's in the Todo already :-). No, honestly - I enjoyed toying around with it for a while just now. Ok, the waveform display appears rather heavy on the CPU, but it looks so beautifully retro, and you even honoured the golden rule of "thou shalt enclose some good examples with your application". Luv it :) Thanks, Frank From florentberthaut at no-log.org Thu Jan 4 19:44:00 2007 From: florentberthaut at no-log.org (florentberthaut@no-log.org) Date: Thu Jan 4 19:44:25 2007 Subject: [linux-audio-dev] Simple Jack mixing problem Message-ID: <57861.AQIGDV8HUH8=.1167957840.squirrel@webmail.no-log.org> Hi everyone, I'm working on a sampler and i have a really silly problem. I simply want to mix sounds in a stereo buffer within the jack "process" function. So for each frame i sum the samples from each sound but then the values go above 1 and i get clipping. So my first thought was to divide by the number of samples playing, but it ends up with a decrease in volume. I tried to limit the values between -1 and 1 but it 's also clipping -> distortion. I looked into some sources and it seems i would actually just have to sum the samples. Can anyone help me with that ? Thanks Flo From david at olofson.net Thu Jan 4 21:28:01 2007 From: david at olofson.net (David Olofson) Date: Thu Jan 4 21:29:25 2007 Subject: [linux-audio-dev] Simple music sequencer/sample player (drummmachine?) In-Reply-To: References: <1167867179.6946.12.camel@localhost.localdomain> <200701041547.40352.david@olofson.net> Message-ID: <200701050328.01841.david@olofson.net> On Thursday 04 January 2007 23:30, Frank Neumann wrote: > > On Thu, 4 Jan 2007 15:47:40 +0100 > David Olofson wrote: > > > Well, it's not a single file, it's got a very minimalistic tracker > > style GUI, and it's using SDL, but it does what it does in about > > the > > simplest but (hopefully) correct way: > > > > http://olofson.net/mixed.html (DT-42) > > http://olofson.net/download/DT-42-0.1.0.tar.gz > > [..] > > > Way ahead of you...! :-D I wrote DT-42 almost exactly a year ago. > > Hey, that's a *nice* little app :-). Thanks! :-) > What about adding JACK audio&transport control? Ah, it's in the Todo > already :-). That, and maybe DSSIfying the audio and/or sequencer part. Dunno... I suppose it would make it possible to load and play songs without the GUI, which might be handy. OTOH, it would add overhead to the GUI<->engine communication, and the audio and sequencer parts aren't really all that interesting in their own right anyway. (Incredibly simple sampleplayer and 2 operator FM synth with D envelope. The sequencer is like a very simple tracker format with something like 3 commands and no pitch control. :-D) Besides, I have other projects in the pipe, including some DSSI synths, a reimplementation of Audiality (actually more like an audio/music toolkit for EEL) and some other stuff. I'm thinking that the ideas might be more useful than the actual DT-42 code. After all, it was intended as a pure C + SDL example with a minimum of libs and build tools required. The GUI is probably better done in some higher level language and/or using a proper toolkit (now it's plain low level SDL rendering), and the engine could use some refactoring. Then again, there is something about GUI applications written entirely in minimalistic low level code... Reminds of the good old days, when real trackers were implemented in 100% assembly language, and audio and video was done to the metal. ;-) > No, honestly - I enjoyed toying around with it for a while just now. > Ok, the waveform display appears rather heavy on the CPU, but it > looks so beautifully retro, and you even honoured the golden rule > of "thou shalt enclose some good examples with your application". > Luv it :) Well, it turned out ok for a "few days" hack, eh? ;-) As to the CPU load, I suspect that the main offender here is actually the song editor, as it lacks "smart refresh" and similar optimizations. IIRC, it pretty much redraws itself completely whenever anything changes, including moving the cursor. Oh, and the FM synth isn't exactly optimized either, float<->int casts, sin() and whatnot... Plenty of cycles to save there. //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --' From david at olofson.net Fri Jan 5 03:45:07 2007 From: david at olofson.net (David Olofson) Date: Fri Jan 5 04:00:02 2007 Subject: [linux-audio-dev] Simple Jack mixing problem In-Reply-To: <57861.AQIGDV8HUH8=.1167957840.squirrel@webmail.no-log.org> References: <57861.AQIGDV8HUH8=.1167957840.squirrel@webmail.no-log.org> Message-ID: <200701050945.07681.david@olofson.net> On Friday 05 January 2007 01:44, florentberthaut@no-log.org wrote: > Hi everyone, > > I'm working on a sampler and i have a really silly problem. > > I simply want to mix sounds in a stereo buffer within the > jack "process" function. > So for each frame i sum the samples from each sound but then the > values go above 1 and i get clipping. > So my first thought was to divide by the number of samples playing, > but it ends up with a decrease in volume. > I tried to limit the values between -1 and 1 but it 's also > clipping -> distortion. Well, that's what JACK is doing anyway - or there would be wrapping in the float -> int conversion, which sounds a lot worse than clipping. It's just not possible to represent larger amplitudes than [-1, 1] in the integer domain (that is, [-32768, 32767] or whatever, depending on resolution), which is what DACs deal with. > I looked into some sources and it seems i would actually just have > to sum the samples. Yep, that's all there is to it, really - and it's the user's responsibility to keep volumes low enough to avoid driving the output into clipping. This is true on hardware synths and samplers too. The only reason some of them appears not to have this problem is that they use various tricks to hide it. For example, the old Roland JV-1080 had 18 bit DACs, where the two extra bits were pretty much used for extra headroom above the "normal" max amplitude of a single voice. Even so, it was pretty easy to drive it into clipping by using resonant filters and/or lots of loud voices. I wouldn't be surprised if some synths and samplers use 20 och 24 bit DACs for even more headroom, waveshaping to make the last 12 dB or so non-linear (soft saturation, sort of), dynamic output gain control and stuff like that. Now, if you're dealing in digital, extra DAC bits and dynamic output gain control is out, obviously. (Goes for plugins and JACK clients as well as hardware devices with digital outputs.) So, either you set your sampler's 0 dB level at -12 dB or something (allows mixing four maximized samples at maximum volume without clipping), or you leave that to the user. If you really want to make the impression sqeezing in more than there's room for, you'll have to add some dynamics processing. There is of course no way of doing this without some sort of distortion, but even a simple waveshaper to "flatten out" peaks above 12 dB below clipping sounds a great deal better than hard clipping. However, I'd rather see that kind of stuff left to the user. Those of us who use 20+ bit sound cards would rather have it all linear and undistorted right into the amplifier. There is always the option of inserting some serious multiband compressor last thing in the JACK chain. Might actually be a good idea anyway, if you like playing loud and don't want to ruin your ears if some synth or effect freaks out. //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --' From florentberthaut at no-log.org Fri Jan 5 04:21:08 2007 From: florentberthaut at no-log.org (florentberthaut@no-log.org) Date: Fri Jan 5 04:24:19 2007 Subject: [linux-audio-dev] Simple Jack mixing problem Message-ID: <63183.AQIGDV8HUH8=.1167988868.squirrel@webmail.no-log.org> Hi thanks for answering, Ok i think i'll leave it to the user, because the goal is to make a simple sampler with kit/instrument creation and control. Flo David Olofson a ?crit : > On Friday 05 January 2007 01:44, florentberthaut@no-log.org wrote: >> Hi everyone, >> >> I'm working on a sampler and i have a really silly problem. >> >> I simply want to mix sounds in a stereo buffer within the >> jack "process" function. >> So for each frame i sum the samples from each sound but then the >> values go above 1 and i get clipping. >> So my first thought was to divide by the number of samples playing, >> but it ends up with a decrease in volume. >> I tried to limit the values between -1 and 1 but it 's also >> clipping -> distortion. > > Well, that's what JACK is doing anyway - or there would be wrapping in > the float -> int conversion, which sounds a lot worse than clipping. > It's just not possible to represent larger amplitudes than [-1, 1] in > the integer domain (that is, [-32768, 32767] or whatever, depending > on resolution), which is what DACs deal with. > >> I looked into some sources and it seems i would actually just have >> to sum the samples. > > Yep, that's all there is to it, really - and it's the user's > responsibility to keep volumes low enough to avoid driving the output > into clipping. > > This is true on hardware synths and samplers too. The only reason some > of them appears not to have this problem is that they use various > tricks to hide it. > > For example, the old Roland JV-1080 had 18 bit DACs, where the two > extra bits were pretty much used for extra headroom above > the "normal" max amplitude of a single voice. Even so, it was pretty > easy to drive it into clipping by using resonant filters and/or lots > of loud voices. > > I wouldn't be surprised if some synths and samplers use 20 och 24 bit > DACs for even more headroom, waveshaping to make the last 12 dB or so > non-linear (soft saturation, sort of), dynamic output gain control > and stuff like that. > > Now, if you're dealing in digital, extra DAC bits and dynamic output > gain control is out, obviously. (Goes for plugins and JACK clients as > well as hardware devices with digital outputs.) So, either you set > your sampler's 0 dB level at -12 dB or something (allows mixing four > maximized samples at maximum volume without clipping), or you leave > that to the user. > > If you really want to make the impression sqeezing in more than > there's room for, you'll have to add some dynamics processing. There > is of course no way of doing this without some sort of distortion, > but even a simple waveshaper to "flatten out" peaks above 12 dB below > clipping sounds a great deal better than hard clipping. > > However, I'd rather see that kind of stuff left to the user. Those of > us who use 20+ bit sound cards would rather have it all linear and > undistorted right into the amplifier. There is always the option of > inserting some serious multiband compressor last thing in the JACK > chain. Might actually be a good idea anyway, if you like playing loud > and don't want to ruin your ears if some synth or effect freaks out. > > > //David Olofson - Programmer, Composer, Open Source Advocate > > .------- http://olofson.net - Games, SDL examples -------. > | http://zeespace.net - 2.5D rendering engine | > | http://audiality.org - Music/audio engine | > | http://eel.olofson.net - Real time scripting | > '-- http://www.reologica.se - Rheology instrumentation --' > From k.s.matheussen at notam02.no Fri Jan 5 05:42:12 2007 From: k.s.matheussen at notam02.no (Kjetil S. Matheussen) Date: Fri Jan 5 05:43:20 2007 Subject: [linux-audio-dev] [ANN] Das_watchdog V0.3.1 Message-ID: Download from http://www.notam02.no/arkiv/src/ Das_watchdog ============ Whenever a program locks up the machine, das_watchdog will temporarily sets all realtime process to non-realtime for 8 seconds. You will get an xmessage window up on the screen whenever that happens. Das_watchdog is made to be run as a system daemon and does not interfere with normal operations (unless the lock-ups are supposed to happen). Das_Watchdog is inspired by the rt_watchdog program made by Florian Schmidt (http://tapas.affenbande.org/?page_id=38). Changes 0.2.5->0.3.1 -------------------- *Changed scheme for finding correct XAUTHORITY environment variable. (Now works with Fedora Core 6) Hopefully, theses changes should increase the chance of seeing the xmessage and avoid seeing multiple ones. (Theres no correct way to do this, so please send me the output of "uname -a" in case you don't see any window) *Added syslogging. *Added the --version argument. From game_core at o2.pl Fri Jan 5 07:26:01 2007 From: game_core at o2.pl (kind king knight) Date: Fri Jan 5 06:25:56 2007 Subject: [linux-audio-dev] libsndfile, or audiofile? Message-ID: <1167999961.3272.2.camel@localhost.localdomain> There is not much to say. Need to know, because learning two different interfaces would be non-economical :P. From a at gaydenko.com Fri Jan 5 06:38:43 2007 From: a at gaydenko.com (Andrew Gaydenko) Date: Fri Jan 5 06:39:13 2007 Subject: [linux-audio-dev] libsndfile, or audiofile? In-Reply-To: <1167999961.3272.2.camel@localhost.localdomain> References: <1167999961.3272.2.camel@localhost.localdomain> Message-ID: <200701051438.43586@goldspace.net> Last 'audiofile' version was released almost three years ago. For my humble needings I have used 'libsndfile'. ======= On Friday 05 January 2007 15:26, kind king knight wrote: ======= There is not much to say. Need to know, because learning two different interfaces would be non-economical :P. From mle+la at mega-nerd.com Fri Jan 5 13:22:35 2007 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Fri Jan 5 13:22:53 2007 Subject: [linux-audio-dev] libsndfile, or audiofile? In-Reply-To: <1167999961.3272.2.camel@localhost.localdomain> References: <1167999961.3272.2.camel@localhost.localdomain> Message-ID: <20070106052235.79cd73e5.mle+la@mega-nerd.com> kind king knight wrote: > There is not much to say. Need to know, because learning two different > interfaces would be non-economical :P. I recommend libsndfile :-). Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ Traditional capital was stuck in a company's bank account or investments. It could not walk away in disgust. Human capital has free will. It can walk out the door; traditional capital cannot. From a at gaydenko.com Fri Jan 5 15:52:22 2007 From: a at gaydenko.com (Andrew Gaydenko) Date: Fri Jan 5 15:55:12 2007 Subject: [linux-audio-dev] block i/o scheduler for JACK Message-ID: <200701052352.22434@goldspace.net> (sorry for crossposting - have tried at LAU mailing list, but have not got any answer) Which kernel block i/o scheduler is most appropriate for JACK application? There are alternatives: Anticipatory I/O scheduler, Deadline I/O scheduler and CFQ I/O scheduler. I mean a kernel without RT-related patches. From rlrevell at joe-job.com Fri Jan 5 16:06:12 2007 From: rlrevell at joe-job.com (Lee Revell) Date: Fri Jan 5 16:05:26 2007 Subject: [linux-audio-dev] block i/o scheduler for JACK In-Reply-To: <200701052352.22434@goldspace.net> References: <200701052352.22434@goldspace.net> Message-ID: <1168031173.11404.80.camel@mindpipe> On Fri, 2007-01-05 at 23:52 +0300, Andrew Gaydenko wrote: > (sorry for crossposting - have tried at LAU mailing list, but have not got > any answer) > > Which kernel block i/o scheduler is most appropriate for JACK application? > There are alternatives: Anticipatory I/O scheduler, Deadline I/O scheduler > and CFQ I/O scheduler. I mean a kernel without RT-related patches. > Should make no difference whatsoever for JACK clients - if they're written correctly, disk IO should not perturb them. CFQ is generally the best choice all around. Lee From david at olofson.net Fri Jan 5 20:31:01 2007 From: david at olofson.net (David Olofson) Date: Fri Jan 5 20:32:48 2007 Subject: [linux-audio-dev] [ANN] EEL 0.1.11 released Message-ID: <200701060231.01841.david@olofson.net> EEL 0.1.11 released ------------------- Here we go again! Been throwing a whole lot of new code and new problems at EEL since the last release, and as you can see, we've skipped two public releases. This was part due to lack of time, and part because there were stability issues I wanted to deal with before making a public release. Most interesting changes from 0.1.8: * All relevant VM instructions can now handle up to 65536 constants. * Compiling large files with line number debug info is now a lot faster. * for i=N, N-1 ... will no longer iterate once. * 64 bit pointer issue in relocate_limbo() fixed. * Fixed octal number escape parsing in strings. * A bunch of improvements to the EELBox GUI toolkit. (Sorry about the current lack of serious examples...) * Added a DSP module, with FFT, polynomial evaluation etc. * Minor audio API improvements (mono samples and vector support. * Vectors and arrays can now be sliced, and... * ...slice() has been renamed copy(), to avoid confusion with an upcoming language feature. * MIDI input support. (Very basic and ALSA only, for now.) * A bunch of new example/test scripts. (Hey, fftsynth.eel is almost interesting! ;-) * Various bug fixes and code cleanups. ChangeLog: http://eel.olofson.net/ChangeLog Home: http://eel.olofson.net/ Downloads: http://eel.olofson.net/download.html Direct download: http://eel.olofson.net/download/EEL-0.1.11.tar.gz Win32 binary package: http://eel.olofson.net/download/EEL-0.1.11-Win32-bin.zip //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --' From nedko at arnaudov.name Mon Jan 8 09:51:29 2007 From: nedko at arnaudov.name (Nedko Arnaudov) Date: Mon Jan 8 09:47:00 2007 Subject: [linux-audio-dev] [ANN] jack_mixer version 2 Message-ID: <87odp9o9la.fsf@arnaudov.name> jack_mixer version 2 released. jack_mixer is GTK (2.x) JACK audio mixer with look similar to it`s hardware counterparts. It has lot of useful features, apart from being able to mix multiple JACK audio streams. Changes since version 1: * Fix compilation issue for 64-bit platforms (-fPIC) * Add new meter scale - iec268, fewer marks * Add hints in documentation for compiling on Ubuntu * Fix compilation with offsetof macro definition Homepage with screenshots: http://home.gna.org/jackmixer/ Download: http://download.gna.org/jackmixer/ -- Nedko Arnaudov -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20070108/87022591/attachment.bin From patrickkidd at gmail.com Mon Jan 8 03:04:59 2007 From: patrickkidd at gmail.com (Patrick Stinson) Date: Mon Jan 8 10:59:10 2007 Subject: [linux-audio-dev] integrating qt apps with common plugin interface Message-ID: <94ef510701080004p337da57do2c1bb342c3e98bc9@mail.gmail.com> has anyone gotten a qt-based gui to work with audiounits, vst, rtas, dxi, or another commercial plugin framework? cheers -- Patrick Kidd Stinson http://www.patrickkidd.com/ http://pkaudio.sourceforge.net/ http://pksampler.sourceforge.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20070107/342d9c42/attachment.html From mista.tapas at gmx.net Mon Jan 8 12:42:51 2007 From: mista.tapas at gmx.net (Florian Schmidt) Date: Mon Jan 8 13:04:41 2007 Subject: [linux-audio-dev] Re: [linux-audio-announce] [ANN] jack_mixer version 2 In-Reply-To: <87odp9o9la.fsf@arnaudov.name> References: <87odp9o9la.fsf@arnaudov.name> Message-ID: <200701081842.52036.mista.tapas@gmx.net> On Monday 08 January 2007 15:51, Nedko Arnaudov wrote: > jack_mixer version 2 released. > > jack_mixer is GTK (2.x) JACK audio mixer with look similar to it`s > hardware counterparts. It has lot of useful features, apart from being > able to mix multiple JACK audio streams. > > Changes since version 1: > > * Fix compilation issue for 64-bit platforms (-fPIC) > * Add new meter scale - iec268, fewer marks > * Add hints in documentation for compiling on Ubuntu > * Fix compilation with offsetof macro definition > > Homepage with screenshots: http://home.gna.org/jackmixer/ > > Download: http://download.gna.org/jackmixer/ works nicely.. and it has LASH :) great. Thanks, Flo -- Palimm Palimm! http://tapas.affenbande.org From game_core at o2.pl Mon Jan 8 13:50:54 2007 From: game_core at o2.pl (kind king knight) Date: Mon Jan 8 13:13:20 2007 Subject: [linux-audio-dev] integrating qt apps with common plugin interface Message-ID: <1168282254.2993.12.camel@localhost.localdomain> I don't think that vst, or dxi, are useful to work with qt, because they aren't adopted in Linux, and I don't think that windows users would bother compiling sources (for releasing compiled qt applications you must buy the qt license). Beside qt doesn't have good routines for playing sound (i am thinking about the gnu version <=3). From milan.mimica at gmail.com Mon Jan 8 17:23:17 2007 From: milan.mimica at gmail.com (Milan Mimica) Date: Mon Jan 8 17:22:44 2007 Subject: [linux-audio-dev] alsa mixing Message-ID: <45A2C455.1010308@gmail.com> Hello! We're designing a new sound subsystem for allegro game programming library, and we would like to take advantages of multiple hardware voice capabilities. On linux, ALSA is the only software that possibly could expose API for such a capability, is that right? It is possible to open multiple PCM outputs and play sound at the same time on all of them. The problem is that we miss some basic mixing features, like panning a mono sound on multichannel output for example. A similar feature is implemented as 'route' ALSA plug-in that can be specified in .asoundrc file, but it is not flexible enough. So the question is, does ALSA provide such functionality? If not, which library could? Is it possible that linux OS doesn't provide any API to take advantage of such hardware capabilities? -- Milan Mimica http://sparklet.sf.net From rj at spamatica.se Mon Jan 8 18:04:33 2007 From: rj at spamatica.se (Robert Jonsson) Date: Mon Jan 8 18:02:54 2007 Subject: [linux-audio-dev] integrating qt apps with common plugin interface In-Reply-To: <94ef510701080004p337da57do2c1bb342c3e98bc9@mail.gmail.com> References: <94ef510701080004p337da57do2c1bb342c3e98bc9@mail.gmail.com> Message-ID: <200701090004.33672.rj@spamatica.se> Hi Patrick, On Monday 08 January 2007 09:04, Patrick Stinson wrote: > has anyone gotten a qt-based gui to work with audiounits, vst, rtas, dxi, > or another commercial plugin framework? No, but why should it not work? What is the problem you are expecting, event loop interference? Regards, Robert -- http://spamatica.se/musicsite/ From rj at spamatica.se Mon Jan 8 18:10:02 2007 From: rj at spamatica.se (Robert Jonsson) Date: Mon Jan 8 18:08:25 2007 Subject: [linux-audio-dev] linux vst Message-ID: <200701090010.02463.rj@spamatica.se> Hi, I noticed that the Linux-VST site has gone online now: http://linux-vst.com /Robert -- http://spamatica.se/musicsite/ From parumi at iua.upf.edu Mon Jan 8 18:45:28 2007 From: parumi at iua.upf.edu (Pau Arumi) Date: Mon Jan 8 18:45:52 2007 Subject: [linux-audio-dev] integrating qt apps with common plugin interface In-Reply-To: <1168282254.2993.12.camel@localhost.localdomain> References: <1168282254.2993.12.camel@localhost.localdomain> Message-ID: <45A2D798.5070107@iua.upf.edu> kind king knight wrote: > I don't think that vst, or dxi, are useful to work with qt, because they > aren't adopted in Linux, and I don't think that windows users would > bother compiling sources (for releasing compiled qt applications you > must buy the qt license). Beside qt doesn't have good routines for > playing sound (i am thinking about the gnu version <=3). > I think you miss all the points: Trolltech provides a GPL version of the current Qt (4.x) for Windows. And regarding the audio capabilities of Qt, well, you couldn't care less about it when you are developing VSTs, etc. plugins, since audio is provided by the host through the process callback. Robert, I'm in the same track for the clam project http://clam.iua.upf.edu/ Currently you can automatically build a VST dll from a clam network definition. Now we want to add Qt interfaces as we do with standalone prototypes: http://iua-share.upf.es/wikis/clam/index.php/Network_Editor_tutorial We have not started doing experiments yet. However, it seems that it is possible, at least using an additional window http://lists.trolltech.com/qt-interest/2006-01/msg00332.html#msg00332 Probably the extra window is needed because that Qt (GPL Win version) doesn't give interface to adopt a (VST) window. On the other hand you can find VST plugins based on FLTK, like ZynAddSubFx, I guess FLTK can adopt windows. Please report any success on that, I'll also do. Best, Pau -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From patrickkidd at gmail.com Mon Jan 8 14:59:55 2007 From: patrickkidd at gmail.com (Patrick Stinson) Date: Tue Jan 9 08:14:24 2007 Subject: [linux-audio-dev] integrating qt apps with common plugin interface In-Reply-To: <1168282254.2993.12.camel@localhost.localdomain> References: <1168282254.2993.12.camel@localhost.localdomain> Message-ID: <94ef510701081159m3b33e22cs233948c9454735de@mail.gmail.com> I'm sorry, but that wasn't my question. We have written a large commercial app that we are going to sell, and we are looking for example code to integrate it with the stated plugin architectures.... On 1/8/07, kind king knight wrote: > > I don't think that vst, or dxi, are useful to work with qt, because they > aren't adopted in Linux, and I don't think that windows users would > bother compiling sources (for releasing compiled qt applications you > must buy the qt license). Beside qt doesn't have good routines for > playing sound (i am thinking about the gnu version <=3). > > -- Patrick Kidd Stinson http://www.patrickkidd.com/ http://pkaudio.sourceforge.net/ http://pksampler.sourceforge.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20070108/3c279818/attachment-0001.html From patrickkidd at gmail.com Mon Jan 8 18:11:22 2007 From: patrickkidd at gmail.com (Patrick Stinson) Date: Tue Jan 9 08:14:29 2007 Subject: [linux-audio-dev] integrating qt apps with common plugin interface In-Reply-To: <200701090004.33672.rj@spamatica.se> References: <94ef510701080004p337da57do2c1bb342c3e98bc9@mail.gmail.com> <200701090004.33672.rj@spamatica.se> Message-ID: <94ef510701081511h5a58d790sf543d0137b55f1aa@mail.gmail.com> event loops and graphical buffers. I'm looking for examples or tips to speed up my getting it working. On 1/8/07, Robert Jonsson wrote: > > Hi Patrick, > > On Monday 08 January 2007 09:04, Patrick Stinson wrote: > > has anyone gotten a qt-based gui to work with audiounits, vst, rtas, > dxi, > > or another commercial plugin framework? > > No, but why should it not work? > What is the problem you are expecting, event loop interference? > > Regards, > Robert > > -- > http://spamatica.se/musicsite/ > -- Patrick Kidd Stinson http://www.patrickkidd.com/ http://pkaudio.sourceforge.net/ http://pksampler.sourceforge.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20070108/416acd1e/attachment-0001.html From patrickkidd at gmail.com Mon Jan 8 19:47:03 2007 From: patrickkidd at gmail.com (Patrick Stinson) Date: Tue Jan 9 08:14:33 2007 Subject: [linux-audio-dev] integrating qt apps with common plugin interface In-Reply-To: <45A2D798.5070107@iua.upf.edu> References: <1168282254.2993.12.camel@localhost.localdomain> <45A2D798.5070107@iua.upf.edu> Message-ID: <94ef510701081647i69ea4586q4c3631c30c436682@mail.gmail.com> On 1/8/07, Pau Arumi wrote: > > kind king knight wrote: > > I don't think that vst, or dxi, are useful to work with qt, because they > > aren't adopted in Linux, and I don't think that windows users would > > bother compiling sources (for releasing compiled qt applications you > > must buy the qt license). Beside qt doesn't have good routines for > > playing sound (i am thinking about the gnu version <=3). > > > > I think you miss all the points: > Trolltech provides a GPL version of the current Qt (4.x) for Windows. > And regarding the audio capabilities of Qt, well, you couldn't care less > about it when you are developing VSTs, etc. plugins, > since audio is provided by the host through the process callback. I'll say this one more time: We have already written a qt app. That means we have the gui code finished, and we have the audio code finished. I am looking for how to integrate the gui drawing buffer and event loops. I'm not worried about the audio entry point. Robert, I'm in the same track for the clam project > http://clam.iua.upf.edu/ > Currently you can automatically build a VST dll from a clam network > definition. Now we want to add Qt interfaces as we do with standalone > prototypes: > http://iua-share.upf.es/wikis/clam/index.php/Network_Editor_tutorial > > We have not started doing experiments yet. However, it seems that it is > possible, at least using an additional window > http://lists.trolltech.com/qt-interest/2006-01/msg00332.html#msg00332 > Probably the extra window is needed because that Qt (GPL Win version) > doesn't give interface to adopt a (VST) window. > On the other hand you can find VST plugins based on FLTK, like > ZynAddSubFx, I guess FLTK can adopt windows. > > Please report any success on that, I'll also do. I will as well. I'm sure I'll post a wiki as I make progress... Best, > Pau > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > -- Patrick Kidd Stinson http://www.patrickkidd.com/ http://pkaudio.sourceforge.net/ http://pksampler.sourceforge.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20070108/d5523c00/attachment-0001.html From contact at leonard-ritter.com Tue Jan 9 18:01:29 2007 From: contact at leonard-ritter.com (Leonard Ritter) Date: Tue Jan 9 18:01:49 2007 Subject: [linux-audio-dev] linux vst In-Reply-To: <200701090010.02463.rj@spamatica.se> References: <200701090010.02463.rj@spamatica.se> Message-ID: <1168383689.5614.3.camel@localhost> wee - not. die, vst, die. On Tue, 2007-01-09 at 00:10 +0100, Robert Jonsson wrote: > Hi, > > I noticed that the Linux-VST site has gone online now: > http://linux-vst.com > > /Robert > -- Leonard Ritter -- Freelance Art & Logic -- http://www.leonard-ritter.com From pshirkey at boosthardware.com Tue Jan 9 20:19:26 2007 From: pshirkey at boosthardware.com (Patrick Shirkey) Date: Tue Jan 9 20:32:36 2007 Subject: [linux-audio-dev] alsa mixing In-Reply-To: <45A2C455.1010308@gmail.com> References: <45A2C455.1010308@gmail.com> Message-ID: <45A43F1E.6060504@boosthardware.com> Milan Mimica wrote: > Hello! > > We're designing a new sound subsystem for allegro game programming > library, and we would like to take advantages of multiple hardware voice > capabilities. > > On linux, ALSA is the only software that possibly could expose API for > such a capability, is that right? It is possible to open multiple PCM > outputs and play sound at the same time on all of them. The problem is > that we miss some basic mixing features, like panning a mono sound on > multichannel output for example. A similar feature is implemented as > 'route' ALSA plug-in that can be specified in .asoundrc file, but it is > not flexible enough. > > So the question is, does ALSA provide such functionality? If not, which > library could? Is it possible that linux OS doesn't provide any API to > take advantage of such hardware capabilities? > Surely this is a task that is up to the app to handle? You would have to provide a function to move the mono signal across the channel array accounting for volume. It would not be too difficult once the base code for the channel handling was in place. -- Patrick Shirkey - Boost Hardware Ltd. Http://www.boosthardware.com Http://lau.linuxaudio.org - The Linux Audio Users guide ======================================== "Anything your mind can see you can manifest physically, then it will become reality" - Macka B From milan.mimica at gmail.com Wed Jan 10 07:06:44 2007 From: milan.mimica at gmail.com (Milan Mimica) Date: Wed Jan 10 07:06:58 2007 Subject: [linux-audio-dev] alsa mixing In-Reply-To: <45A43F1E.6060504@boosthardware.com> References: <45A2C455.1010308@gmail.com> <45A43F1E.6060504@boosthardware.com> Message-ID: <45A4D6D4.8070809@gmail.com> Patrick Shirkey wrote: > > Surely this is a task that is up to the app to handle? That doesn't answer my question. What about unused fancy hardware? ALSA obviously has the code ('route', 'dmix' and 'plug' plug-ins), it just doesn't provide the API (or I can't find it). > You would have to provide a function to move the mono signal across the > channel array accounting for volume. It would not be too difficult once > the base code for the channel handling was in place. We do have a software mixer already. -- Milan Mimica http://sparklet.sf.net From paul at linuxaudiosystems.com Wed Jan 10 08:22:23 2007 From: paul at linuxaudiosystems.com (Paul Davis) Date: Wed Jan 10 08:23:12 2007 Subject: [linux-audio-dev] alsa mixing In-Reply-To: <45A2C455.1010308@gmail.com> References: <45A2C455.1010308@gmail.com> Message-ID: <1168435343.24499.63.camel@localhost.localdomain> On Mon, 2007-01-08 at 23:23 +0100, Milan Mimica wrote: > Hello! > > We're designing a new sound subsystem for allegro game programming > library, and we would like to take advantages of multiple hardware voice > capabilities. very few audio interfaces have this feature anymore. most h/w makers seem to assume s/w mixing and no longer provide multiple PCM h/w streams. > On linux, ALSA is the only software that possibly could expose API for > such a capability, is that right? its right and wrong. but mostly irrelevant. > It is possible to open multiple PCM > outputs and play sound at the same time on all of them. if there *are* multiple h/w PCM voices, then ALSA provides "subdevices" which get opened automatically each time you call snd_pcm_open() on a given PCM device. however, as i mentioned, not much h/w provides this any more. opening multiple PCM devices is entirely different and has its own set of problems because the devices are generally not sample clock synced. > The problem is > that we miss some basic mixing features, like panning a mono sound on > multichannel output for example. A similar feature is implemented as > 'route' ALSA plug-in that can be specified in .asoundrc file, but it is > not flexible enough. ALSA is not intended to provide any kind of live, real time signal distribution API. this is a completely app-specific domain and it would absurd for a generic HAL like ALSA to try to offer it. what you mean by "panning" and the control you want is totally different than, say, Ardour (http://ardour.org/) requires. > So the question is, does ALSA provide such functionality? If not, which > library could? Is it possible that linux OS doesn't provide any API to > take advantage of such hardware capabilities? in general, you should forget about the h/w capabilities of an audio interface. for every user that has a device with some interesting qualities, there will be 10 who do not. welcome to winmodem for audio ... --p From milan.mimica at gmail.com Wed Jan 10 08:32:20 2007 From: milan.mimica at gmail.com (Milan Mimica) Date: Wed Jan 10 08:31:44 2007 Subject: [linux-audio-dev] alsa mixing In-Reply-To: <1168435343.24499.63.camel@localhost.localdomain> References: <45A2C455.1010308@gmail.com> <1168435343.24499.63.camel@localhost.localdomain> Message-ID: <45A4EAE4.2060303@gmail.com> Paul Davis wrote: > > if there *are* multiple h/w PCM voices, then ALSA provides "subdevices" > which get opened automatically each time you call snd_pcm_open() on a > given PCM device. Yes, that's what I meant. > ALSA is not intended to provide any kind of live, real time signal > distribution API. this is a completely app-specific domain and it would > absurd for a generic HAL like ALSA to try to offer it. what you mean by > "panning" and the control you want is totally different than, say, > Ardour (http://ardour.org/) requires. OK. This is the first time I got a straight "no". Well sort a :) Thanks. -- Milan Mimica http://sparklet.sf.net From jussi.laako at pp.inet.fi Wed Jan 10 11:02:11 2007 From: jussi.laako at pp.inet.fi (Jussi Laako) Date: Wed Jan 10 11:02:31 2007 Subject: [linux-audio-dev] alsa mixing In-Reply-To: <1168435343.24499.63.camel@localhost.localdomain> References: <45A2C455.1010308@gmail.com> <1168435343.24499.63.camel@localhost.localdomain> Message-ID: <45A50E03.1010701@pp.inet.fi> Paul Davis wrote: > in general, you should forget about the h/w capabilities of an audio > interface. for every user that has a device with some interesting > qualities, there will be 10 who do not. > > welcome to winmodem for audio ... Well, in this particular case, let's just see what the generic user out there probably has. In quite a lot of cases it's some SoundBlaster Audigy2 or X-Fi variant which both have somewhat extensive signal processing capabilities (or that's what I've understood). Or you could take ancient Aureal's Vortex2 as an example. Or also rather common CMI8738 (not sure about this one). Current Linux support for these devices is limited to PCM playback/recording and possibly bare MIDI. Currently the thing we really are missing on Linux is HAL support for something like OpenAL w/ EFX (or some DirectSound3D-for-Linux type thing). Having this is somewhat crucial for game development. This is also something OpenSL ES (http://www.khronos.org/opensles/) is trying to address on embedded area. - Jussi From paul at linuxaudiosystems.com Wed Jan 10 11:22:26 2007 From: paul at linuxaudiosystems.com (Paul Davis) Date: Wed Jan 10 11:23:35 2007 Subject: [linux-audio-dev] alsa mixing In-Reply-To: <45A50E03.1010701@pp.inet.fi> References: <45A2C455.1010308@gmail.com> <1168435343.24499.63.camel@localhost.localdomain> <45A50E03.1010701@pp.inet.fi> Message-ID: <1168446146.24499.69.camel@localhost.localdomain> On Wed, 2007-01-10 at 18:02 +0200, Jussi Laako wrote: > Paul Davis wrote: > > in general, you should forget about the h/w capabilities of an audio > > interface. for every user that has a device with some interesting > > qualities, there will be 10 who do not. > > > > welcome to winmodem for audio ... > > Well, in this particular case, let's just see what the generic user out > there probably has. In quite a lot of cases it's some SoundBlaster > Audigy2 or X-Fi variant which both have somewhat extensive signal > processing capabilities (or that's what I've understood). Or you could > take ancient Aureal's Vortex2 as an example. Or also rather common > CMI8738 (not sure about this one). Current Linux support for these > devices is limited to PCM playback/recording and possibly bare MIDI. > > Currently the thing we really are missing on Linux is HAL support for > something like OpenAL w/ EFX (or some DirectSound3D-for-Linux type > thing). Having this is somewhat crucial for game development. This is > also something OpenSL ES (http://www.khronos.org/opensles/) is trying to > address on embedded area. i suspect that the generic user at this point probably has an Intel HDA device, the CMI or a SiS chipset. i'm not a game developer and i can't comment on the usefulness of DirectSound3D. it is just not used by the kinds of apps that i work on. --p From jesuswaffle at gmail.com Fri Jan 12 01:45:54 2007 From: jesuswaffle at gmail.com (nick thomas) Date: Fri Jan 12 01:46:05 2007 Subject: [linux-audio-dev] Locks or no locks? Message-ID: I apologize if this has been discussed previously on the list; Google didn't seem to be turning anything up from the list archives. I'm writing my first DSP program for JACK. My problem is this: I've got a high-priority audio synthesis thread, and a low-priority user interface thread, and they need to communicate: the UI thread needs to tell the synthesis thread to respond to the user twisting knobs and moving sliders in the interface, and the the synthesis thread needs to tell the UI thread what it's doing, so that the UI thread can update its monitoring widgets. I'm sure that this is an extremely common situation for JACK programs, and I was wondering how to handle it. I know of two possible approaches: using locks and shared memory, or using FIFOs and no shared memory. Vanilla pthreads provides direct support for the former approach, and JACK's ringbuffer interface seems to provide the necessary primitives to implement the latter approach. A lock-based system would probably be substantially simpler to implement than a lock-free one; however, I can imagine some possible priority inversion issues with a lock-based system. I don't know if that is ever a problem in practice, with real-time scheduling enabled. Anyway, there's my question: which approach (lock-based or lock-free) is generally favored for JACK programs? Thanks for helping a newbie out! From marcandre.lureau at gmail.com Wed Jan 10 11:16:49 2007 From: marcandre.lureau at gmail.com (=?ISO-8859-1?Q?Marc-Andr=E9_Lureau?=) Date: Fri Jan 12 04:40:15 2007 Subject: [linux-audio-dev] alsa mixing In-Reply-To: <45A50E03.1010701@pp.inet.fi> References: <45A2C455.1010308@gmail.com> <1168435343.24499.63.camel@localhost.localdomain> <45A50E03.1010701@pp.inet.fi> Message-ID: On 1/10/07, Jussi Laako wrote: > > Paul Davis wrote: > > welcome to winmodem for audio ... > > Well, in this particular case, let's just see what the generic user out > there probably has. In quite a lot of cases it's some SoundBlaster > Audigy2 or X-Fi variant which both have somewhat extensive signal Well, not everyone. But given that the desktop station as to sell new/better products, I would say this is still a marketing argument for any vendor. But for the laptop (and most of the developers, who run laptops and don't have money, and don't care too much), they probably have a very limited chip that does not do hw mixing. And what about HDA? Every laptop will soon support HDA. Does it means we will have more hw mixing? As I said, it seems to be a marketing argument for these technologies. Currently the thing we really are missing on Linux is HAL support for > something like OpenAL w/ EFX (or some DirectSound3D-for-Linux type > thing). Having this is somewhat crucial for game development. This is > also something OpenSL ES (http://www.khronos.org/opensles/) is trying to > address on embedded area. I feel the same, even if I would not criticize ALSA, which does "its-job". But the initial question sounded more like a gentle request for current status/state of art in linux audio. No offense here :) Good luck to the next Allegro Audio API - that is an excellent initiative (btw, you should consider a wrapper on top of PortAudio, i would suggest). -- Marc-Andr? Lureau, GSmartMix -------------- next part -------------- An HTML attachment was scrubbed... URL: http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20070110/55c0c061/attachment.html From patrickkidd at gmail.com Fri Jan 12 04:21:17 2007 From: patrickkidd at gmail.com (Patrick Stinson) Date: Fri Jan 12 04:40:21 2007 Subject: [linux-audio-dev] Locks or no locks? In-Reply-To: References: Message-ID: <94ef510701120121k15a265c4nf80ec8de9c64edb@mail.gmail.com> The skinny: - Never make a blocking call in your synth thread; there are ways around it. Using a thread lock is a blocking call. - Use atomic operations where possible and for as long as possible to avoid complicated messaging code. - Have the synth thread operate on built-in types (int, float, bool)), which can safely be set by any thread without worrying about locking. - Use a timer in the gui thread to make a callback to update widgets based on atomic values set by the synth thread. 20 ms is fine. Use a boolean to indicate that a resource has changed and should be read. This will get you through most problems. On the other hand, automating controls (as is done in most plugin architectures like vst) is something that needs to be event based from the synth thread to the ui thread, and you will need to figure out a non-blocking message queue for that. For that I leave the solution open to others in this list. On 1/11/07, nick thomas wrote: > > I apologize if this has been discussed previously on the list; Google > didn't seem to be turning anything up from the list archives. > > I'm writing my first DSP program for JACK. My problem is this: I've > got a high-priority audio synthesis thread, and a low-priority user > interface thread, and they need to communicate: the UI thread needs to > tell the synthesis thread to respond to the user twisting knobs and > moving sliders in the interface, and the the synthesis thread needs to > tell the UI thread what it's doing, so that the UI thread can update > its monitoring widgets. I'm sure that this is an extremely common > situation for JACK programs, and I was wondering how to handle it. > > I know of two possible approaches: using locks and shared memory, or > using FIFOs and no shared memory. Vanilla pthreads provides direct > support for the former approach, and JACK's ringbuffer interface seems > to provide the necessary primitives to implement the latter approach. > > A lock-based system would probably be substantially simpler to > implement than a lock-free one; however, I can imagine some possible > priority inversion issues with a lock-based system. I don't know if > that is ever a problem in practice, with real-time scheduling enabled. > > Anyway, there's my question: which approach (lock-based or lock-free) > is generally favored for JACK programs? Thanks for helping a newbie > out! > -- Patrick Kidd Stinson http://www.patrickkidd.com/ http://pkaudio.sourceforge.net/ http://pksampler.sourceforge.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20070112/b29af2db/attachment.html From nedko at arnaudov.name Fri Jan 12 08:19:11 2007 From: nedko at arnaudov.name (Nedko Arnaudov) Date: Fri Jan 12 08:20:35 2007 Subject: [linux-audio-dev] Locks or no locks? In-Reply-To: (nick thomas's message of "Fri, 12 Jan 2007 01:45:54 -0500") References: Message-ID: <87ejq0pels.fsf@arnaudov.name> "nick thomas" writes: > I apologize if this has been discussed previously on the list; Google > didn't seem to be turning anything up from the list archives. > > I'm writing my first DSP program for JACK. My problem is this: I've > got a high-priority audio synthesis thread, and a low-priority user > interface thread, and they need to communicate: the UI thread needs to > tell the synthesis thread to respond to the user twisting knobs and > moving sliders in the interface, and the the synthesis thread needs to > tell the UI thread what it's doing, so that the UI thread can update > its monitoring widgets. I'm sure that this is an extremely common > situation for JACK programs, and I was wondering how to handle it. > > I know of two possible approaches: using locks and shared memory, or > using FIFOs and no shared memory. Vanilla pthreads provides direct > support for the former approach, and JACK's ringbuffer interface seems > to provide the necessary primitives to implement the latter approach. > > A lock-based system would probably be substantially simpler to > implement than a lock-free one; however, I can imagine some possible > priority inversion issues with a lock-based system. I don't know if > that is ever a problem in practice, with real-time scheduling enabled. > > Anyway, there's my question: which approach (lock-based or lock-free) > is generally favored for JACK programs? Thanks for helping a newbie > out! > Recently I had very similar/same problem for the lv2 dynparam extension support libraries. Since I missed article explaining all possible approaches with pros and cons I tried to make one. It available here: http://nedko.arnaudov.name/wiki/moin.cgi/Accessing_data_from_audio_process_thread_and_UI_thread I plan to move it to our lad wiki once it is up, so anybody can contribute to it. This really a *draft* document, but I made it with hope that someone will find it helpful. -- Nedko Arnaudov -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20070112/869c194c/attachment.bin From dsbaikov at gmail.com Fri Jan 12 10:04:59 2007 From: dsbaikov at gmail.com (Dmitry Baikov) Date: Fri Jan 12 10:05:16 2007 Subject: [linux-audio-dev] Locks or no locks? In-Reply-To: References: Message-ID: <70a871c80701120704y431a2cc9h9ef1f71ae53662a2@mail.gmail.com> On 1/12/07, nick thomas wrote: > Anyway, there's my question: which approach (lock-based or lock-free) > is generally favored for JACK programs? Thanks for helping a newbie > out! You know th eanswer: > JACK's ringbuffer interface seems > to provide the necessary primitives to implement the latter approach. It's the best. Regards, Dmitry. From James at superbug.co.uk Fri Jan 12 23:20:34 2007 From: James at superbug.co.uk (James Courtier-Dutton) Date: Fri Jan 12 23:21:00 2007 Subject: [linux-audio-dev] alsa mixing In-Reply-To: <45A2C455.1010308@gmail.com> References: <45A2C455.1010308@gmail.com> Message-ID: <45A85E12.9070004@superbug.co.uk> Milan Mimica wrote: > Hello! > > We're designing a new sound subsystem for allegro game programming > library, and we would like to take advantages of multiple hardware > voice capabilities. > > On linux, ALSA is the only software that possibly could expose API for > such a capability, is that right? It is possible to open multiple PCM > outputs and play sound at the same time on all of them. The problem is > that we miss some basic mixing features, like panning a mono sound on > multichannel output for example. A similar feature is implemented as > 'route' ALSA plug-in that can be specified in .asoundrc file, but it > is not flexible enough. > > So the question is, does ALSA provide such functionality? If not, > which library could? Is it possible that linux OS doesn't provide any > API to take advantage of such hardware capabilities? > > For games programming, I suggest you use the OpenAL API. OpenAL will use the hardware capabilities of the sound card, if present, leaving the game to not worry if the work is done in hardware or software. One extra suggestion I would make is to make sure the game uses 48kHz audio, and not 44.1kHz audio, as not many sound cards support 44.1kHz in hardware, resulting is CPU intensive resampling. If I missunderstood what you are doing, and you instead wish to implement your own OpenAL type API, then you can ask alsa-lib to tell you how many channels the hardware can mix together. James From milan.mimica at gmail.com Sat Jan 13 06:59:43 2007 From: milan.mimica at gmail.com (Milan Mimica) Date: Sat Jan 13 06:59:00 2007 Subject: [linux-audio-dev] alsa mixing In-Reply-To: <45A85E12.9070004@superbug.co.uk> References: <45A2C455.1010308@gmail.com> <45A85E12.9070004@superbug.co.uk> Message-ID: <45A8C9AF.6050504@gmail.com> James Courtier-Dutton wrote: > > If I missunderstood what you are doing, and you instead wish to > implement your own OpenAL type API, then you can ask alsa-lib to tell > you how many channels the hardware can mix together. Allegro provides a unified API to various sound interfaces on various platforms. The programmer (or the user) can choose from several output drivers: ALSA, OSS, arts, JACK, OpenAL, DicestSound, ... But none of those is required though! We already have a OpenAL wrapper implemented and OpenAL provides all we need. Now we would like to the same thing with ALSA, because ALSA is more common on linux installations than OpenAL. Of course, we can do it with our software mixer + ALSA, but we where thinking of leaving mixing to the hardware if possible. > For games programming, I suggest you use the OpenAL API. > OpenAL will use the hardware capabilities of the sound card, if present, > leaving the game to not worry if the work is done in hardware or software. OpenAL can use hardware capabilities of the sound card? Hm, can it do mixing in hardware too? Maybe I just have to check how do they implement it in linux. > One extra suggestion I would make is to make sure the game uses 48kHz > audio, and not 44.1kHz audio, as not many sound cards support 44.1kHz in > hardware, resulting is CPU intensive resampling. It's up to the programmer (library user) to decide which sample rate to use. -- Milan Mimica http://sparklet.sf.net From James at superbug.co.uk Sat Jan 13 18:15:30 2007 From: James at superbug.co.uk (James Courtier-Dutton) Date: Sat Jan 13 18:16:39 2007 Subject: [linux-audio-dev] alsa mixing In-Reply-To: <45A8C9AF.6050504@gmail.com> References: <45A2C455.1010308@gmail.com> <45A85E12.9070004@superbug.co.uk> <45A8C9AF.6050504@gmail.com> Message-ID: <45A96812.3050100@superbug.co.uk> Milan Mimica wrote: > > > For games programming, I suggest you use the OpenAL API. > > OpenAL will use the hardware capabilities of the sound card, if > present, > > leaving the game to not worry if the work is done in hardware or > software. > > OpenAL can use hardware capabilities of the sound card? Hm, can it do > mixing in hardware too? Maybe I just have to check how do they > implement it in linux. > If "mixing in hardware" is one of the "hardware capabilities", then yes. Not all sound cards can do hardware mixing. If these are ALSA specific questions, then you might do better asking on the alsa-user mailing list instead of this one. ALSA presents a very simple picture regarding hardware mixing. If the device has more than one sub PCM device, it can do hardware mixing. /proc/asound/card0/pcm0p Then "ls" will display the sub devices. There is an api call to retrieve it as a simple integer, but I don't remember the call off hand. I.e. return 1 for not hardware mixing, and >1 for hardware mixing, with the returned integer indicating how many channels can be mixed together in hardware. To do the hardware mixing, one simply opens the alsa device name, e.g. "plug:front" multiple times, and the hardware will mix them together. Do not use the alsa device names starting with hw: . These are for use internally by alsa-lib, and should not be used by applications. Is that what you need? James From milan.mimica at gmail.com Sat Jan 13 19:09:39 2007 From: milan.mimica at gmail.com (Milan Mimica) Date: Sat Jan 13 19:08:58 2007 Subject: [linux-audio-dev] alsa mixing In-Reply-To: <45A96812.3050100@superbug.co.uk> References: <45A2C455.1010308@gmail.com> <45A85E12.9070004@superbug.co.uk> <45A8C9AF.6050504@gmail.com> <45A96812.3050100@superbug.co.uk> Message-ID: <45A974C3.6010702@gmail.com> James Courtier-Dutton wrote: > > To do the hardware mixing, one simply opens the alsa device name, e.g. > "plug:front" multiple times, and the hardware will mix them together. I know so far. But I would like to get a bit more from ALSA. For example, open a 'slave' 2-ch device, and open some mono subdevices that will be 'routed' to that slave, according to 'route table'. ...If you're familiar with ALSA terminology. Something similar can be done using .asoundrc configuration file, so I assume that the code exists. Furthermore, there is ALSA plug-in API that lets me create a 'routed' subdevice. The only problem is that, once set, the 'route table' cannot be changed. As it has been said in this thread, this is probably out of ALSA's domain. -- Milan Mimica http://sparklet.sf.net From pshirkey at boosthardware.com Sun Jan 14 07:04:51 2007 From: pshirkey at boosthardware.com (Patrick Shirkey) Date: Sun Jan 14 07:26:07 2007 Subject: [linux-audio-dev] Saving gtk slider settings In-Reply-To: <45A974C3.6010702@gmail.com> References: <45A2C455.1010308@gmail.com> <45A85E12.9070004@superbug.co.uk> <45A8C9AF.6050504@gmail.com> <45A96812.3050100@superbug.co.uk> <45A974C3.6010702@gmail.com> Message-ID: <45AA1C63.7000306@boosthardware.com> Hi, I'm looking at the save feature for jackeq and haven't found an easy to grok example of saving the standard gtk slider settings. Can someone point me to a specific function that saves the settings for standard gtk2 sliders. Cheers. -- Patrick Shirkey - Boost Hardware Ltd. Http://www.boosthardware.com Http://lau.linuxaudio.org - The Linux Audio Users guide ======================================== "Anything your mind can see you can manifest physically, then it will become reality" - Macka B From ico at vt.edu Sun Jan 14 17:23:25 2007 From: ico at vt.edu (Ivica Ico Bukvic) Date: Sun Jan 14 17:24:28 2007 Subject: [linux-audio-dev] lists.linuxaudio.org migration complete, time to consolidate LAD/LAU/LAA? Message-ID: <00bd01c7382a$9c1210c0$0202a8c0@64BitBadass> Greetings all, I am pleased to announce that the consortium lists have been migrated from the agnula domain and are fully functioning. They can be accessed via lists.linuxaudio.org. This important migration will greatly simplify further consolidation of online resources. Given that there was some discussion about this before which has elicited positive feedback, in an effort to consolidate online resources please consider this an open call to LAU/LAD/LAA maintainer(s) to consider migrating lists to the lists.linuxaudio.org. Provided that there is still interest for such a move, the consortium will provide you with necessary help to make migration as seamless as possible. Furthermore, linuxaudio.org in conjunction with Virginia Tech will provide: 1) virtually unlimited bandwidth 2) generous disk space 3) the necessary access to maintainers 4) the assurance that no institutional, logistical, and/or any other kind of control will be exerted over the mailing lists, respective maintainers and subscribers The list of current online resources hosted by linuxaudio.org can be found at portal.linuxaudio.org. I sincerely hope that the community will support this important milestone towards consolidation of Linux audio online resources. Should you happen to have any additional questions and/or concerns, please do not hesitate to contact me. Best wishes, Ivica Ico Bukvic, D.M.A. Linuxaudio.org Director Virginia Tech Department of Music - 0240 Blacksburg, VA 24061 (540) 231-1137 (540) 231-5034 (fax) ico@linuxaudio.org http://www.music.vt.edu/people/faculty/bukvic From dlphillips at woh.rr.com Mon Jan 15 09:20:33 2007 From: dlphillips at woh.rr.com (Dave Phillips) Date: Mon Jan 15 09:07:10 2007 Subject: [linux-audio-dev] an relevant link about Vista Message-ID: <45AB8DB1.1050307@woh.rr.com> Greetings: This link may have been posted here before now, but it bears repetition : http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt Nasty stuff planned in Redmond. Best, dp From gene.heskett at verizon.net Mon Jan 15 09:34:28 2007 From: gene.heskett at verizon.net (Gene Heskett) Date: Mon Jan 15 09:35:03 2007 Subject: [linux-audio-dev] an relevant link about Vista In-Reply-To: <45AB8DB1.1050307@woh.rr.com> References: <45AB8DB1.1050307@woh.rr.com> Message-ID: <200701150934.28935.gene.heskett@verizon.net> On Monday 15 January 2007 09:20, Dave Phillips wrote: >Greetings: > >This link may have been posted here before now, but it bears repetition > : > > http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt > >Nasty stuff planned in Redmond. > >Best, > >dp Thanks Dave, saved. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2007 by Maurice Eugene Heskett, all rights reserved. From lars.luthman at gmail.com Mon Jan 15 10:19:20 2007 From: lars.luthman at gmail.com (Lars Luthman) Date: Mon Jan 15 10:19:46 2007 Subject: [linux-audio-dev] an relevant link about Vista In-Reply-To: <200701150934.28935.gene.heskett@verizon.net> References: <45AB8DB1.1050307@woh.rr.com> <200701150934.28935.gene.heskett@verizon.net> Message-ID: <1168874360.5113.6.camel@box..lars> On Mon, 2007-01-15 at 09:34 -0500, Gene Heskett wrote: > On Monday 15 January 2007 09:20, Dave Phillips wrote: > Greetings: > This link may have been posted here before now, but it bears repetition: > http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt > Nasty stuff planned in Redmond. Encryption of bus traffic? Turning audio and video inputs on and off automatically depending on what's currently playing? Encryption of RAM pages containing audio or video before swapping them to disk? Deliberate degradation of _all_ audio and video on high quality output devices? This is evil, but it's evil in a stupid way. How could anyone who is even a tiny little bit interested in getting good performance for a reasonable price ever consider buying a system like that? It's as if McDonald's would announce that the new and improved Big Mac comes with shards of broken glass inside. --ll -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20070115/3210f461/attachment.bin From radarsat1 at gmail.com Mon Jan 15 10:32:44 2007 From: radarsat1 at gmail.com (Stephen Sinclair) Date: Mon Jan 15 10:33:39 2007 Subject: [linux-audio-dev] an relevant link about Vista In-Reply-To: <1168874360.5113.6.camel@box..lars> References: <45AB8DB1.1050307@woh.rr.com> <200701150934.28935.gene.heskett@verizon.net> <1168874360.5113.6.camel@box..lars> Message-ID: <9b3e2dc20701150732q78301454u7cb96ba4d5ec52e1@mail.gmail.com> > It's as if > McDonald's would announce that the new and improved Big Mac comes with > shards of broken glass inside. .... best.... DRM.... analogy...... ever. steve From dlphillips at woh.rr.com Mon Jan 15 11:32:53 2007 From: dlphillips at woh.rr.com (Dave Phillips) Date: Mon Jan 15 11:19:26 2007 Subject: [linux-audio-dev] an relevant link about Vista In-Reply-To: <0JBX00FAY1D2ZU@ms-mss-05.columbus.rr.com> References: <45AB8DB1.1050307@woh.rr.com> <200701150934.28935.gene.heskett@verizon.net> <0JBX00FAY1D2ZU@ms-mss-05.columbus.rr.com> Message-ID: <45ABACB5.8010909@woh.rr.com> Lars Luthman wrote: >It's as if McDonald's would announce that the new and improved Big Mac comes with >shards of broken glass inside. > > Well, in America at least you can convince people to eat anything, and you can train them to like it and ask for more. Literal and figurative examples abound. Best, dp From mobarre at gmail.com Mon Jan 15 11:50:14 2007 From: mobarre at gmail.com (Marc-Olivier Barre) Date: Mon Jan 15 11:51:25 2007 Subject: [linux-audio-dev] Re: lists.linuxaudio.org migration complete, time to consolidate LAD/LAU/LAA? In-Reply-To: <00bd01c7382a$9c1210c0$0202a8c0@64BitBadass> References: <00bd01c7382a$9c1210c0$0202a8c0@64BitBadass> Message-ID: <3c808a150701150850k1dccbd16ge1037d357257b29@mail.gmail.com> > Greetings all, > > I am pleased to announce that the consortium lists have been migrated from > the agnula domain and are fully functioning. They can be accessed via > lists.linuxaudio.org. This important migration will greatly simplify further > consolidation of online resources. > > Given that there was some discussion about this before which has elicited > positive feedback, in an effort to consolidate online resources please > consider this an open call to LAU/LAD/LAA maintainer(s) to consider > migrating lists to the lists.linuxaudio.org. Provided that there is still > interest for such a move, the consortium will provide you with necessary > help to make migration as seamless as possible. Furthermore, linuxaudio.org > in conjunction with Virginia Tech will provide: > > 1) virtually unlimited bandwidth > 2) generous disk space > 3) the necessary access to maintainers > 4) the assurance that no institutional, logistical, and/or any other kind of > control will be exerted over the mailing lists, respective maintainers and > subscribers > > The list of current online resources hosted by linuxaudio.org can be found > at portal.linuxaudio.org. > > I sincerely hope that the community will support this important milestone > towards consolidation of Linux audio online resources. > > Should you happen to have any additional questions and/or concerns, please > do not hesitate to contact me. > > Best wishes, I do not have any objections to this, and I am willing to continue the administration tasks on these new servers if the migration is voted by the other members. Also, I would like to discuss with you (ico) some setup specifics I would like to see implemented, mostly about automatic spam filtering, which is a huge problem on LAA. I know you guys don't see it, but believe me... ;-) __________________ Marc-Olivier Barre, Markinoko. From ico at vt.edu Mon Jan 15 12:08:08 2007 From: ico at vt.edu (Ivica Ico Bukvic) Date: Mon Jan 15 12:08:59 2007 Subject: [linux-audio-dev] RE: lists.linuxaudio.org migration complete, time to consolidate LAD/LAU/LAA? In-Reply-To: <3c808a150701150850k1dccbd16ge1037d357257b29@mail.gmail.com> Message-ID: <002801c738c7$bc927270$0202a8c0@64BitBadass> > I do not have any objections to this, and I am willing to continue the > administration tasks on these new servers if the migration is voted by > the other members. > > Also, I would like to discuss with you (ico) some setup specifics I > would like to see implemented, mostly about automatic spam filtering, > which is a huge problem on LAA. I know you guys don't see it, but > believe me... ;-) Yes, I can only imagine how much junk you have to read through... FWIW, you can set up the listserv so that it simply discards stuff from unsubscribed posters. This would fix LAA as well and as such it seems to me like a reasonable compromise since spammers in most cases are not subscribed to the list and if a poster really wants to post on a particular list they might as well subscribe to it. I am sure there may be some who would disagree with this kind of a policy and thus I think it is ultimately up to you to decide what you deem best solution/compromise. Best wishes, Ico From richard.spindler at gmail.com Mon Jan 15 14:00:24 2007 From: richard.spindler at gmail.com (Richard Spindler) Date: Mon Jan 15 14:03:40 2007 Subject: [linux-audio-dev] an relevant link about Vista In-Reply-To: <45AB8DB1.1050307@woh.rr.com> References: <45AB8DB1.1050307@woh.rr.com> Message-ID: <4af8d6ff0701151100q14e10ea9j1bb5162592079db1@mail.gmail.com> 2007/1/15, Dave Phillips : > This link may have been posted here before now, but it bears repetition : > > http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt > > Nasty stuff planned in Redmond. It seems as if we will have to build our own hardware sooner or later. Actually I am already planning a little homebrew audio-hardware project. ;-) I will write up a little summary and post it soon. Cheers -Richard -- Are you teaching the What and the How but without the Why and the When? From paul at linuxaudiosystems.com Mon Jan 15 14:09:03 2007 From: paul at linuxaudiosystems.com (Paul Davis) Date: Mon Jan 15 14:11:22 2007 Subject: [linux-audio-dev] an relevant link about Vista In-Reply-To: <4af8d6ff0701151100q14e10ea9j1bb5162592079db1@mail.gmail.com> References: <45AB8DB1.1050307@woh.rr.com> <4af8d6ff0701151100q14e10ea9j1bb5162592079db1@mail.gmail.com> Message-ID: <1168888143.2935.103.camel@localhost.localdomain> On Mon, 2007-01-15 at 20:00 +0100, Richard Spindler wrote: > 2007/1/15, Dave Phillips : > > This link may have been posted here before now, but it bears repetition : > > > > http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt > > > > Nasty stuff planned in Redmond. > > It seems as if we will have to build our own hardware sooner or later. you don't really think that pro-audio people will settle for this crap do you? the market for their equipment might be small and overpriced, but it won't go away. From richard.spindler at gmail.com Mon Jan 15 14:19:27 2007 From: richard.spindler at gmail.com (Richard Spindler) Date: Mon Jan 15 14:19:34 2007 Subject: [linux-audio-dev] an relevant link about Vista In-Reply-To: <1168888143.2935.103.camel@localhost.localdomain> References: <45AB8DB1.1050307@woh.rr.com> <4af8d6ff0701151100q14e10ea9j1bb5162592079db1@mail.gmail.com> <1168888143.2935.103.camel@localhost.localdomain> Message-ID: <4af8d6ff0701151119v5865f7b6t900d05c1b5f5223b@mail.gmail.com> 2007/1/15, Paul Davis : > > It seems as if we will have to build our own hardware sooner or later. > > you don't really think that pro-audio people will settle for this crap > do you? the market for their equipment might be small and overpriced, > but it won't go away. Sure, but there should be a choice of non-crippled, non-pro audio hardware. IMHO -Richard -- Are you teaching the What and the How but without the Why and the When? From richard.spindler at gmail.com Mon Jan 15 14:27:49 2007 From: richard.spindler at gmail.com (Richard Spindler) Date: Mon Jan 15 14:46:25 2007 Subject: [linux-audio-dev] an relevant link about Vista In-Reply-To: <1168888143.2935.103.camel@localhost.localdomain> References: <45AB8DB1.1050307@woh.rr.com> <4af8d6ff0701151100q14e10ea9j1bb5162592079db1@mail.gmail.com> <1168888143.2935.103.camel@localhost.localdomain> Message-ID: <4af8d6ff0701151127y18393a66wdd3212fce50e42ae@mail.gmail.com> 2007/1/15, Paul Davis : > > It seems as if we will have to build our own hardware sooner or later. > > you don't really think that pro-audio people will settle for this crap > do you? the market for their equipment might be small and overpriced, > but it won't go away. btw. I'm quite sure that what is outlined in the link is highly unlikely to ever happen, but one should keep himself all options open. -Richard -- Are you teaching the What and the How but without the Why and the When? From gene.heskett at verizon.net Mon Jan 15 16:28:46 2007 From: gene.heskett at verizon.net (Gene Heskett) Date: Mon Jan 15 16:53:28 2007 Subject: [linux-audio-dev] an relevant link about Vista In-Reply-To: <9b3e2dc20701150732q78301454u7cb96ba4d5ec52e1@mail.gmail.com> References: <45AB8DB1.1050307@woh.rr.com> <1168874360.5113.6.camel@box..lars> <9b3e2dc20701150732q78301454u7cb96ba4d5ec52e1@mail.gmail.com> Message-ID: <200701151628.46851.gene.heskett@verizon.net> On Monday 15 January 2007 10:32, Stephen Sinclair wrote: >> It's as if >> McDonald's would announce that the new and improved Big Mac comes with >> shards of broken glass inside. > >.... best.... DRM.... analogy...... ever. > Amen Steve. Damn I wish I'd written that... -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2007 by Maurice Eugene Heskett, all rights reserved. From dominique.michel at citycable.ch Mon Jan 15 16:30:56 2007 From: dominique.michel at citycable.ch (Dominique Michel) Date: Mon Jan 15 17:12:57 2007 Subject: [linux-audio-dev] an relevant link about Vista In-Reply-To: <45AB8DB1.1050307@woh.rr.com> References: <45AB8DB1.1050307@woh.rr.com> Message-ID: <20070115223056.123ebe08@localhost> Nasty reading, but thanks anyway. It confirm at I was wrong: the Vista ready boxes will be even worst as what I was thinking. But I am not surprised from a society that have its biggest complex outside the US in the little apartheid state of Isra?l. Dominique From waz at easynet.co.uk Mon Jan 15 22:13:22 2007 From: waz at easynet.co.uk (Wayne Myers) Date: Mon Jan 15 22:16:44 2007 Subject: [linux-audio-dev] an relevant link about Vista In-Reply-To: <20070115223056.123ebe08@localhost> References: <45AB8DB1.1050307@woh.rr.com> <20070115223056.123ebe08@localhost> Message-ID: <20070116031322.0c33c628@localhost.localdomain> > But I am not surprised from a society that have its biggest complex outside the > US in the little apartheid state of Isra?l. I'm not a fan of Microsoft either, but I do not believe there is any place for your extremely contentious political opinions with regard to the Middle East on this list. At all. You are of course entirely free to express those opinions, but you might try choosing a forum where they are in some way relevant to discussion, or, indeed, wanted. Cheers, Wayne -- Wayne Myers http://www.waz.easynet.co.uk/ http://www.conniptions.org/ From viceic at net2000.ch Tue Jan 16 02:31:01 2007 From: viceic at net2000.ch (Predrag Viceic) Date: Tue Jan 16 02:31:50 2007 Subject: [linux-audio-dev] LAD/LAU/LAA/Consortium/... Message-ID: <200701160831.03123.viceic@net2000.ch> Hi, Sorry for crossposting, which is intentional. See below ;) I personally think that this multiplication of LA lists is not a good thing. The idea, proposed by Ivica, which politely suggests the migration of all those lists to an unique one seems very good to me. I would even suggest the usage of a forum (? la php-forum) for information sharing. Those forums would allow multiple topics (LAD, LAA, LAU, Ardour, Rosegarden, MuSE, Jack, ... ) and in the same time facilitate the research, the tracking of topics and the most important thing, would allow the linux newcomers to see all the work done in those lists. I hope that I'm not irritating anyone by suggesting the above, but we are all conscious of the fact that linux audio is still a niche "market" so having an unique point of access to the posts would really be awesome. Cheers, Predrag Viceic http://freecycle.redsteamrecords.com From mobarre at gmail.com Tue Jan 16 05:42:33 2007 From: mobarre at gmail.com (Marc-Olivier Barre) Date: Tue Jan 16 05:43:04 2007 Subject: [linux-audio-dev] Re: lists.linuxaudio.org migration complete, time to consolidate LAD/LAU/LAA? In-Reply-To: <002801c738c7$bc927270$0202a8c0@64BitBadass> References: <3c808a150701150850k1dccbd16ge1037d357257b29@mail.gmail.com> <002801c738c7$bc927270$0202a8c0@64BitBadass> Message-ID: <3c808a150701160242j10e57510s29650f74e1a70769@mail.gmail.com> On 1/15/07, Ivica Ico Bukvic wrote: > FWIW, you can set up the listserv so that it simply discards stuff from > unsubscribed posters. This would fix LAA as well and as such it seems to me > like a reasonable compromise since spammers in most cases are not subscribed > to the list and if a poster really wants to post on a particular list they > might as well subscribe to it. > > I am sure there may be some who would disagree with this kind of a policy > and thus I think it is ultimately up to you to decide what you deem best > solution/compromise. Yes I did think about this. The best solution would be a slight modification to the listserv to be able to filter things out based on the subject line. Most people posting on the list add an [ANN] header to their mail, which is a good practice and could lead to auto-acceptation of there mail. spamassassin adds a *** JUNK MAIL *** header which could lead to an auto-reject. The rest could be subject to moderation with the possibility to feed new emails to spamassassin to make it's filtering more accurate. I would be surprised if no one ever thought about that... It's about the same work flow as in a email client running some smart spam filter (Thunderbird for instance). __________________ Marc-Olivier Barre, Markinoko. From mobarre at gmail.com Tue Jan 16 05:44:59 2007 From: mobarre at gmail.com (Marc-Olivier Barre) Date: Tue Jan 16 05:45:56 2007 Subject: [linux-audio-dev] an relevant link about Vista In-Reply-To: <20070116031322.0c33c628@localhost.localdomain> References: <45AB8DB1.1050307@woh.rr.com> <20070115223056.123ebe08@localhost> <20070116031322.0c33c628@localhost.localdomain> Message-ID: <3c808a150701160244i65d470bbhee5cb17127059a31@mail.gmail.com> On 1/16/07, Wayne Myers wrote: > > But I am not surprised from a society that have its biggest complex > outside the > > US in the little apartheid state of Isra?l. > > I'm not a fan of Microsoft either, but I do not believe there is any > place for your extremely contentious political opinions with regard to > the Middle East on this list. At all. > We need more moderators on the list, mail me ;-) __________________ Marc-Olivier Barre, Markinoko. From damon at karuna.eclipse.co.uk Tue Jan 16 07:05:53 2007 From: damon at karuna.eclipse.co.uk (Damon Chaplin) Date: Tue Jan 16 07:06:36 2007 Subject: [linux-audio-dev] Recommended books for new audio developers Message-ID: <1168949153.3117.12.camel@localhost.localdomain> Hi, What are the recommended books to read for people new to audio development? (Covering things like synthesis techniques, effects processing and basic acoustics stuff.) On the bottom of the Documentation section of linux-sound.org I found these 2: Computer Music Tutorial by Curtis Roads (1995, 1254 pages) Computer Music: Synthesis, Composition, and Performance by Charles Dodge and Thomas Jerse (1997, 480 pages) Though they seem quite old. Is there anything newer or better? I guess for Linux-specific issues you have to read the docs/source for things like ALSA, Jack, LADSPA/LV2, DSSI & LASH. Damon From dlphillips at woh.rr.com Tue Jan 16 07:30:13 2007 From: dlphillips at woh.rr.com (Dave Phillips) Date: Tue Jan 16 07:16:31 2007 Subject: [linux-audio-dev] Recommended books for new audio developers In-Reply-To: <1168949153.3117.12.camel@localhost.localdomain> References: <1168949153.3117.12.camel@localhost.localdomain> Message-ID: <45ACC555.3090305@woh.rr.com> Damon Chaplin wrote: >What are the recommended books to read for people new to audio >development? (Covering things like synthesis techniques, effects >processing and basic acoustics stuff.) > >On the bottom of the Documentation section of linux-sound.org I found >these 2: > >Computer Music Tutorial > by Curtis Roads (1995, 1254 pages) > > A misnamed classic. It's no tutorial, but it is crammed with information. However, it's not really targeted to developers. >Computer Music: Synthesis, Composition, and Performance > by Charles Dodge and Thomas Jerse (1997, 480 pages) > > You might get more from this one. It's the one I recommend to newbies to computer-assisted sound design and music-making. >Though they seem quite old. Is there anything newer or better? > > There are numerous texts on DSP on the Web and elsewheres, perhaps some of the engineers here will recommend a beginner's guide. >I guess for Linux-specific issues you have to read the docs/source for >things like ALSA, Jack, LADSPA/LV2, DSSI & LASH. > Yes. Alas, publishers have turned a deaf ear to suggestions for a programmer's guide to the Linux sound system. But the time is certainly right for such a guide. Best, dp From paul at linuxaudiosystems.com Tue Jan 16 07:47:35 2007 From: paul at linuxaudiosystems.com (Paul Davis) Date: Tue Jan 16 07:48:04 2007 Subject: [linux-audio-dev] Recommended books for new audio developers In-Reply-To: <45ACC555.3090305@woh.rr.com> References: <1168949153.3117.12.camel@localhost.localdomain> <45ACC555.3090305@woh.rr.com> Message-ID: <1168951655.446.1.camel@localhost.localdomain> On Tue, 2007-01-16 at 07:30 -0500, Dave Phillips wrote: > Damon Chaplin wrote: > > >What are the recommended books to read for people new to audio > >development? (Covering things like synthesis techniques, effects > >processing and basic acoustics stuff.) > > > >On the bottom of the Documentation section of linux-sound.org I found > >these 2: > > > >Computer Music Tutorial > > by Curtis Roads (1995, 1254 pages) > > > > > A misnamed classic. It's no tutorial, but it is crammed with > information. However, it's not really targeted to developers. although true, i have to stress that Roads' book was absolutely pivotal in getting me started. it provides a background, a context, a way of thinking about the goals. its certainly not useful directly for developers, but everyone writing audio software should know most (or at least a good chunk) of what is in there. From damien.cirotteau at agnula.org Tue Jan 16 09:11:24 2007 From: damien.cirotteau at agnula.org (Damien Cirotteau) Date: Tue Jan 16 09:15:38 2007 Subject: [linux-audio-dev] Recommended books for new audio developers In-Reply-To: <1168951655.446.1.camel@localhost.localdomain> References: <1168949153.3117.12.camel@localhost.localdomain> <45ACC555.3090305@woh.rr.com> <1168951655.446.1.camel@localhost.localdomain> Message-ID: <20070116151124.3edab225@poulenc> I would also recommend Introduction to Sound Processing by Davide Rocchesso (2003, 236 pages) It is less know than your 2 references but still is very good. It is not targeted to developers but cover your requirements and other sound processing related subjects (plus some useful mathematical fundamentals) As for coding there are some Matlab examples. This book has also the great advantage to be published under a Creative Commons Attribution Share-Alike license and can be downloaded for free at: http://profs.sci.univr.it/~rocchess/htmls/corsi/SoundProcessing/SoundProcessingBook/vsp.pdf You should [0] also be able to order a printed version on the publisher website: http://www.mondo-estremo.com/publications/publications/public.html damien [0] But I am not very sure that the publisher is still running. Otherwise contact the author (his email is in the pdf) On Tue, 16 Jan 2007 07:47:35 -0500 Paul Davis wrote: > On Tue, 2007-01-16 at 07:30 -0500, Dave Phillips wrote: > > Damon Chaplin wrote: > > > > >What are the recommended books to read for people new to audio > > >development? (Covering things like synthesis techniques, effects > > >processing and basic acoustics stuff.) > > > > > >On the bottom of the Documentation section of linux-sound.org I > > >found these 2: > > > > > >Computer Music Tutorial > > > by Curtis Roads (1995, 1254 pages) > > > > > > > > A misnamed classic. It's no tutorial, but it is crammed with > > information. However, it's not really targeted to developers. > > although true, i have to stress that Roads' book was absolutely > pivotal in getting me started. it provides a background, a context, a > way of thinking about the goals. its certainly not useful directly for > developers, but everyone writing audio software should know most (or > at least a good chunk) of what is in there. > ___________________________________________________________________________ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com From steiner at block4.com Tue Jan 16 09:21:53 2007 From: steiner at block4.com (Malte Steiner) Date: Tue Jan 16 09:22:24 2007 Subject: [linux-audio-dev] Recommended books for new audio developers In-Reply-To: <1168949153.3117.12.camel@localhost.localdomain> References: <1168949153.3117.12.camel@localhost.localdomain> Message-ID: <45ACDF81.7010208@block4.com> Damon Chaplin wrote: > Hi, > > What are the recommended books to read for people new to audio > development? (Covering things like synthesis techniques, effects > processing and basic acoustics stuff.) > I guess you know http://musicdsp.org/ which has tons of examples for concrete tasks like oscillators and filters, often in a portable way, read pure c or c++ so it helps you on every OS. Cheers, Malte -- Malte Steiner media art + development -www.block4.com- From steiner at block4.com Tue Jan 16 09:43:37 2007 From: steiner at block4.com (Malte Steiner) Date: Tue Jan 16 09:43:14 2007 Subject: [linux-audio-dev] LAD/LAU/LAA/Consortium/... In-Reply-To: <200701160831.03123.viceic@net2000.ch> References: <200701160831.03123.viceic@net2000.ch> Message-ID: <45ACE499.5020207@block4.com> Hello, I prefer a mailinglist over a forum but talking about information sharing, I wonder if there is a central howto page, more user oriented, which shows at one central point what and how audio stuff can be archived on Linux, what are the problems and WHY they are there (if there is one please excuse my ignorance). There is the Alsa project page which offers good hardware information, there is linux-sound.org which is an amazing ressource of links to applications but these sites assume that you know what you are searching for. I guess there are lots of people who just want to create music and look over the Windows fence but are overwhelmed by the complexity of choice and think that everything is complicated. Jacklab and Ubuntustudio is a bit in this direction. I guess it has to be a wiki and communitydriven but also has to have a certain asthetic standard to not putoff the enduser. Biggest challange now in my opinion for Open Source is enduser documentation. Adam Hydes Flossmanual http://www.flossmanuals.net is a good hit in that direction. Cheers, Malte -- Malte Steiner media art + development -www.block4.com- From pw_lists at slinkp.com Tue Jan 16 09:54:37 2007 From: pw_lists at slinkp.com (Paul Winkler) Date: Tue Jan 16 09:55:23 2007 Subject: [linux-audio-dev] Recommended books for new audio developers In-Reply-To: <1168949153.3117.12.camel@localhost.localdomain> References: <1168949153.3117.12.camel@localhost.localdomain> Message-ID: <20070116145437.GA9016@slinkp.com> I would also recommend "The Science of Musical Sound" by John Pierce. it only has a bit of material about computer music, and that is pretty light and pretty dated, but otherwise it's GREAT background for thinking about how sound works. On Tue, Jan 16, 2007 at 12:05:53PM +0000, Damon Chaplin wrote: > > Hi, > > What are the recommended books to read for people new to audio > development? (Covering things like synthesis techniques, effects > processing and basic acoustics stuff.) > > On the bottom of the Documentation section of linux-sound.org I found > these 2: > > Computer Music Tutorial > by Curtis Roads (1995, 1254 pages) > > Computer Music: Synthesis, Composition, and Performance > by Charles Dodge and Thomas Jerse (1997, 480 pages) > > Though they seem quite old. Is there anything newer or better? > > > I guess for Linux-specific issues you have to read the docs/source for > things like ALSA, Jack, LADSPA/LV2, DSSI & LASH. > > Damon -- Paul Winkler http://www.slinkp.com From dlphillips at woh.rr.com Tue Jan 16 10:14:49 2007 From: dlphillips at woh.rr.com (Dave Phillips) Date: Tue Jan 16 10:04:43 2007 Subject: [linux-audio-dev] Recommended books for new audio developers In-Reply-To: <20070116145437.GA9016@slinkp.com> References: <1168949153.3117.12.camel@localhost.localdomain> <20070116145437.GA9016@slinkp.com> Message-ID: <45ACEBE9.4040006@woh.rr.com> Paul Winkler wrote: >I would also recommend "The Science of Musical Sound" by John Pierce. > >it only has a bit of material about computer music, and that is pretty >light and pretty dated, but otherwise it's GREAT background for >thinking about how sound works. > Thanks for the reminder, Paul. I agree, it's a fine book. Recommended. Best, dp From mdeboer at iua.upf.edu Tue Jan 16 11:03:39 2007 From: mdeboer at iua.upf.edu (Maarten de Boer) Date: Tue Jan 16 11:05:51 2007 Subject: [linux-audio-dev] Recommended books for new audio developers In-Reply-To: <1168949153.3117.12.camel@localhost.localdomain> References: <1168949153.3117.12.camel@localhost.localdomain> Message-ID: <20070116170339.1027e9ba.mdeboer@iua.upf.es> Nice to see this list of recommended books growing. I'd like to add F. Richard Moore, Elements of Computer Music http://www.amazon.com/Elements-Computer-Music-Richard-Moore/dp/0132525526 (the 1 customor review sums it up pretty well) and Musical Signal Processing, 1997 Swets & Zeitlinger Publishers (it seems at the moment only the hardback is available on amazon, which makes it a bit expensive...) -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From ico at vt.edu Tue Jan 16 11:17:58 2007 From: ico at vt.edu (Ivica Ico Bukvic) Date: Tue Jan 16 11:18:33 2007 Subject: [linux-audio-user] Re: [linux-audio-dev] LAD/LAU/LAA/Consortium/... In-Reply-To: <45ACE499.5020207@block4.com> Message-ID: <007101c73989$e2fc5940$0202a8c0@64BitBadass> Oh dear... Please note that Linuxaudio.org offer does *not* suggest moving to forums. Again, let me repeat, it does *not* suggest moving to forums. It suggests moving the existing mailing lists LAD/LAU/LAA, so that they are hosted under Linuxaudio.org. They would still remain the same lists with same subscribers and same features. The only difference is that we would have them under the Linuxaudio.org umbrella. Namely, we would have linux-audio-dev@linuxaudio.org etc., instead of linux-audio-dev@music.columbia.edu. But also, more importantly, these as well as any other relevant lists that end-up being consolidated, would be found under *one* *single* URL: lists.linuxaudio.org. And that, in and of itself in my book (and I am sure in a book of any newcomer to Linux audio) would be truly priceless. Best wishes, Ico From fbar at footils.org Tue Jan 16 11:18:41 2007 From: fbar at footils.org (Frank Barknecht) Date: Tue Jan 16 11:19:49 2007 Subject: [linux-audio-dev] Recommended books for new audio developers In-Reply-To: <20070116170339.1027e9ba.mdeboer@iua.upf.es> References: <1168949153.3117.12.camel@localhost.localdomain> <20070116170339.1027e9ba.mdeboer@iua.upf.es> Message-ID: <20070116161840.GP13039@fliwatut.scifi> Hallo, Maarten de Boer hat gesagt: // Maarten de Boer wrote: > Nice to see this list of recommended books growing. I'd like > to add > > F. Richard Moore, Elements of Computer Music > > http://www.amazon.com/Elements-Computer-Music-Richard-Moore/dp/0132525526 > (the 1 customor review sums it up pretty well) I'll definitely second that one. It's still the bomb! Ciao -- Frank Barknecht _ ______footils.org_ __goto10.org__ From k.s.matheussen at notam02.no Tue Jan 16 11:43:00 2007 From: k.s.matheussen at notam02.no (Kjetil S. Matheussen) Date: Tue Jan 16 11:45:03 2007 Subject: [linux-audio-dev] an relevant link about Vista In-Reply-To: <20070116031644.B79895BC2C6C@music.columbia.edu> References: <20070116031644.B79895BC2C6C@music.columbia.edu> Message-ID: Wayne Myers: > > I'm not a fan of Microsoft either, but I do not believe there is any > place for your extremely contentious political opinions with regard to > the Middle East on this list. At all. > > You are of course entirely free to express those opinions, but you might > try choosing a forum where they are in some way relevant to discussion, > or, indeed, wanted. > Although I generally agree with you about choosing a more relevant forum, you should know that what you just wrote can be seen as just as much an extreme political opinion as well, and that you, by what you wrote, continue to nurture a potentional flame war. I don't know whether it was intentional or not. From t_w_ at freenet.de Tue Jan 16 12:09:27 2007 From: t_w_ at freenet.de (Thorsten Wilms) Date: Tue Jan 16 12:10:00 2007 Subject: [linux-audio-dev] an relevant link about Vista In-Reply-To: References: <20070116031644.B79895BC2C6C@music.columbia.edu> Message-ID: <20070116170927.GA5409@charly.SWORD> On Tue, Jan 16, 2007 at 05:43:00PM +0100, Kjetil S. Matheussen wrote: > > Wayne Myers: > > > >I'm not a fan of Microsoft either, but I do not believe there is any > >place for your extremely contentious political opinions with regard to > >the Middle East on this list. At all. > > > >You are of course entirely free to express those opinions, but you might > >try choosing a forum where they are in some way relevant to discussion, > >or, indeed, wanted. > > > > Although I generally agree with you about choosing a more relevant forum, > you should know that what you just wrote can be seen as just as much an > extreme political opinion as well, and that you, by what you wrote, > continue to nurture a potentional flame war. > > I don't know whether it was intentional or not. Yeah, and your post is much more helpfull and relevant ... just like this one ;) -- Thorsten Wilms Thorwil's Creature Illustrations: http://www.printfection.com/thorwil From mobarre at gmail.com Tue Jan 16 12:25:09 2007 From: mobarre at gmail.com (Marc-Olivier Barre) Date: Tue Jan 16 12:25:20 2007 Subject: [linux-audio-user] Re: [linux-audio-dev] LAD/LAU/LAA/Consortium/... In-Reply-To: <007101c73989$e2fc5940$0202a8c0@64BitBadass> References: <45ACE499.5020207@block4.com> <007101c73989$e2fc5940$0202a8c0@64BitBadass> Message-ID: <3c808a150701160925t164084ds98856d38853ecd1b@mail.gmail.com> On 1/16/07, Ivica Ico Bukvic wrote: > Oh dear... > > Please note that Linuxaudio.org offer does *not* suggest moving to forums. > Again, let me repeat, it does *not* suggest moving to forums. > Are you sure we should move the lists to a forum ? ;-) __________________ Marc-Olivier Barre, Markinoko. From apolinaire at poczta.fm Tue Jan 16 13:05:04 2007 From: apolinaire at poczta.fm (apolinaire@poczta.fm) Date: Tue Jan 16 13:18:57 2007 Subject: [linux-audio-dev] Recommended books for new audio developers Message-ID: <20070116180504.F1491B897@poczta.interia.pl> Let me introduce a little (IMHO) listing of readings :) Generallly, Theory of Electronic Music created by Computer: The Theory and Technique of Electronic Music (Online Book) http://crca.ucsd.edu/~msp/techniques.htm by Miller Puckette (current version is "v0.11") Electronic and computer music by MANNING Peter (2004) http://books.google.com/books? vid=ISBN0195144848&id=P2dClS4LdPQC&pg=PP1&lpg=PP1&dq=Electronic+and +computer+music Additional Resources: Musik- und Audioinformatik (course) http://www.encyclospace.org/Musikinformatik_1/ by Prof. Dr. Guerino Mazzola ___________________________________________________________ Acoustics, etc. Master Handbook of Acoustics by F. Alton (2000 - 592 pages) http://books.google.com/books?q=everest+acoustics&btnG=Search +Books&as_brr=0 The Science of Sound by Thomas D. Rossing, F. Richard Moore, Paul A. Wheeler Addison Wesley (2002) ___________________________________________________________ Perception, Cognition Music, Cognition, and ComputerizedSound by Perry R. Cook (1999 - 392 pages) http://books.google.com/books? vid=ISBN0262531909&id=L04W8ADtpQ4C&pg=PP1&lpg=PP1&ots=7fqmDaKOy5&dq=music,+cognition,+and+computerized+sound&sig=yKMxGVK7hx2MY0Bt3d2o6IAB4l0 Spatial Hearing: The Psychophysics of Human Sound Localization by Jens Blauert (1997 - 494 pages) http://books.google.com/books? vid=ISBN0262024136&id=wBiEKPhw7r0C&pg=PP1&lpg=PP1&ots=4Grc8V9Sfj&dq=spatial+hearing&sig=gn-DAIIkAIpsR4bATxe9SYc5uCc Additional Resources: http://www.cnmat.berkeley.edu/Music108/index.html ___________________________________________________________ Digital audio signal Principles of Digital Audio by Ken C. Pohlmann (2005 - 842 pages) The Art of Digital Audio by John Watkinson (1994 - 685 pages) ___________________________________________________________ Audio Signal Processing The Scientist and Engineer's Guide to Digital Signal Processing http://www.dspguide.com/ (Online Book) by Steven W. Smith Digital Audio Signal Processing by Udo Zolzer http://books.google.com/books?vid=ISBN0471972266&id=IPMhDE- QWzQC&pg=PP1&lpg=PP1&ots=RgnzD-LNaH&dq=Digital+Audio+Signal +Processing&sig=yHPLV6fpUnuIBOuW1BvePBiHaLc DAFX - Digital Audio Effects by direction Udo Zolzer http://books.google.com/books? vid=ISBN0471490784&id=h90HIV0uwVsC&pg=RA1-PA2&lpg=RA1-PA2&ots=dhzgTFs4d- &dq=audio+digital+signal+processing&sig=amsRRLktD8AfWJ97vCiMuLe4Pw8 Introduction to digital filters. (Online Book) http://ccrma.stanford.edu/~jos/filters/ by Julius O. Smith Physical Audio Signal Processing: For Virtual Musical Instruments and Audio Effects (Online Book) http://ccrma.stanford.edu/~jos/pasp/ by Julius O. Smith additional resources: http://www.bdti.com/faq/ http://www.bdti.com/articles/info_articles.htm __________________________________________________________ Audio Programming Resources http://www.harmony-central.com/Computer/Programming/ http://www.audiomulch.com/~rossb/code/music-programming/ Linux Audio Conference papers etc. 2003 http://on1.zkm.de/zkm/stories/storyReader$3027 2004 http://on1.zkm.de/zkm/stories/storyReader$3623 2005 http://lac.zkm.de/2005/ 2006 http://lac.zkm.de/2006/ __________________________________________________________ Sound Recording Sound Recording: The Life Story of a Technology by David L. Morton (2006 - 215 pages) The Art of Recording: Understanding and Crafting the Mix by William Moylan (2002 - 304 pages) The Mastering Engineer's Handbook by Bobby Owsinski, Sally Englefried (2000 - 270 pages) Mastering Audio: The Art and the Science by Bob Katz, Robert A. Katz (2002 - 319 pages) additional resources: Foundations of Sound Recording Technology http://ccrma.stanford.edu/courses/192a/ Foundations of Sound Recording Technology http://ccrma.stanford.edu/courses/192b/ >Computer Music Tutorial > by Curtis Roads (1995, 1254 pages) >Computer Music: Synthesis, Composition, and Performance > by Charles Dodge and Thomas Jerse (1997, 480 pages) > I hope you will add something:) ----------- Pawel Cyrta -- pawel.cyrta@ircam.fr ------- l'Equipe Analyse/Synthese IRCAM 1 place Stravinsky 75004 Paris FRANCE ---------------------------------------------------------------------- Nieograniczona pojemnosc skrzynki >>> http://link.interia.pl/f19e6 From ladev at sound-man.co.uk Tue Jan 16 19:02:52 2007 From: ladev at sound-man.co.uk (John Rigg) Date: Tue Jan 16 18:40:49 2007 Subject: [linux-audio-dev] Recommended books for new audio developers In-Reply-To: <20070116145437.GA9016@slinkp.com> References: <1168949153.3117.12.camel@localhost.localdomain> <20070116145437.GA9016@slinkp.com> Message-ID: <20070117000252.GA2677@localhost.localdomain> On Tue, Jan 16, 2007 at 09:54:37AM -0500, Paul Winkler wrote: > I would also recommend "The Science of Musical Sound" by John Pierce. > > it only has a bit of material about computer music, and that is pretty > light and pretty dated, but otherwise it's GREAT background for > thinking about how sound works. Ditto "Recording Studio Design" by Philip Newell. John From viceic at net2000.ch Wed Jan 17 02:05:45 2007 From: viceic at net2000.ch (Predrag Viceic) Date: Wed Jan 17 02:06:05 2007 Subject: [linux-audio-user] Re: [linux-audio-dev] LAD/LAU/LAA/Consortium/... In-Reply-To: <007101c73989$e2fc5940$0202a8c0@64BitBadass> References: <007101c73989$e2fc5940$0202a8c0@64BitBadass> Message-ID: <200701170805.45824.viceic@net2000.ch> I didn't pretend that Linuxaudio.org suggest moving to forums. Read my post. *I* suggest moving to forums as *I* think it's better way to exchange the info than those 90-tish, Mailman powered, mailing lists where you can't even search for posts or whatever. And apparently I'm not the only one that pretends that: Ardour has a forum: http://ardour.org/forum/15 Rosegarden has a forum: http://www.nabble.com/RoseGarden-f2887.html Hydrogen has a forum : http://www.hydrogen-music.org/forum/ etc. etc. etc. WFT?! even glibc has a forum !! http://www.nabble.com/Sourceware---glibc-f12198.html The idea I had in mind when talking about linux audio forums: http://www.linuxforums.org/forum/ Predrag Viceic http://freecycle.redsteamrecords.com And no, Freecycle does not have a forum because Savanah doesn't provide such tool. Disclaimer: The opinions expressed are solely mine and not of the members of linuxaudio.org "consortium". Le mardi 16 janvier 2007 17:17, Ivica Ico Bukvic a ?crit?: > Oh dear... > > Please note that Linuxaudio.org offer does *not* suggest moving to forums. > Again, let me repeat, it does *not* suggest moving to forums. > > It suggests moving the existing mailing lists LAD/LAU/LAA, so that they are > hosted under Linuxaudio.org. They would still remain the same lists with > same subscribers and same features. The only difference is that we would > have them under the Linuxaudio.org umbrella. Namely, we would have > linux-audio-dev@linuxaudio.org etc., instead of > linux-audio-dev@music.columbia.edu. But also, more importantly, these as > well as any other relevant lists that end-up being consolidated, would be > found under *one* *single* URL: lists.linuxaudio.org. And that, in and of > itself in my book (and I am sure in a book of any newcomer to Linux audio) > would be truly priceless. > > Best wishes, > > Ico From mobarre at gmail.com Wed Jan 17 05:55:59 2007 From: mobarre at gmail.com (Marc-Olivier Barre) Date: Wed Jan 17 06:05:29 2007 Subject: [linux-audio-user] Re: [linux-audio-dev] LAD/LAU/LAA/Consortium/... In-Reply-To: <200701170805.45824.viceic@net2000.ch> References: <007101c73989$e2fc5940$0202a8c0@64BitBadass> <200701170805.45824.viceic@net2000.ch> Message-ID: <3c808a150701170255p2344f013yf9f494b861ef1331@mail.gmail.com> On 1/17/07, Predrag Viceic wrote: > I didn't pretend that Linuxaudio.org suggest moving to forums. Read my post. > *I* suggest moving to forums as *I* think it's better way to exchange the info > than those 90-tish, Mailman powered, mailing lists where you can't even > search for posts or whatever. > > And apparently I'm not the only one that pretends that: > > Ardour has a forum: http://ardour.org/forum/15 > Rosegarden has a forum: http://www.nabble.com/RoseGarden-f2887.html > Hydrogen has a forum : http://www.hydrogen-music.org/forum/ > etc. etc. etc. > > WFT?! even glibc has a forum !! > http://www.nabble.com/Sourceware---glibc-f12198.html > > The idea I had in mind when talking about linux audio forums: > http://www.linuxforums.org/forum/ Ardour is a bad example : most of the serious technical stuff is either discussed on IRC or in a bug report on the tracker (which leads to more tailking on IRC...) Cheers, -- __________________ Marc-Olivier Barre, Markinoko. From dlphillips at woh.rr.com Wed Jan 17 07:22:13 2007 From: dlphillips at woh.rr.com (Dave Phillips) Date: Wed Jan 17 07:22:49 2007 Subject: [linux-audio-user] Re: [linux-audio-dev] LAD/LAU/LAA/Consortium/... In-Reply-To: <3c808a150701170255p2344f013yf9f494b861ef1331@mail.gmail.com> References: <007101c73989$e2fc5940$0202a8c0@64BitBadass> <200701170805.45824.viceic@net2000.ch> <3c808a150701170255p2344f013yf9f494b861ef1331@mail.gmail.com> Message-ID: <45AE14F5.5070305@woh.rr.com> Marc-Olivier Barre wrote: > On 1/17/07, Predrag Viceic wrote: > >> I didn't pretend that Linuxaudio.org suggest moving to forums. Read >> my post. >> *I* suggest moving to forums as *I* think it's better way to exchange >> the info >> than those 90-tish, Mailman powered, mailing lists where you can't even >> search for posts or whatever. >> >> And apparently I'm not the only one that pretends that: >> >> Ardour has a forum: http://ardour.org/forum/15 >> Rosegarden has a forum: http://www.nabble.com/RoseGarden-f2887.html >> Hydrogen has a forum : http://www.hydrogen-music.org/forum/ >> etc. etc. etc. >> >> WFT?! even glibc has a forum !! >> http://www.nabble.com/Sourceware---glibc-f12198.html >> >> The idea I had in mind when talking about linux audio forums: >> http://www.linuxforums.org/forum/ > > > Ardour is a bad example : most of the serious technical stuff is > either discussed on IRC or in a bug report on the tracker (which leads > to more tailking on IRC...) More to the point: The forums are application-specific, not general in nature. The LA* mail-lists are general, non-specific wrt applications discussed. I'm a member of a few forums that are successful, but I don't think a forum is the best comm channel for general discussion of Linux audio software use and development. IMO the mail lists function nicely now. Best, dp From radarsat1 at gmail.com Wed Jan 17 12:57:05 2007 From: radarsat1 at gmail.com (Stephen Sinclair) Date: Wed Jan 17 12:59:49 2007 Subject: [linux-audio-user] Re: [linux-audio-dev] LAD/LAU/LAA/Consortium/... In-Reply-To: <200701170805.45824.viceic@net2000.ch> References: <007101c73989$e2fc5940$0202a8c0@64BitBadass> <200701170805.45824.viceic@net2000.ch> Message-ID: <9b3e2dc20701170957w2020dddrcd41e64cbb704ff9@mail.gmail.com> > *I* suggest moving to forums as *I* think it's better way to exchange the info > than those 90-tish, Mailman powered, mailing lists where you can't even > search for posts or whatever. Personally, ever since switching to gmail which handles lists using tags and has excellent searching capabilities, I far prefer lists over forums/boards. However, I think it's sort of silly to have to chose at all. Mailing lists and boards are so similar, there's no reason you can't just have both. For instance, there is a plugin for phpBB that allows people to sign up to the board and treat it like a mailing list. Of course, since mailman is probably a better mailing list handler than phpBB, it would be better to have some sort of web-based interface to the mailing lists (still handled by mailman), accessible through linuxaudio.org. Anyone know of a good solution for that? By the way, there is at least the risk that web-accessible forums will increase spam risks. Usually requiring registration helps with that, but I don't know if its enough. Steve From cannam at all-day-breakfast.com Wed Jan 17 13:13:29 2007 From: cannam at all-day-breakfast.com (Chris Cannam) Date: Wed Jan 17 13:17:35 2007 Subject: [linux-audio-user] Re: [linux-audio-dev] LAD/LAU/LAA/Consortium/... In-Reply-To: <200701170805.45824.viceic@net2000.ch> References: <007101c73989$e2fc5940$0202a8c0@64BitBadass> <200701170805.45824.viceic@net2000.ch> Message-ID: <200701171813.30057.cannam@all-day-breakfast.com> On Wednesday 17 Jan 2007 07:05, Predrag Viceic wrote: > Rosegarden has a forum: http://www.nabble.com/RoseGarden-f2887.html FWIW Rosegarden doesn't have a forum -- the above is a web gateway to its user mailing list. It's OK for reading, but not much cop for posting. Chris From david at olofson.net Wed Jan 17 13:23:39 2007 From: david at olofson.net (David Olofson) Date: Wed Jan 17 13:25:50 2007 Subject: [linux-audio-user] Re: [linux-audio-dev] LAD/LAU/LAA/Consortium/... In-Reply-To: <9b3e2dc20701170957w2020dddrcd41e64cbb704ff9@mail.gmail.com> References: <007101c73989$e2fc5940$0202a8c0@64BitBadass> <200701170805.45824.viceic@net2000.ch> <9b3e2dc20701170957w2020dddrcd41e64cbb704ff9@mail.gmail.com> Message-ID: <200701171923.39639.david@olofson.net> On Wednesday 17 January 2007 18:57, Stephen Sinclair wrote: [...] > For instance, there is a plugin for phpBB that allows people to sign > up to the board and treat it like a mailing list. Of course, since > mailman is probably a better mailing list handler than phpBB, it > would be better to have some sort of web-based interface to the > mailing lists (still handled by mailman), accessible through > linuxaudio.org. > > Anyone know of a good solution for that? Not much experience with using this; just noticed that SDL and some other lists are wired to it: http://gmane.org/ //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --' From contact at leonard-ritter.com Wed Jan 17 14:37:37 2007 From: contact at leonard-ritter.com (Leonard Ritter) Date: Wed Jan 17 14:38:24 2007 Subject: [linux-audio-dev] an relevant link about Vista In-Reply-To: <20070115223056.123ebe08@localhost> References: <45AB8DB1.1050307@woh.rr.com> <20070115223056.123ebe08@localhost> Message-ID: <1169062657.5577.2.camel@localhost> On Mon, 2007-01-15 at 22:30 +0100, Dominique Michel wrote: > But I am not surprised from a society that have its biggest complex outside the > US in the little apartheid state of Isra?l. oh damn what kind of jokes i would make to drive this absurd statement even further, but i'm afraid of being banned ;) i hope you're just having a very sinister type of black humour. :D > > Dominique -- Leonard Ritter -- Freelance Art & Logic -- http://www.leonard-ritter.com From contact at leonard-ritter.com Wed Jan 17 14:38:15 2007 From: contact at leonard-ritter.com (Leonard Ritter) Date: Wed Jan 17 14:39:14 2007 Subject: [linux-audio-dev] an relevant link about Vista In-Reply-To: <20070116170927.GA5409@charly.SWORD> References: <20070116031644.B79895BC2C6C@music.columbia.edu> <20070116170927.GA5409@charly.SWORD> Message-ID: <1169062695.5577.4.camel@localhost> On Tue, 2007-01-16 at 18:09 +0100, Thorsten Wilms wrote: > > I don't know whether it was intentional or not. > > > Yeah, and your post is much more helpfull and relevant ... > just like this one ;) fyi thorwil: your post is irrelevant as well. > > -- Leonard Ritter -- Freelance Art & Logic -- http://www.leonard-ritter.com From capocasa at gmx.net Thu Jan 18 19:40:24 2007 From: capocasa at gmx.net (Carlo Capocasa) Date: Thu Jan 18 19:50:14 2007 Subject: [linux-audio-dev] Re: an relevant link about Vista In-Reply-To: <45AB8DB1.1050307@woh.rr.com> References: <45AB8DB1.1050307@woh.rr.com> Message-ID: Whew. Big Brother is disabling your hardware. Quite an irony how short Bill Gates is. Carlo From mobarre at gmail.com Fri Jan 19 05:51:51 2007 From: mobarre at gmail.com (Marc-Olivier Barre) Date: Fri Jan 19 05:52:10 2007 Subject: [Consortium] Re: [linux-audio-user] Re: [linux-audio-dev] LAD/LAU/LAA/Consortium/... In-Reply-To: <1169184347.5593.19.camel@localhost> References: <007101c73989$e2fc5940$0202a8c0@64BitBadass> <200701170811.37838.viceic@net2000.ch> <1169184347.5593.19.camel@localhost> Message-ID: <3c808a150701190251i3fba8826n5c80bc6a8d3ff1c0@mail.gmail.com> On 1/19/07, Leonard Ritter wrote: > i don't see why we need to "move" to forums. mailing lists and forums > have a different target audience and purpose. > > however i strongly support a linux audio related forum - especially for > people new to the subject or searching for help (right now they turn up > on irc in order to make fools out of themselves), an aggregation of > knowledge in form of organizable threads that can be browsed wouldn't be > such a terrible idea. > > "we need one because others have one" is a stupid argument. there are > far better arguments for a forum. > > i think all that is needed is someone with some (security related) > experience with forums and enough time to set it up and moderate - i am > convinced ico or whoever is responsible for la.org will happily provide > resources for such an experiment. Ok, Apparently forum addicts have decided to hijack this thread though, the original question was : do you want LA* _lists_ (LIST is the keyword here, can't stress it enough) to be moved to linuxaudio.org. I have noting against the idea of a forum, the people interested in this are free to build and maintain one and eventually discuss it with Ico. I'm sure __________________ Marc-Olivier Barre, Markinoko. From mobarre at gmail.com Fri Jan 19 05:54:06 2007 From: mobarre at gmail.com (Marc-Olivier Barre) Date: Fri Jan 19 05:56:14 2007 Subject: [Consortium] Re: [linux-audio-user] Re: [linux-audio-dev] LAD/LAU/LAA/Consortium/... In-Reply-To: <3c808a150701190251i3fba8826n5c80bc6a8d3ff1c0@mail.gmail.com> References: <007101c73989$e2fc5940$0202a8c0@64BitBadass> <200701170811.37838.viceic@net2000.ch> <1169184347.5593.19.camel@localhost> <3c808a150701190251i3fba8826n5c80bc6a8d3ff1c0@mail.gmail.com> Message-ID: <3c808a150701190254y7a3e4d74o6ea02a9450d814ca@mail.gmail.com> > Ok, Apparently forum addicts have decided to hijack this thread > though, the original question was : do you want LA* _lists_ (LIST is > the keyword here, can't stress it enough) to be moved to > linuxaudio.org. > > I have noting against the idea of a forum, the people interested in > this are free to build and maintain one and eventually discuss it with > Ico. I'm sure > __________________ > Marc-Olivier Barre, > Markinoko. > Ok, I've hit the post button in the middle of my post... I was saying that I was sure a forum could help a lot of newbie not interested in a mailing list. Now could we get back to the original question and take a decision ? Cheers, -- __________________ Marc-Olivier Barre, Markinoko. From nedko at arnaudov.name Fri Jan 19 09:23:52 2007 From: nedko at arnaudov.name (Nedko Arnaudov) Date: Fri Jan 19 09:19:12 2007 Subject: [Consortium] Re: [linux-audio-user] Re: [linux-audio-dev] LAD/LAU/LAA/Consortium/... In-Reply-To: <3c808a150701190254y7a3e4d74o6ea02a9450d814ca@mail.gmail.com> (Marc-Olivier Barre's message of "Fri, 19 Jan 2007 11:54:06 +0100") References: <007101c73989$e2fc5940$0202a8c0@64BitBadass> <200701170811.37838.viceic@net2000.ch> <1169184347.5593.19.camel@localhost> <3c808a150701190251i3fba8826n5c80bc6a8d3ff1c0@mail.gmail.com> <3c808a150701190254y7a3e4d74o6ea02a9450d814ca@mail.gmail.com> Message-ID: <8764b3jds7.fsf@arnaudov.name> "Marc-Olivier Barre" writes: > Now could we get back to the original question and take a decision ? My thoughts: * It is better place because of name (columbia.edu?!?!?) (++) * It is working now, why we need to move it (--) * Isn't it be better to spend efforst on wiki instead (--) Summary: I'm not against. -- Nedko Arnaudov -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20070119/d7419f79/attachment.bin From paul at linuxaudiosystems.com Fri Jan 19 09:18:59 2007 From: paul at linuxaudiosystems.com (Paul Davis) Date: Fri Jan 19 09:19:38 2007 Subject: [Consortium] Re: [linux-audio-user] Re: [linux-audio-dev] LAD/LAU/LAA/Consortium/... In-Reply-To: <3c808a150701190254y7a3e4d74o6ea02a9450d814ca@mail.gmail.com> References: <007101c73989$e2fc5940$0202a8c0@64BitBadass> <200701170811.37838.viceic@net2000.ch> <1169184347.5593.19.camel@localhost> <3c808a150701190251i3fba8826n5c80bc6a8d3ff1c0@mail.gmail.com> <3c808a150701190254y7a3e4d74o6ea02a9450d814ca@mail.gmail.com> Message-ID: <1169216339.446.135.camel@localhost.localdomain> On Fri, 2007-01-19 at 11:54 +0100, Marc-Olivier Barre wrote: > > Ok, Apparently forum addicts have decided to hijack this thread > > though, the original question was : do you want LA* _lists_ (LIST is > > the keyword here, can't stress it enough) to be moved to > > linuxaudio.org. > > > > I have noting against the idea of a forum, the people interested in > > this are free to build and maintain one and eventually discuss it with > > Ico. I'm sure > > __________________ > > Marc-Olivier Barre, > > Markinoko. > > > > Ok, I've hit the post button in the middle of my post... I was saying > that I was sure a forum could help a lot of newbie not interested in a > mailing list. > > Now could we get back to the original question and take a decision ? votes++ for the move. From tom.berger at gmail.com Tue Jan 16 10:37:58 2007 From: tom.berger at gmail.com (Tom Berger) Date: Fri Jan 19 12:00:35 2007 Subject: [linux-audio-dev] Recommended books for new audio developers In-Reply-To: <1168949153.3117.12.camel@localhost.localdomain> References: <1168949153.3117.12.camel@localhost.localdomain> Message-ID: On 1/16/07, Damon Chaplin wrote: > > What are the recommended books to read for people new to audio > development? (Covering things like synthesis techniques, effects > processing and basic acoustics stuff.) > Try MIller Puckette's free book "Theory and Techniques of Electronic Music". It's pretty high-level and a bit pure-data centric, but it's an excellent introduction. See http://crca.ucsd.edu/~msp/techniques.htm Tom -- http://intellectronica.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20070116/464fee28/attachment.html From bengan at kthnoc.net Fri Jan 19 11:59:15 2007 From: bengan at kthnoc.net (Bengt =?iso-8859-1?q?G=F6rd=E9n?=) Date: Fri Jan 19 12:04:41 2007 Subject: [Consortium] Re: [linux-audio-user] Re: [linux-audio-dev] LAD/LAU/LAA/Consortium/... In-Reply-To: <3c808a150701190254y7a3e4d74o6ea02a9450d814ca@mail.gmail.com> References: <007101c73989$e2fc5940$0202a8c0@64BitBadass> <3c808a150701190251i3fba8826n5c80bc6a8d3ff1c0@mail.gmail.com> <3c808a150701190254y7a3e4d74o6ea02a9450d814ca@mail.gmail.com> Message-ID: <200701191759.20778.bengan@kthnoc.net> fredag 19 januari 2007 11:54 skrev Marc-Olivier Barre: > Now could we get back to the original question and take a decision ? I vote yes. -- - Bengan ------------------------------------------------------------ - KTHNOC - No1 Internet Offspring | http://www.noc.kth.se/~bengan --- - 08-7906586 (ej vidarekopplat), 070-6443325 ------------------------ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20070119/19e49c6e/attachment.bin From mobarre at gmail.com Fri Jan 19 12:32:42 2007 From: mobarre at gmail.com (Marc-Olivier Barre) Date: Fri Jan 19 12:34:10 2007 Subject: [Consortium] Re: [linux-audio-user] Re: [linux-audio-dev] LAD/LAU/LAA/Consortium/... In-Reply-To: <5bdc1c8b0701190917u27bf78abj8cacfd526b77db2b@mail.gmail.com> References: <007101c73989$e2fc5940$0202a8c0@64BitBadass> <3c808a150701190251i3fba8826n5c80bc6a8d3ff1c0@mail.gmail.com> <3c808a150701190254y7a3e4d74o6ea02a9450d814ca@mail.gmail.com> <200701191759.20778.bengan@kthnoc.net> <5bdc1c8b0701190917u27bf78abj8cacfd526b77db2b@mail.gmail.com> Message-ID: <3c808a150701190932x6eff0fcbpacae9c931f073d5b@mail.gmail.com> On 1/19/07, Mark Knecht wrote: > > By the way - one negative thing about email lists is that my response > will not be seen by everyone who saw what I'm replying to since I'm > not subscribed to all the lists on this email. > Wrong, if a non member posts on the list, it's my job to review the message and accept it if it's not spam and for LAA if and only if it's an announcement. __________________ Marc-Olivier Barre, Markinoko. From contact at leonard-ritter.com Fri Jan 19 13:35:54 2007 From: contact at leonard-ritter.com (Leonard Ritter) Date: Fri Jan 19 13:57:29 2007 Subject: [Consortium] Re: [linux-audio-user] Re: [linux-audio-dev] LAD/LAU/LAA/Consortium/... In-Reply-To: <200701191759.20778.bengan@kthnoc.net> References: <007101c73989$e2fc5940$0202a8c0@64BitBadass> <3c808a150701190251i3fba8826n5c80bc6a8d3ff1c0@mail.gmail.com> <3c808a150701190254y7a3e4d74o6ea02a9450d814ca@mail.gmail.com> <200701191759.20778.bengan@kthnoc.net> Message-ID: <1169231754.5593.52.camel@localhost> me too. On Fri, 2007-01-19 at 17:59 +0100, Bengt G?rd?n wrote: > fredag 19 januari 2007 11:54 skrev Marc-Olivier Barre: > > Now could we get back to the original question and take a decision ? > > I vote yes. > > -- Leonard Ritter -- Freelance Art & Logic -- http://www.leonard-ritter.com From zanga.mail at gmail.com Mon Jan 22 14:08:46 2007 From: zanga.mail at gmail.com (Stefano D'Angelo) Date: Mon Jan 22 14:08:54 2007 Subject: [linux-audio-dev] Sound processing objects architecture, is it possible? Message-ID: <160c13350701221108r1a5fff41v6130a9dc40e396d3@mail.gmail.com> Hi all, I'm quite new to sound-related programming, but however I have an idea which could interest some of you, but I don't know if it's possible to develop such thing. What I'd like to work on is a sound processing architecture (LADSPA, VST, DSSI, etc.) wrapper, which hides the details of a particular implementation to audio program developers. The whole thing could be made of a library to be used directly by audio developers in their programs, one or more configuration files used to retrieve directories in which plugins are placed and other stuff, and modules which contain implementation details for each processing architecture. The library could also contain some code to "trap" particular kinds of functions (for example Xlib functions to embed plugin GUIs inside programs). I think that the advantage of all of these stuff is to enable programs to use any kind of processing object (they could not only be loadable modules, but also text files or whatever), to collect "information" on how to implement a certain processing object type just in one place, and, last but not least, to ease creation of new standards and comparison of existing ones. What do you think about it? Sincerely, Stefano D'Angelo From dsbaikov at gmail.com Mon Jan 22 14:29:51 2007 From: dsbaikov at gmail.com (Dmitry Baikov) Date: Mon Jan 22 14:30:05 2007 Subject: [linux-audio-dev] Sound processing objects architecture, is it possible? In-Reply-To: <160c13350701221108r1a5fff41v6130a9dc40e396d3@mail.gmail.com> References: <160c13350701221108r1a5fff41v6130a9dc40e396d3@mail.gmail.com> Message-ID: <70a871c80701221129q24fc820cw98b604533c92b06@mail.gmail.com> On 1/22/07, Stefano D'Angelo wrote: > What I'd like to work on is a sound processing architecture (LADSPA, > VST, DSSI, etc.) wrapper, which hides the details of a particular > implementation to audio program developers. All this architectures have different APIs. Will your one have an fat API (union of all APIs it hides) or a thin API (intersection). What will you do if APIs you wrap are doing the same things very different ways? You say that if will be possible to compare standards or create a new ones. If your API wraps them all, then it should automatically be best one. So, why bother creating new API's if your proposal is in fact that new API, which is better than any other. And if it is not better, you can't use more advanced API through your wrapper. Just some thoughts. Regards, Dmitry. From contact at leonard-ritter.com Mon Jan 22 14:32:49 2007 From: contact at leonard-ritter.com (Leonard Ritter) Date: Mon Jan 22 14:33:40 2007 Subject: [linux-audio-dev] Sound processing objects architecture, is it possible? In-Reply-To: <160c13350701221108r1a5fff41v6130a9dc40e396d3@mail.gmail.com> References: <160c13350701221108r1a5fff41v6130a9dc40e396d3@mail.gmail.com> Message-ID: <1169494370.5628.4.camel@localhost> might libzzub be part of what you are searching for? http://trac.zeitherrschaft.org/zzub On Mon, 2007-01-22 at 20:08 +0100, Stefano D'Angelo wrote: > Hi all, > I'm quite new to sound-related programming, but however I have an idea > which could interest some of you, but I don't know if it's possible to > develop such thing. > What I'd like to work on is a sound processing architecture (LADSPA, > VST, DSSI, etc.) wrapper, which hides the details of a particular > implementation to audio program developers. > The whole thing could be made of a library to be used directly by > audio developers in their programs, one or more configuration files > used to retrieve directories in which plugins are placed and other > stuff, and modules which contain implementation details for each > processing architecture. > The library could also contain some code to "trap" particular kinds of > functions (for example Xlib functions to embed plugin GUIs inside > programs). > I think that the advantage of all of these stuff is to enable programs > to use any kind of processing object (they could not only be loadable > modules, but also text files or whatever), to collect "information" on > how to implement a certain processing object type just in one place, > and, last but not least, to ease creation of new standards and > comparison of existing ones. > What do you think about it? > > Sincerely, > > Stefano D'Angelo -- Leonard Ritter -- Freelance Art & Logic -- http://www.leonard-ritter.com From zanga.mail at gmail.com Mon Jan 22 16:39:22 2007 From: zanga.mail at gmail.com (Stefano D'Angelo) Date: Mon Jan 22 16:40:09 2007 Subject: [linux-audio-dev] Sound processing objects architecture, is it possible? In-Reply-To: <70a871c80701221129q24fc820cw98b604533c92b06@mail.gmail.com> References: <160c13350701221108r1a5fff41v6130a9dc40e396d3@mail.gmail.com> <70a871c80701221129q24fc820cw98b604533c92b06@mail.gmail.com> Message-ID: <160c13350701221339m19a7cceek39dc022d22fc5fb7@mail.gmail.com> 2007/1/22, Dmitry Baikov : > On 1/22/07, Stefano D'Angelo wrote: > > What I'd like to work on is a sound processing architecture (LADSPA, > > VST, DSSI, etc.) wrapper, which hides the details of a particular > > implementation to audio program developers. > All this architectures have different APIs. > Will your one have an fat API (union of all APIs it hides) or a thin > API (intersection). I'm thinking about a (fat) union API. > What will you do if APIs you wrap are doing the same things very different ways? Well, it depends on how big is the difference... this is a reason why I'm asking you if you think this is possible... after all I know just about VST, LADSPA 1.1 and LV2, and they don't seem to be that much different (I mean at a logical level). > You say that if will be possible to compare standards or create a new ones. > If your API wraps them all, then it should automatically be best one. > So, why bother creating new API's if your proposal is in fact that new > API, which is better than any other. Good point! This is true, but there are lots of sound processing plugins around, so maybe instead of creating a new API and then apply some "compatibility layer", it should be better to create a wrapping tool natively. I think it should be also easier to expand. > And if it is not better, you can't use more advanced API through your wrapper. True, but I was thinking about a more "sophisticated" idea of "processing object". For example you might want to write a library to implement sound processing with already-instructed neural networks, and you wish to load values from a text file (which would actually be your "processing object"). With this ideal architecture you don't have to create a new engine from scratch and wait for other programmers to implement it. You would just write a module, and that would work with any program using this system. I know my English isn't perfect, I do what I can. :-) Stefano P.S.: I think I've also found a name for it: "Naspro", an recursive acronym meaning "Naspro Architecture for Sound PRocessing Objects". The "Naspro" is a southern italian type of icing used for sweets. From zanga.mail at gmail.com Mon Jan 22 16:46:16 2007 From: zanga.mail at gmail.com (Stefano D'Angelo) Date: Mon Jan 22 16:46:25 2007 Subject: [linux-audio-dev] Sound processing objects architecture, is it possible? In-Reply-To: <1169494370.5628.4.camel@localhost> References: <160c13350701221108r1a5fff41v6130a9dc40e396d3@mail.gmail.com> <1169494370.5628.4.camel@localhost> Message-ID: <160c13350701221346h25ece7a4u86688d31bbe69da1@mail.gmail.com> 2007/1/22, Leonard Ritter : > might libzzub be part of what you are searching for? > > http://trac.zeitherrschaft.org/zzub Well, what do you mean for "extensible DSP plugin system"? Let me know, Stefano From dsbaikov at gmail.com Mon Jan 22 16:51:41 2007 From: dsbaikov at gmail.com (Dmitry Baikov) Date: Mon Jan 22 16:54:08 2007 Subject: [linux-audio-dev] Sound processing objects architecture, is it possible? In-Reply-To: <160c13350701221339m19a7cceek39dc022d22fc5fb7@mail.gmail.com> References: <160c13350701221108r1a5fff41v6130a9dc40e396d3@mail.gmail.com> <70a871c80701221129q24fc820cw98b604533c92b06@mail.gmail.com> <160c13350701221339m19a7cceek39dc022d22fc5fb7@mail.gmail.com> Message-ID: <70a871c80701221351w4bfbce4dt7a078da0f6d371dd@mail.gmail.com> On 1/23/07, Stefano D'Angelo wrote: > Good point! This is true, but there are lots of sound processing > plugins around, so maybe instead of creating a new API and then apply > some "compatibility layer", it should be better to create a wrapping > tool natively. I think it should be also easier to expand. Then, embrase LV2 and create LV2 plugins that will load VSTs, LADSPA and anything you want. Or if you want something not possible with LV2, write an extension proposal. I think LV2 was designed as a very extendable API. If it is not, in your opinion, then help the guys to improve it. Regards, Dmitry. From mle+la at mega-nerd.com Mon Jan 22 16:53:13 2007 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Mon Jan 22 16:54:49 2007 Subject: [linux-audio-dev] Sample Rate Converter Comparison Message-ID: <20070123085313.7d2fe3ae.mle+la@mega-nerd.com> Hi all, SecretRabbitCode was recently included in a test of a number of commercially available sample rate converters and while it wasn't the best, it certainly didn't disgrace itself either. The results are here: http://src.infinitewave.ca/ This test gives me yet more incentive to continue my work on coming up with a new improved algorithm. Cheers, Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "I'd rather not work with people who aren't careful. It's darwinism in software development." -- Linus Torvalds on the linux-kernel list From paul at linuxaudiosystems.com Mon Jan 22 17:06:43 2007 From: paul at linuxaudiosystems.com (Paul Davis) Date: Mon Jan 22 17:07:10 2007 Subject: [linux-audio-dev] Sample Rate Converter Comparison In-Reply-To: <20070123085313.7d2fe3ae.mle+la@mega-nerd.com> References: <20070123085313.7d2fe3ae.mle+la@mega-nerd.com> Message-ID: <1169503603.446.260.camel@localhost.localdomain> On Tue, 2007-01-23 at 08:53 +1100, Erik de Castro Lopo wrote: > Hi all, > > SecretRabbitCode was recently included in a test of a number of > commercially available sample rate converters and while it wasn't > the best, it certainly didn't disgrace itself either. congrats Erik. as you said, not the best (r8brain ?) but compared to the stuff in some proprietary DAWs, pretty great. quite amazing how bad the ProTools and Sadie systems were ... --p From zanga.mail at gmail.com Mon Jan 22 17:15:35 2007 From: zanga.mail at gmail.com (Stefano D'Angelo) Date: Mon Jan 22 17:15:44 2007 Subject: [linux-audio-dev] Sound processing objects architecture, is it possible? In-Reply-To: <70a871c80701221351w4bfbce4dt7a078da0f6d371dd@mail.gmail.com> References: <160c13350701221108r1a5fff41v6130a9dc40e396d3@mail.gmail.com> <70a871c80701221129q24fc820cw98b604533c92b06@mail.gmail.com> <160c13350701221339m19a7cceek39dc022d22fc5fb7@mail.gmail.com> <70a871c80701221351w4bfbce4dt7a078da0f6d371dd@mail.gmail.com> Message-ID: <160c13350701221415w66056241x840a618d4e0b05a5@mail.gmail.com> 2007/1/22, Dmitry Baikov : > On 1/23/07, Stefano D'Angelo wrote: > > Good point! This is true, but there are lots of sound processing > > plugins around, so maybe instead of creating a new API and then apply > > some "compatibility layer", it should be better to create a wrapping > > tool natively. I think it should be also easier to expand. > > Then, embrase LV2 and create LV2 plugins that will load VSTs, LADSPA > and anything you want. > Or if you want something not possible with LV2, write an extension proposal. > > I think LV2 was designed as a very extendable API. > If it is not, in your opinion, then help the guys to improve it. That could be a very wise solution, but there's one big problem with it: when you load a LV2 plugin, you load only one plugin! To be clearer I make an example: I have 10 VST plugin, and I want to write a LV2 plugin which loads VST plugins. When the LV2-aware application asks me which plugin I want to load I should specify the VST plugin loader... but then? There's no way for my LV2 plugin to determine which VST plugin it should load. But also if this is an overcomeable problem, for each VST plugin I load I have to waste memory space with a new instance of the LV2 VST loader plugin. Then, it is quite absurde from the user point of view to open a plugin which lets you open other plugins... it's just illogical! Don't misunderstand me, LV2 is great, I think that it's the best processing architecture out there, but it's designed with a 1:1 relationship in mind (one plugin = one effect). That's absolutely not an LV2 weakness, it just does its job and nothing else (as it should be). Here I'm talking about a different problem: interoperability beetween different processing paradigms, letting the user choose what he likes more. Regards, Stefano From mle+la at mega-nerd.com Mon Jan 22 17:44:30 2007 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Mon Jan 22 17:44:40 2007 Subject: [linux-audio-dev] Sample Rate Converter Comparison In-Reply-To: <1169503603.446.260.camel@localhost.localdomain> References: <20070123085313.7d2fe3ae.mle+la@mega-nerd.com> <1169503603.446.260.camel@localhost.localdomain> Message-ID: <20070123094430.1171615e.mle+la@mega-nerd.com> Paul Davis wrote: > congrats Erik. Thanks! > as you said, not the best (r8brain ?) r8brains was good as was iZotope, Wavelab/Crystal and a couple of others. > but compared to the > stuff in some proprietary DAWs, pretty great. quite amazing how bad the > ProTools and Sadie systems were ... Protools wasn't *that* bad unless you look at it on a bang per buck basis :-). Sadie however was appallingly bad. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ I call C++ a curse on programmers everywhere; the language that has enabled and encouraged more stupidity and bad software design than any other programming language ever. From zanga.mail at gmail.com Mon Jan 22 17:47:31 2007 From: zanga.mail at gmail.com (Stefano D'Angelo) Date: Mon Jan 22 17:47:40 2007 Subject: [linux-audio-dev] Sound processing objects architecture, is it possible? In-Reply-To: <160c13350701221346h25ece7a4u86688d31bbe69da1@mail.gmail.com> References: <160c13350701221108r1a5fff41v6130a9dc40e396d3@mail.gmail.com> <1169494370.5628.4.camel@localhost> <160c13350701221346h25ece7a4u86688d31bbe69da1@mail.gmail.com> Message-ID: <160c13350701221447p55f13ed9pf05f94e4288ebe0e@mail.gmail.com> Anyway, I gave a fast look at the include/zzub/plugin.h file and it seems me like it's a valid example of a plugin system which could be implemented on the top of an architecture such as the one I'm describing right here. (You were meaning this, right?) Regards, Stefano From mle+la at mega-nerd.com Mon Jan 22 17:53:20 2007 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Mon Jan 22 17:53:41 2007 Subject: [linux-audio-dev] Sample Rate Converter Comparison In-Reply-To: <20070123085313.7d2fe3ae.mle+la@mega-nerd.com> References: <20070123085313.7d2fe3ae.mle+la@mega-nerd.com> Message-ID: <20070123095320.cb6dcede.mle+la@mega-nerd.com> Erik de Castro Lopo wrote: > Hi all, > > SecretRabbitCode was recently included in a test of a number of > commercially available sample rate converters and while it wasn't > the best, it certainly didn't disgrace itself either. I should also thank Ben Loftis of GWL (Harrison consoles) for hooking me up with the people running the tests so that the Rabbit could be included. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "A 'newbie', in Haskell, is someone who hasn't yet implemented a compiler. They've only written a monad tutorial." -- From #haskell on freenode From steve at plugin.org.uk Tue Jan 23 03:46:30 2007 From: steve at plugin.org.uk (Steve Harris) Date: Tue Jan 23 03:46:41 2007 Subject: Fwd: [linux-audio-dev] Sound processing objects architecture, is it possible? References: Message-ID: <72F787DC-186E-4456-BB25-FB31CEF884AB@plugin.org.uk> On 22 Jan 2007, at 22:15, Stefano D'Angelo wrote: > 2007/1/22, Dmitry Baikov : >> On 1/23/07, Stefano D'Angelo wrote: >> > Good point! This is true, but there are lots of sound processing >> > plugins around, so maybe instead of creating a new API and then >> apply >> > some "compatibility layer", it should be better to create a >> wrapping >> > tool natively. I think it should be also easier to expand. >> >> Then, embrase LV2 and create LV2 plugins that will load VSTs, LADSPA >> and anything you want. >> Or if you want something not possible with LV2, write an extension >> proposal. >> >> I think LV2 was designed as a very extendable API. >> If it is not, in your opinion, then help the guys to improve it. > > That could be a very wise solution, but there's one big problem with > it: when you load a LV2 plugin, you load only one plugin! > To be clearer I make an example: I have 10 VST plugin, and I want to > write a LV2 plugin which loads VST plugins. When the LV2-aware > application asks me which plugin I want to load I should specify the > VST plugin loader... but then? There's no way for my LV2 plugin to > determine which VST plugin it should load. This works fine, and was in the design brief for LV2. When asked what effects your LV2 plugin supports, you can return a list. > But also if this is an overcomeable problem, for each VST plugin I > load I have to waste memory space with a new instance of the LV2 VST > loader plugin. No you don't. A LV2 VST loader would be a single shared object, so the OS would only load one instance of it. > Then, it is quite absurde from the user point of view to open a plugin > which lets you open other plugins... it's just illogical! It doesn't look like that to the user, they will just see a list of plugins, some of which will be VST and some will not be. Have you tried the DSSI VST reflector? It would work the same as that. > Don't misunderstand me, LV2 is great, I think that it's the best > processing architecture out there, but it's designed with a 1:1 > relationship in mind (one plugin = one effect). That's absolutely not > an LV2 weakness, it just does its job and nothing else (as it should > be). You need to read the spec again. The terminology is confused, not least in the spec documents, but a single .lv2 "plugin" can host multiple effects with different ports and so on. - Steve From steve at plugin.org.uk Tue Jan 23 03:54:45 2007 From: steve at plugin.org.uk (Steve Harris) Date: Tue Jan 23 03:54:52 2007 Subject: [linux-audio-dev] Back in the land of the connected Message-ID: Just a quick heads-up. As some of you may know, I recently left my old job and the University of Southampton. But, I forgot to fill in the paperwork to keep my old accounts, machines etc. Consequently my @ecs.soton.ac.uk and @plugin.org.uk addresses stopped working, and the server that was running plugin.org.uk went offline. I now have my email accounts back. I'm still fishing through the backlog, so if you sent anything and I haven't replied, give it a week or so then try again. Some stuff will have been lost. Plugin.org.uk is back online at a new server, but judging by my inbox some things aren't working right. I'll look at it over the next day or so. - Steve From game_core at o2.pl Mon Jan 22 15:02:03 2007 From: game_core at o2.pl (kind king knight) Date: Tue Jan 23 06:09:31 2007 Subject: [linux-audio-dev] Little advertisment ;P Message-ID: <1169496123.5527.23.camel@localhost.localdomain> I am an electronic musician (even an computer musician). I am specializen in any kind of electronic music from techno to glitch .Here are some of my releases: www.ccmixter.org/media/people/game_core I am also a regular participator of soundevotion (www.sdcompo.com)tracking competition (as crosfire) I mainly use trackers (renoise,fasttracker, sakale), but have experience in modular synthesis (reaktor, buzz, arts builder), midi/audio/vst sequencers (cubase, logic), and other (rebirth, reason, and many others). The point is that if you have developed an music application (linux, or windows), and need demo songs, or a simple testing, then I am probably interested:). I know that most of open source audio developers are also musicians, and they do the demo songs, and bug testing, and other things by themselves, but there not always is time. Anyway I am here to help you! :D From zanga.mail at gmail.com Tue Jan 23 07:17:08 2007 From: zanga.mail at gmail.com (Stefano D'Angelo) Date: Tue Jan 23 07:17:25 2007 Subject: [linux-audio-dev] Sound processing objects architecture, is it possible? In-Reply-To: <72F787DC-186E-4456-BB25-FB31CEF884AB@plugin.org.uk> References: <72F787DC-186E-4456-BB25-FB31CEF884AB@plugin.org.uk> Message-ID: <160c13350701230417i733f2fco3220e24fcc240eac@mail.gmail.com> 2007/1/23, Steve Harris : > On 22 Jan 2007, at 22:15, Stefano D'Angelo wrote: > > > 2007/1/22, Dmitry Baikov : > >> On 1/23/07, Stefano D'Angelo wrote: > >> > Good point! This is true, but there are lots of sound processing > >> > plugins around, so maybe instead of creating a new API and then > >> apply > >> > some "compatibility layer", it should be better to create a > >> wrapping > >> > tool natively. I think it should be also easier to expand. > >> > >> Then, embrase LV2 and create LV2 plugins that will load VSTs, LADSPA > >> and anything you want. > >> Or if you want something not possible with LV2, write an extension > >> proposal. > >> > >> I think LV2 was designed as a very extendable API. > >> If it is not, in your opinion, then help the guys to improve it. > > > > That could be a very wise solution, but there's one big problem with > > it: when you load a LV2 plugin, you load only one plugin! > > To be clearer I make an example: I have 10 VST plugin, and I want to > > write a LV2 plugin which loads VST plugins. When the LV2-aware > > application asks me which plugin I want to load I should specify the > > VST plugin loader... but then? There's no way for my LV2 plugin to > > determine which VST plugin it should load. > > This works fine, and was in the design brief for LV2. When asked what > effects your LV2 plugin supports, you can return a list. > > > But also if this is an overcomeable problem, for each VST plugin I > > load I have to waste memory space with a new instance of the LV2 VST > > loader plugin. > > No you don't. A LV2 VST loader would be a single shared object, so > the OS would only load one instance of it. > > > Then, it is quite absurde from the user point of view to open a plugin > > which lets you open other plugins... it's just illogical! > > It doesn't look like that to the user, they will just see a list of > plugins, some of which will be VST and some will not be. Have you > tried the DSSI VST reflector? It would work the same as that. > > > Don't misunderstand me, LV2 is great, I think that it's the best > > processing architecture out there, but it's designed with a 1:1 > > relationship in mind (one plugin = one effect). That's absolutely not > > an LV2 weakness, it just does its job and nothing else (as it should > > be). > > You need to read the spec again. > > The terminology is confused, not least in the spec documents, but a > single .lv2 "plugin" can host multiple effects with different ports > and so on. > > - Steve > Oops... seems like I'm a bit confused! Well, I'm going to reread the LV2 spec and try to figure out how to manage this kind of situations. Sorry for wasting your time! Sincerely, Stefano From steve at plugin.org.uk Tue Jan 23 08:02:11 2007 From: steve at plugin.org.uk (Steve Harris) Date: Tue Jan 23 08:04:28 2007 Subject: [linux-audio-dev] Sound processing objects architecture, is it possible? In-Reply-To: <160c13350701230417i733f2fco3220e24fcc240eac@mail.gmail.com> References: <72F787DC-186E-4456-BB25-FB31CEF884AB@plugin.org.uk> <160c13350701230417i733f2fco3220e24fcc240eac@mail.gmail.com> Message-ID: On 23 Jan 2007, at 12:17, Stefano D'Angelo wrote: >> >> You need to read the spec again. >> >> The terminology is confused, not least in the spec documents, but a >> single .lv2 "plugin" can host multiple effects with different ports >> and so on. >> >> - Steve >> > > Oops... seems like I'm a bit confused! Well, I'm going to reread the > LV2 spec and try to figure out how to manage this kind of situations. > Sorry for wasting your time! Not at all, at the very least it points out that the LV2 spec needs to be clearer, and probably needs better examples. - Steve From dlphillips at woh.rr.com Tue Jan 23 08:17:42 2007 From: dlphillips at woh.rr.com (Dave Phillips) Date: Tue Jan 23 08:04:44 2007 Subject: [linux-audio-dev] interview with Rui Nuno Capela Message-ID: <45B60AF6.7030700@woh.rr.com> Greetings: I've placed online an interview with Rui Capela, the creator of QJackCtl, QSynth, QSampler, and QTractor. You can read it here: http://www.linuxjournal.com Enjoy! Best, dp From zanga.mail at gmail.com Tue Jan 23 08:19:16 2007 From: zanga.mail at gmail.com (Stefano D'Angelo) Date: Tue Jan 23 08:19:45 2007 Subject: [linux-audio-dev] Sound processing objects architecture, is it possible? In-Reply-To: References: <72F787DC-186E-4456-BB25-FB31CEF884AB@plugin.org.uk> <160c13350701230417i733f2fco3220e24fcc240eac@mail.gmail.com> Message-ID: <160c13350701230519q2460240fuc31a41afd7e1b508@mail.gmail.com> 2007/1/23, Steve Harris : > > On 23 Jan 2007, at 12:17, Stefano D'Angelo wrote: > >> > >> You need to read the spec again. > >> > >> The terminology is confused, not least in the spec documents, but a > >> single .lv2 "plugin" can host multiple effects with different ports > >> and so on. > >> > >> - Steve > >> > > > > Oops... seems like I'm a bit confused! Well, I'm going to reread the > > LV2 spec and try to figure out how to manage this kind of situations. > > Sorry for wasting your time! > > Not at all, at the very least it points out that the LV2 spec needs > to be clearer, and probably needs better examples. > > - Steve > Well, maybe it's because I'm not very good at English :-) However I have another question: how would a LV2 VST loader plugin could communicate to the host a VST plugin info? This could be done only via an extension? Then, if I understood correctly, such LV2 VST loader plugin, when asked for effects, should return a list of all effects of all VST plugins it knows about? Stefano From ladev at sound-man.co.uk Tue Jan 23 09:31:45 2007 From: ladev at sound-man.co.uk (John Rigg) Date: Tue Jan 23 09:13:41 2007 Subject: [linux-audio-dev] Sample Rate Converter Comparison In-Reply-To: <20070123085313.7d2fe3ae.mle+la@mega-nerd.com> References: <20070123085313.7d2fe3ae.mle+la@mega-nerd.com> Message-ID: <20070123143145.GA3145@localhost.localdomain> On Tue, Jan 23, 2007 at 08:53:13AM +1100, Erik de Castro Lopo wrote: > Hi all, > > SecretRabbitCode was recently included in a test of a number of > commercially available sample rate converters and while it wasn't > the best, it certainly didn't disgrace itself either. > > The results are here: > > http://src.infinitewave.ca/ Don't know if it's just me, but I can't get the images to change on the web page (using Firefox 1.0.4 with javascript turned on). The only way I can look at the results is to get the URLs for individual images from the page source and type them in manually. John From steve at plugin.org.uk Tue Jan 23 09:25:52 2007 From: steve at plugin.org.uk (Steve Harris) Date: Tue Jan 23 09:40:22 2007 Subject: [linux-audio-dev] Sound processing objects architecture, is it possible? In-Reply-To: <160c13350701230519q2460240fuc31a41afd7e1b508@mail.gmail.com> References: <72F787DC-186E-4456-BB25-FB31CEF884AB@plugin.org.uk> <160c13350701230417i733f2fco3220e24fcc240eac@mail.gmail.com> <160c13350701230519q2460240fuc31a41afd7e1b508@mail.gmail.com> Message-ID: <01C2B4E7-8F9B-4FDC-8922-1EFA4BF4EBF0@plugin.org.uk> On 23 Jan 2007, at 13:19, Stefano D'Angelo wrote: > 2007/1/23, Steve Harris : >> >> On 23 Jan 2007, at 12:17, Stefano D'Angelo wrote: >> >> >> >> You need to read the spec again. >> >> >> >> The terminology is confused, not least in the spec documents, >> but a >> >> single .lv2 "plugin" can host multiple effects with different >> ports >> >> and so on. >> >> >> >> - Steve >> >> >> > >> > Oops... seems like I'm a bit confused! Well, I'm going to reread >> the >> > LV2 spec and try to figure out how to manage this kind of >> situations. >> > Sorry for wasting your time! >> >> Not at all, at the very least it points out that the LV2 spec needs >> to be clearer, and probably needs better examples. >> >> - Steve >> > > Well, maybe it's because I'm not very good at English :-) > However I have another question: how would a LV2 VST loader plugin > could communicate to the host a VST plugin info? This could be done > only via an extension? That's the slightly tricky part, the VST reflector would have to generate an RDF file describing all the VST plugins it knows about. That will work fine, and is not particularly difficult, but it could be made slicker with an extension that allowed the VST reflector to generate that file dynamically. > Then, if I understood correctly, such LV2 VST loader plugin, when > asked for effects, should return a list of all effects of all VST > plugins it knows about? Yes, it can just return the URIs of all the installed VST effects as return values of the lv2_descriptor() calls. The host calls it repeatedly until it's found all the effects. - Steve From a at gaydenko.com Tue Jan 23 09:33:04 2007 From: a at gaydenko.com (Andrew Gaydenko) Date: Tue Jan 23 09:45:55 2007 Subject: [linux-audio-dev] Sample Rate Converter Comparison In-Reply-To: <20070123143145.GA3145@localhost.localdomain> References: <20070123085313.7d2fe3ae.mle+la@mega-nerd.com> <20070123143145.GA3145@localhost.localdomain> Message-ID: <200701231733.04977@goldspace.net> ======= On Tuesday 23 January 2007 17:31, John Rigg wrote: ======= > >Don't know if it's just me, but I can't get the images to change on >the web page (using Firefox 1.0.4 with javascript turned on). The only >way I can look at the results is to get the URLs for individual images >from the page source and type them in manually. > >John > The same with FF 2.0.0.1. From paul at linuxaudiosystems.com Tue Jan 23 09:43:17 2007 From: paul at linuxaudiosystems.com (Paul Davis) Date: Tue Jan 23 09:53:55 2007 Subject: [linux-audio-dev] Sample Rate Converter Comparison In-Reply-To: <20070123143145.GA3145@localhost.localdomain> References: <20070123085313.7d2fe3ae.mle+la@mega-nerd.com> <20070123143145.GA3145@localhost.localdomain> Message-ID: <1169563397.446.303.camel@localhost.localdomain> On Tue, 2007-01-23 at 14:31 +0000, John Rigg wrote: > On Tue, Jan 23, 2007 at 08:53:13AM +1100, Erik de Castro Lopo wrote: > > Hi all, > > > > SecretRabbitCode was recently included in a test of a number of > > commercially available sample rate converters and while it wasn't > > the best, it certainly didn't disgrace itself either. > > > > The results are here: > > > > http://src.infinitewave.ca/ > > Don't know if it's just me, but I can't get the images to change on > the web page (using Firefox 1.0.4 with javascript turned on). The only > way I can look at the results is to get the URLs for individual images > from the page source and type them in manually. its just you :) or rather, an early version of firefox perhaps. i have 1.5.X and it works fine here. From bengan at kthnoc.net Tue Jan 23 09:46:47 2007 From: bengan at kthnoc.net (Bengt =?iso-8859-1?q?G=F6rd=E9n?=) Date: Tue Jan 23 09:56:11 2007 Subject: [linux-audio-dev] Sample Rate Converter Comparison In-Reply-To: <20070123143145.GA3145@localhost.localdomain> References: <20070123085313.7d2fe3ae.mle+la@mega-nerd.com> <20070123143145.GA3145@localhost.localdomain> Message-ID: <200701231546.48975.bengan@kthnoc.net> tisdag 23 januari 2007 15:31 skrev John Rigg: > On Tue, Jan 23, 2007 at 08:53:13AM +1100, Erik de Castro Lopo wrote: > > Hi all, > > > > SecretRabbitCode was recently included in a test of a number of > > commercially available sample rate converters and while it wasn't > > the best, it certainly didn't disgrace itself either. > > > > The results are here: > > > > http://src.infinitewave.ca/ > > Don't know if it's just me, but I can't get the images to change on > the web page (using Firefox 1.0.4 with javascript turned on). 1.0.x is end of life in april 2006. You should upgrade to be on the safe side. regards, -- - Bengan ------------------------------------------------------------ - KTHNOC - No1 Internet Offspring | http://www.noc.kth.se/~bengan --- - 08-7906586 (ej vidarekopplat), 070-6443325 ------------------------ From steve at plugin.org.uk Tue Jan 23 10:04:48 2007 From: steve at plugin.org.uk (Steve Harris) Date: Tue Jan 23 10:12:56 2007 Subject: [linux-audio-dev] Sample Rate Converter Comparison In-Reply-To: <1169563397.446.303.camel@localhost.localdomain> References: <20070123085313.7d2fe3ae.mle+la@mega-nerd.com> <20070123143145.GA3145@localhost.localdomain> <1169563397.446.303.camel@localhost.localdomain> Message-ID: <81410B4F-9D0A-4F9E-841B-AD05B0FD81D9@plugin.org.uk> On 23 Jan 2007, at 14:43, Paul Davis wrote: > On Tue, 2007-01-23 at 14:31 +0000, John Rigg wrote: >> On Tue, Jan 23, 2007 at 08:53:13AM +1100, Erik de Castro Lopo wrote: >>> Hi all, >>> >>> SecretRabbitCode was recently included in a test of a number of >>> commercially available sample rate converters and while it wasn't >>> the best, it certainly didn't disgrace itself either. >>> >>> The results are here: >>> >>> http://src.infinitewave.ca/ >> >> Don't know if it's just me, but I can't get the images to change on >> the web page (using Firefox 1.0.4 with javascript turned on). The >> only >> way I can look at the results is to get the URLs for individual >> images >> from the page source and type them in manually. > > its just you :) or rather, an early version of firefox perhaps. i have > 1.5.X and it works fine here. Works fine with my 2.0.0.1 too. - Steve From dlphillips at woh.rr.com Tue Jan 23 10:47:23 2007 From: dlphillips at woh.rr.com (Dave Phillips) Date: Tue Jan 23 10:34:40 2007 Subject: [linux-audio-dev] Sample Rate Converter Comparison In-Reply-To: <81410B4F-9D0A-4F9E-841B-AD05B0FD81D9@plugin.org.uk> References: <20070123085313.7d2fe3ae.mle+la@mega-nerd.com> <20070123143145.GA3145@localhost.localdomain> <1169563397.446.303.camel@localhost.localdomain> <81410B4F-9D0A-4F9E-841B-AD05B0FD81D9@plugin.org.uk> Message-ID: <45B62E0B.60001@woh.rr.com> Steve Harris wrote: > [snip] > Works fine with my 2.0.0.1 too. I do all email and most Web surfing on my antique Omnibook running RH9, PlanetCCRMA, Mozilla 1.7.13. The graphics selector works fine here. And hey Erik, nice work ! :) Best, dp From zanga.mail at gmail.com Tue Jan 23 11:14:02 2007 From: zanga.mail at gmail.com (Stefano D'Angelo) Date: Tue Jan 23 11:14:24 2007 Subject: [linux-audio-dev] Sound processing objects architecture, is it possible? In-Reply-To: <01C2B4E7-8F9B-4FDC-8922-1EFA4BF4EBF0@plugin.org.uk> References: <72F787DC-186E-4456-BB25-FB31CEF884AB@plugin.org.uk> <160c13350701230417i733f2fco3220e24fcc240eac@mail.gmail.com> <160c13350701230519q2460240fuc31a41afd7e1b508@mail.gmail.com> <01C2B4E7-8F9B-4FDC-8922-1EFA4BF4EBF0@plugin.org.uk> Message-ID: <160c13350701230814k179cecd7hf8e05328dbc323e@mail.gmail.com> 2007/1/23, Steve Harris : > > On 23 Jan 2007, at 13:19, Stefano D'Angelo wrote: > > > 2007/1/23, Steve Harris : > >> > >> On 23 Jan 2007, at 12:17, Stefano D'Angelo wrote: > >> >> > >> >> You need to read the spec again. > >> >> > >> >> The terminology is confused, not least in the spec documents, > >> but a > >> >> single .lv2 "plugin" can host multiple effects with different > >> ports > >> >> and so on. > >> >> > >> >> - Steve > >> >> > >> > > >> > Oops... seems like I'm a bit confused! Well, I'm going to reread > >> the > >> > LV2 spec and try to figure out how to manage this kind of > >> situations. > >> > Sorry for wasting your time! > >> > >> Not at all, at the very least it points out that the LV2 spec needs > >> to be clearer, and probably needs better examples. > >> > >> - Steve > >> > > > > Well, maybe it's because I'm not very good at English :-) > > However I have another question: how would a LV2 VST loader plugin > > could communicate to the host a VST plugin info? This could be done > > only via an extension? > > That's the slightly tricky part, the VST reflector would have to > generate an RDF file describing all the VST plugins it knows about. > That will work fine, and is not particularly difficult, but it could > be made slicker with an extension that allowed the VST reflector to > generate that file dynamically. > > > Then, if I understood correctly, such LV2 VST loader plugin, when > > asked for effects, should return a list of all effects of all VST > > plugins it knows about? > > Yes, it can just return the URIs of all the installed VST effects as > return values of the lv2_descriptor() calls. The host calls it > repeatedly until it's found all the effects. > > - Steve > Just some last questions and I'll stop shouting and fooling around :-) This issue should also have been faced with vstserver, fst and so, but I never used them, so I'm just asking (I'm doing all of these because I'm working on a DSP program): how would a LV2 VST loader handle VST plugins with various effects, banks and programs, expecially in the case (if any and/or possible) where such plugin makes some fades when changing while playing (real-time processing)? Then... I see in VST docs that a getInputLatency and getOutputLatency functions are defined. I think that these could be used as extensions on a LV2 host, but such values are to be trusted under wine? And what about the combination of LASH and VST storing system? Anyway, thanks a lot! Regards, Stefano From steve at plugin.org.uk Tue Jan 23 11:32:15 2007 From: steve at plugin.org.uk (Steve Harris) Date: Tue Jan 23 11:32:28 2007 Subject: [linux-audio-dev] Sound processing objects architecture, is it possible? In-Reply-To: <160c13350701230814k179cecd7hf8e05328dbc323e@mail.gmail.com> References: <72F787DC-186E-4456-BB25-FB31CEF884AB@plugin.org.uk> <160c13350701230417i733f2fco3220e24fcc240eac@mail.gmail.com> <160c13350701230519q2460240fuc31a41afd7e1b508@mail.gmail.com> <01C2B4E7-8F9B-4FDC-8922-1EFA4BF4EBF0@plugin.org.uk> <160c13350701230814k179cecd7hf8e05328dbc323e@mail.gmail.com> Message-ID: On 23 Jan 2007, at 16:14, Stefano D'Angelo wrote: > > Just some last questions and I'll stop shouting and fooling around :-) > > This issue should also have been faced with vstserver, fst and so, but > I never used them, so I'm just asking (I'm doing all of these because > I'm working on a DSP program): how would a LV2 VST loader handle VST > plugins with various effects, banks and programs, expecially in the > case (if any and/or possible) where such plugin makes some fades when > changing while playing (real-time processing)? I've no idea, you'd have to ask the authors of those other converters. > Then... I see in VST docs that a getInputLatency and getOutputLatency > functions are defined. I think that these could be used as extensions > on a LV2 host, but such values are to be trusted under wine? LADSPA has _latency ports, I don't remember what we said for LV2. The latency should only be algorithmic, so wine should not be relevant. > And what about the combination of LASH and VST storing system? Sorry, I don't know anything about the VST storing system. - Steve From zanga.mail at gmail.com Tue Jan 23 11:49:54 2007 From: zanga.mail at gmail.com (Stefano D'Angelo) Date: Tue Jan 23 11:50:06 2007 Subject: [linux-audio-dev] Sound processing objects architecture, is it possible? In-Reply-To: References: <72F787DC-186E-4456-BB25-FB31CEF884AB@plugin.org.uk> <160c13350701230417i733f2fco3220e24fcc240eac@mail.gmail.com> <160c13350701230519q2460240fuc31a41afd7e1b508@mail.gmail.com> <01C2B4E7-8F9B-4FDC-8922-1EFA4BF4EBF0@plugin.org.uk> <160c13350701230814k179cecd7hf8e05328dbc323e@mail.gmail.com> Message-ID: <160c13350701230849g29f3e5c9g7d31122d2d83b1fb@mail.gmail.com> 2007/1/23, Steve Harris : > > On 23 Jan 2007, at 16:14, Stefano D'Angelo wrote: > > > > Just some last questions and I'll stop shouting and fooling around :-) > > > > This issue should also have been faced with vstserver, fst and so, but > > I never used them, so I'm just asking (I'm doing all of these because > > I'm working on a DSP program): how would a LV2 VST loader handle VST > > plugins with various effects, banks and programs, expecially in the > > case (if any and/or possible) where such plugin makes some fades when > > changing while playing (real-time processing)? > > I've no idea, you'd have to ask the authors of those other converters. > > > Then... I see in VST docs that a getInputLatency and getOutputLatency > > functions are defined. I think that these could be used as extensions > > on a LV2 host, but such values are to be trusted under wine? > > LADSPA has _latency ports, I don't remember what we said for LV2. The > latency should only be algorithmic, so wine should not be relevant. > > > And what about the combination of LASH and VST storing system? > > Sorry, I don't know anything about the VST storing system. > > - Steve No problem, as I said before, thanks a lot! Stefano From ladev at sound-man.co.uk Tue Jan 23 12:29:36 2007 From: ladev at sound-man.co.uk (John Rigg) Date: Tue Jan 23 12:04:47 2007 Subject: [linux-audio-dev] Sample Rate Converter Comparison In-Reply-To: <20070123143145.GA3145@localhost.localdomain> References: <20070123085313.7d2fe3ae.mle+la@mega-nerd.com> <20070123143145.GA3145@localhost.localdomain> Message-ID: <20070123172936.GA3569@localhost.localdomain> On Tue, Jan 23, 2007 at 02:31:45PM +0000, John Rigg wrote: > On Tue, Jan 23, 2007 at 08:53:13AM +1100, Erik de Castro Lopo wrote: > > Hi all, > > > > SecretRabbitCode was recently included in a test of a number of > > commercially available sample rate converters and while it wasn't > > the best, it certainly didn't disgrace itself either. > > > > The results are here: > > > > http://src.infinitewave.ca/ > > Don't know if it's just me, but I can't get the images to change on > the web page (using Firefox 1.0.4 with javascript turned on). The only > way I can look at the results is to get the URLs for individual images > from the page source and type them in manually. It worked much better after I remembered I'd disabled `Change images' in Javascript advanced settings. Good to see SRC stands up so well against the proprietary stuff. Nice work. (I particularly liked the 180-degree phase shift in Sonar :-)). John From d.sbragion at infotecna.it Tue Jan 23 12:35:12 2007 From: d.sbragion at infotecna.it (Denis Sbragion) Date: Tue Jan 23 12:34:23 2007 Subject: [linux-audio-dev] Sample Rate Converter Comparison In-Reply-To: <20070123085313.7d2fe3ae.mle+la@mega-nerd.com> References: <20070123085313.7d2fe3ae.mle+la@mega-nerd.com> Message-ID: <4398.192.168.1.15.1169573712.squirrel@www.infotecna.lcl> Hello Erik, On Mon, January 22, 2007 22:53, Erik de Castro Lopo wrote: > SecretRabbitCode was recently included in a test of a number of > commercially available sample rate converters and while it wasn't > the best, it certainly didn't disgrace itself either. I once tried to further improve your sinc code, using longer and better filters optimized using the Dolph-Chebyshev window and a different balance between bandwidth and stopband attenuation, of course at the expense of performances. It turned out that I couldn't improve the results above a given threshold because of a sort of (really low level) jitter in the timebase calculation. With integer resampling factors, where the jitter dind't appear because of the way the timebase is computed, the results where on pair with CoolEdit/Audition, which is among the best in that test. It was long time ago, so I don't remeber exactly what I did, but this information might be useful in improving your code. Removing this timebase calculation problem, if it can be removed at all of course, probably will make your code close to perfection, making the final performace just a factor of the quality of the filters used. Regarding this, you might think about an option to load the filters from file... :) Of course this is just academic, because I really doubt that the tiny artifacts introduced by SRC are audible at all, even in its current implementation. Just a matter of winning the race. :) Bye, -- Denis Sbragion InfoTecna Tel: +39 0362 805396, Fax: +39 0362 805404 URL: http://www.infotecna.it From mle+la at mega-nerd.com Tue Jan 23 15:22:17 2007 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Tue Jan 23 15:22:30 2007 Subject: [linux-audio-dev] Sample Rate Converter Comparison In-Reply-To: <4398.192.168.1.15.1169573712.squirrel@www.infotecna.lcl> References: <20070123085313.7d2fe3ae.mle+la@mega-nerd.com> <4398.192.168.1.15.1169573712.squirrel@www.infotecna.lcl> Message-ID: <20070124072217.62f4455c.mle+la@mega-nerd.com> Denis Sbragion wrote: > Of course this is just academic, because I really doubt that the tiny > artifacts introduced by SRC are audible at all, even in its current > implementation. Just a matter of winning the race. :) The current algorithm (originally described by Julius O. Smith) has its limitations. Thats why I have spent a considerable amount of time trying to come up with something that has lower computational requirements as well as better quality :-). Cheers, Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "[Perl] combines all the worst aspects of C and Lisp: a billion different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript." -- Jamie Zawinski From rncbc at rncbc.org Tue Jan 23 18:17:26 2007 From: rncbc at rncbc.org (Rui Nuno Capela) Date: Tue Jan 23 18:11:46 2007 Subject: [linux-audio-dev] Re: [linux-audio-user] interview with Rui Nuno Capela In-Reply-To: <45B60AF6.7030700@woh.rr.com> References: <45B60AF6.7030700@woh.rr.com> Message-ID: <45B69786.9070301@rncbc.org> Dave Phillips wrote: > Greetings: > > I've placed online an interview with Rui Capela, the creator of > QJackCtl, QSynth, QSampler, and QTractor. You can read it here: > > http://www.linuxjournal.com > > Enjoy! > Gee. Thanks Dave. Is not that usual one having his own name on a LJ article's title. I think I'll faint now #-) Cheers! -- rncbc aka Rui Nuno Capela rncbc@rncbc.org From ztraveler at adelphia.net Tue Jan 23 23:31:20 2007 From: ztraveler at adelphia.net (Michelle Donalies) Date: Tue Jan 23 23:23:07 2007 Subject: [linux-audio-dev] ScoreChaser -- a new music notation editor Message-ID: <200701232331.20704.ztraveler@adelphia.net> I recently began work on a new music notation editor called ScoreChaser. A prototype release can be found at sourceforge.net/projects/scorechaser. Its intent is to be a program in the vein of Rosegarden (and indeed, it borrows quite heavily from RG, at least in these early versions), but with groupable tracks, tablature support, and (eventually) multiple simultaneous time signatures. It's currently just an initial release with very limited functionality, but it does demonstrate the groupable tracks and the beginnings of tablature support. From d.sbragion at infotecna.it Wed Jan 24 03:45:45 2007 From: d.sbragion at infotecna.it (Denis Sbragion) Date: Wed Jan 24 03:44:58 2007 Subject: [linux-audio-dev] Sample Rate Converter Comparison In-Reply-To: <20070124072217.62f4455c.mle+la@mega-nerd.com> References: <20070123085313.7d2fe3ae.mle+la@mega-nerd.com> <4398.192.168.1.15.1169573712.squirrel@www.infotecna.lcl> <20070124072217.62f4455c.mle+la@mega-nerd.com> Message-ID: <1245.192.168.1.15.1169628345.squirrel@www.infotecna.lcl> Hello Erik, On Tue, January 23, 2007 21:22, Erik de Castro Lopo wrote: > The current algorithm (originally described by Julius O. Smith) > has its limitations. Thats why I have spent a considerable > amount of time trying to come up with something that has lower > computational requirements as well as better quality :-). and did you get it? Which kind of algorithm are you using now? Quite curios... Bye, P.S. The CoolEdit algorithm provides excellent performances but I think it works only for rational resampling factors, isn't it? This makes those performances much easier to achieve, I think. -- Denis Sbragion InfoTecna Tel: +39 0362 805396, Fax: +39 0362 805404 URL: http://www.infotecna.it From mle+la at mega-nerd.com Wed Jan 24 04:20:02 2007 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Wed Jan 24 04:20:42 2007 Subject: [linux-audio-dev] Sample Rate Converter Comparison In-Reply-To: <1245.192.168.1.15.1169628345.squirrel@www.infotecna.lcl> References: <20070123085313.7d2fe3ae.mle+la@mega-nerd.com> <4398.192.168.1.15.1169573712.squirrel@www.infotecna.lcl> <20070124072217.62f4455c.mle+la@mega-nerd.com> <1245.192.168.1.15.1169628345.squirrel@www.infotecna.lcl> Message-ID: <20070124202002.7d70f1c2.mle+la@mega-nerd.com> Denis Sbragion wrote: > and did you get it? I'm not there yet, but I'm getting closer. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "We must not forget that Allah's rules have to be established in all lands." -- Imam Muzammil H. Siddiqi of the Islamic Society of North America From d.sbragion at infotecna.it Wed Jan 24 05:41:29 2007 From: d.sbragion at infotecna.it (Denis Sbragion) Date: Wed Jan 24 05:40:44 2007 Subject: [linux-audio-dev] Sample Rate Converter Comparison In-Reply-To: <20070124202002.7d70f1c2.mle+la@mega-nerd.com> References: <20070123085313.7d2fe3ae.mle+la@mega-nerd.com> <4398.192.168.1.15.1169573712.squirrel@www.infotecna.lcl> <20070124072217.62f4455c.mle+la@mega-nerd.com> <1245.192.168.1.15.1169628345.squirrel@www.infotecna.lcl> <20070124202002.7d70f1c2.mle+la@mega-nerd.com> Message-ID: <1770.192.168.1.15.1169635289.squirrel@www.infotecna.lcl> On Wed, January 24, 2007 10:20, Erik de Castro Lopo wrote: > I'm not there yet, but I'm getting closer. Great. Looking forward... Bye, -- Denis Sbragion InfoTecna Tel: +39 0362 805396, Fax: +39 0362 805404 URL: http://www.infotecna.it From rah at bash.sh Wed Jan 24 07:03:12 2007 From: rah at bash.sh (Bob Ham) Date: Wed Jan 24 07:33:51 2007 Subject: [OT] Zionism and LAD (was: Re: [linux-audio-dev] an relevant link about Vista) Message-ID: <1169640192.2232.115.camel@orchid.arb.net> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20070124/16c61da7/attachment.bin From waz at easynet.co.uk Wed Jan 24 09:08:02 2007 From: waz at easynet.co.uk (Wayne Myers) Date: Wed Jan 24 09:14:28 2007 Subject: [OT] Zionism and LAD (was: Re: [linux-audio-dev] an relevant link about Vista) In-Reply-To: <1169640192.2232.115.camel@orchid.arb.net> References: <1169640192.2232.115.camel@orchid.arb.net> Message-ID: <20070124140802.37cc6b3c@localhost.localdomain> > MUST.. RESIST URGE.. TO CLICK SEND... DAMN! What a shame. Let's take this away from here. Now. My reply to this nonsense, in case anyone is interested, can be found on dodgeit.com here, as long as it lasts (about seven days I think): http://www.dodgeit.com/run/checkmail?mailbox=bobhamsflame Further nonsense, if anyone wishes to indulge in it, can be contributed by sending mail to bobhamsflame@dodgeit.com. My apologies to everyone on the list for my part in wasting your time in this way and for winding Bob up enough to cause him to choose to copy his personal email to this list. Cheers, Wayne -- Wayne Myers http://www.waz.easynet.co.uk/ http://www.conniptions.org/ From contact at leonard-ritter.com Wed Jan 24 10:00:57 2007 From: contact at leonard-ritter.com (Leonard Ritter) Date: Wed Jan 24 10:01:18 2007 Subject: [OT] Zionism and LAD (was: Re: [linux-audio-dev] an relevant link about Vista) In-Reply-To: <1169640192.2232.115.camel@orchid.arb.net> References: <1169640192.2232.115.camel@orchid.arb.net> Message-ID: <1169650857.5563.8.camel@localhost> FYI: you are all stupid monkeys - fact (it is. (really.)). now get back to work. -- Leonard Ritter -- Freelance Art & Logic -- http://www.leonard-ritter.com From jayv at synth.net Wed Jan 24 10:06:33 2007 From: jayv at synth.net (Jay Vaughan) Date: Wed Jan 24 10:07:35 2007 Subject: [linux-audio-dev] Sound processing objects architecture, is it possible? In-Reply-To: <160c13350701221108r1a5fff41v6130a9dc40e396d3@mail.gmail.com> References: <160c13350701221108r1a5fff41v6130a9dc40e396d3@mail.gmail.com> Message-ID: At 20:08 +0100 22/1/07, Stefano D'Angelo wrote: >What I'd like to work on is a sound processing architecture (LADSPA, >VST, DSSI, etc.) wrapper, which hides the details of a particular >implementation to audio program developers. Nice idea. Already done: http://teragon.org/products/PluginCore/ >What do you think about it? Would be nice if there were a GPL effort in the same way .. -- ; Jay Vaughan From paul at linuxaudiosystems.com Wed Jan 24 10:42:39 2007 From: paul at linuxaudiosystems.com (Paul Davis) Date: Wed Jan 24 11:44:00 2007 Subject: [linux-audio-dev] Sound processing objects architecture, is it possible? In-Reply-To: References: <160c13350701221108r1a5fff41v6130a9dc40e396d3@mail.gmail.com> Message-ID: <1169653359.446.354.camel@localhost.localdomain> On Wed, 2007-01-24 at 16:06 +0100, Jay Vaughan wrote: > At 20:08 +0100 22/1/07, Stefano D'Angelo wrote: > >What I'd like to work on is a sound processing architecture (LADSPA, > >VST, DSSI, etc.) wrapper, which hides the details of a particular > >implementation to audio program developers. > > Nice idea. Already done: > > http://teragon.org/products/PluginCore/ > > >What do you think about it? > > Would be nice if there were a GPL effort in the same way .. ARDOUR::Plugin ? which currently wraps VST, LADSPA and will soon do either LV2 or DSSI ... yeah, ok, so its partly in jest, but not entirely. --p From zanga.mail at gmail.com Wed Jan 24 10:52:58 2007 From: zanga.mail at gmail.com (Stefano D'Angelo) Date: Wed Jan 24 11:45:18 2007 Subject: [linux-audio-dev] Sound processing objects architecture, is it possible? In-Reply-To: References: <160c13350701221108r1a5fff41v6130a9dc40e396d3@mail.gmail.com> Message-ID: <160c13350701240752i1cb3554dq3cef571bee02d437@mail.gmail.com> 2007/1/24, Jay Vaughan : > At 20:08 +0100 22/1/07, Stefano D'Angelo wrote: > >What I'd like to work on is a sound processing architecture (LADSPA, > >VST, DSSI, etc.) wrapper, which hides the details of a particular > >implementation to audio program developers. > > Nice idea. Already done: > > http://teragon.org/products/PluginCore/ > > >What do you think about it? > > Would be nice if there were a GPL effort in the same way .. > > -- > > ; > > Jay Vaughan > > Well, it seems like LV2 can do (at least theorically) all of these already, altough some things might be a bit tricky (read the rest of the conversation). Now I'm seeking whether this approach (LV2 bridges plugins) can present practical problems and, in such case, I think it's better to solve them in LV2 than restart from scratch. To be true, there are two things I'm concerned about: one (less relevant, maybe) is RDF files... a bridge plugin should generate them for all installed plugins when it is loaded, and so it has to contain (or link to) code that can handle such syntax (I really don't understand why LV2 developers choose such language instead of XML, which is much more known and supported). The other one is more serious (but should have been also faced by vstserver, fst and dssi-vst): I'm talking about logical compatibility beetween LV2 and other standards (VST in this case) in handling some tasks (settings and session storing, banks/effects/programs metaphor, etc.). Does anyone know about these matters? Then I think that it would be nice if some GUI programs could take advantage of trapping Xlib (or whatever) functions (LD_PRELOAD?) in order to embed plugin GUIs inside the app and/or have a library that autogenerates GUIs for non GUI-plugins (well... the XML GUI specification for LADSPA has been dropped in LV2 in favour of extensions?). ... it's such a complex matter :-P Regards, Stefano From steve at plugin.org.uk Wed Jan 24 10:53:42 2007 From: steve at plugin.org.uk (Steve Harris) Date: Wed Jan 24 11:45:42 2007 Subject: [linux-audio-dev] Sound processing objects architecture, is it possible? In-Reply-To: References: <160c13350701221108r1a5fff41v6130a9dc40e396d3@mail.gmail.com> Message-ID: <10531CB9-F5A1-42D1-B584-28C36739C529@plugin.org.uk> On 24 Jan 2007, at 15:06, Jay Vaughan wrote: > At 20:08 +0100 22/1/07, Stefano D'Angelo wrote: >> What I'd like to work on is a sound processing architecture (LADSPA, >> VST, DSSI, etc.) wrapper, which hides the details of a particular >> implementation to audio program developers. > > Nice idea. Already done: > > http://teragon.org/products/PluginCore/ > >> What do you think about it? > > Would be nice if there were a GPL effort in the same way .. Hum. I'm reminded of the often used thought process: "hmmm, there are way to many standards in this area, what we can do to improve things is add another, that would be great!". The way to help, IMHO, would be to make the existing systems compatible, using bridges/reflectors/wrappers, rather than creating more specs. - Steve From zanga.mail at gmail.com Wed Jan 24 11:02:29 2007 From: zanga.mail at gmail.com (Stefano D'Angelo) Date: Wed Jan 24 11:49:57 2007 Subject: [linux-audio-dev] JACK data transfers Message-ID: <160c13350701240802l6f848587kdaf739b98ab624ae@mail.gmail.com> Well... I know I'm quite a boring person, but I need some informations for my project and so I'm going to stress you a bit ;-) I'm wondering if JACK is suitable to transfer non-audio data beetween applications (my particular case is to transfer control data to processing plugins). Is that "naturally" possible, is it an hack or is it impossible at all? And another thing (I'm too lazy to check it out myself :-P): does jack transfers data by copying or uses something like shared memory or whatever? Thanks is advance. Stefano D'Angelo From paul at linuxaudiosystems.com Wed Jan 24 11:28:22 2007 From: paul at linuxaudiosystems.com (Paul Davis) Date: Wed Jan 24 12:08:00 2007 Subject: [linux-audio-dev] a new patent for us to challenge Message-ID: <1169656102.446.361.camel@localhost.localdomain> http://www.freshpatents.com/Low-latency-real-time-audio-streaming-dt20060406ptan20060074637.php?type=description in which Microsoft patents designs partially implemented by OSS 10 years ago and fully implemented by ALSA 5 years ago. Wrapping this up in windows API nonsense obscures the basic fact this design is not innovative in any way unless compared only to existing Windows audio driver architectures. From rah at bash.sh Wed Jan 24 11:54:35 2007 From: rah at bash.sh (Bob Ham) Date: Wed Jan 24 12:32:48 2007 Subject: [OT] Zionism and LAD (was: Re: [linux-audio-dev] an relevant link about Vista) In-Reply-To: <1169650857.5563.8.camel@localhost> References: <1169640192.2232.115.camel@orchid.arb.net> <1169650857.5563.8.camel@localhost> Message-ID: <1169657675.2232.242.camel@orchid.arb.net> On Wed, 2007-01-24 at 16:00 +0100, Leonard Ritter wrote: > FYI: you are all stupid monkeys - fact (it is. (really.)). Ook! -- Bob Ham -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20070124/fad0e0ee/attachment.bin From steve at plugin.org.uk Wed Jan 24 12:55:36 2007 From: steve at plugin.org.uk (Steve Harris) Date: Wed Jan 24 13:21:19 2007 Subject: [linux-audio-dev] Sound processing objects architecture, is it possible? In-Reply-To: <160c13350701240752i1cb3554dq3cef571bee02d437@mail.gmail.com> References: <160c13350701221108r1a5fff41v6130a9dc40e396d3@mail.gmail.com> <160c13350701240752i1cb3554dq3cef571bee02d437@mail.gmail.com> Message-ID: <6BC1F5FE-5422-41E3-9F14-118B5BB23A67@plugin.org.uk> On 24 Jan 2007, at 15:52, Stefano D'Angelo wrote: > 2007/1/24, Jay Vaughan : >> At 20:08 +0100 22/1/07, Stefano D'Angelo wrote: >> >What I'd like to work on is a sound processing architecture (LADSPA, >> >VST, DSSI, etc.) wrapper, which hides the details of a particular >> >implementation to audio program developers. >> >> Nice idea. Already done: >> >> http://teragon.org/products/PluginCore/ >> >> >What do you think about it? >> >> Would be nice if there were a GPL effort in the same way .. >> >> -- >> >> ; >> >> Jay Vaughan >> >> > > Well, it seems like LV2 can do (at least theorically) all of these > already, altough some things might be a bit tricky (read the rest of > the conversation). > Now I'm seeking whether this approach (LV2 bridges plugins) can > present practical problems and, in such case, I think it's better to > solve them in LV2 than restart from scratch. > To be true, there are two things I'm concerned about: one (less > relevant, maybe) is RDF files... a bridge plugin should generate them > for all installed plugins when it is loaded, and so it has to contain > (or link to) code that can handle such syntax (I really don't > understand why LV2 developers choose such language instead of XML, > which is much more known and supported). For one thing XML has no guarantee of extensibility, making it unsuitable. > The other one is more serious (but should have been also faced by > vstserver, fst and dssi-vst): I'm talking about logical compatibility > beetween LV2 and other standards (VST in this case) in handling some > tasks (settings and session storing, banks/effects/programs metaphor, > etc.). Does anyone know about these matters? That was outside the remit, LV2 1.0 was just intended to replace LADSPA, and LADSPA doesn't have those features. However, LV2 is designed to be easy to extend to include such things. > Then I think that it would be nice if some GUI programs could take > advantage of trapping Xlib (or whatever) functions (LD_PRELOAD?) in > order to embed plugin GUIs inside the app and/or have a library that > autogenerates GUIs for non GUI-plugins (well... the XML GUI > specification for LADSPA has been dropped in LV2 in favour of > extensions?). > ... it's such a complex matter :-P The tripping point is the X event loop. Allegedly GTK and Qt have compatible event loops, but that's still quite limiting, and I don't think anyone's built a proof of concept. - Steve From steve at plugin.org.uk Wed Jan 24 13:00:19 2007 From: steve at plugin.org.uk (Steve Harris) Date: Wed Jan 24 13:36:28 2007 Subject: [linux-audio-dev] JACK data transfers In-Reply-To: <160c13350701240802l6f848587kdaf739b98ab624ae@mail.gmail.com> References: <160c13350701240802l6f848587kdaf739b98ab624ae@mail.gmail.com> Message-ID: <017ACAD5-313E-4474-976D-82A4E34DFFF4@plugin.org.uk> On 24 Jan 2007, at 16:02, Stefano D'Angelo wrote: > Well... I know I'm quite a boring person, but I need some informations > for my project and so I'm going to stress you a bit ;-) > I'm wondering if JACK is suitable to transfer non-audio data beetween > applications (my particular case is to transfer control data to > processing plugins). Is that "naturally" possible, is it an hack or is > it impossible at all? You could encode control data in the audio stream, or build a bespoke JACK that add additional data types, or you could use the nascent JACK-MIDI stuff. You could also look at OSC, which, depending on your syncronisation needs could be a better fit. > And another thing (I'm too lazy to check it out myself :-P): does jack > transfers data by copying or uses something like shared memory or > whatever? It uses shared memory where possible. - Steve From zanga.mail at gmail.com Wed Jan 24 13:04:34 2007 From: zanga.mail at gmail.com (Stefano D'Angelo) Date: Wed Jan 24 13:40:57 2007 Subject: [linux-audio-dev] Sound processing objects architecture, is it possible? In-Reply-To: <10531CB9-F5A1-42D1-B584-28C36739C529@plugin.org.uk> References: <160c13350701221108r1a5fff41v6130a9dc40e396d3@mail.gmail.com> <10531CB9-F5A1-42D1-B584-28C36739C529@plugin.org.uk> Message-ID: <160c13350701241004s4474627by3da6bacfb1c061a9@mail.gmail.com> 2007/1/24, Steve Harris : > The way to help, IMHO, would be to make the existing systems > compatible, using bridges/reflectors/wrappers, rather than creating > more specs. > > - Steve Honestly I don't know about PluginCore, however that's not necessairly true. Although it is a completely different thing, take as an example GStreamer. If you compare a processing plugin to a media file and plugin development APIs to encodings... in the end they're quite similar! As I stated before, while in most cases bridges/reflectors/wrappers can be made quicker and safer, it must be ensured that there's logical equivalence beetween the two standards (or that the one you're writing the plugin for is logically a subset of the one you're going to use). Stefano From dsbaikov at gmail.com Wed Jan 24 13:36:14 2007 From: dsbaikov at gmail.com (Dmitry Baikov) Date: Wed Jan 24 14:16:44 2007 Subject: [linux-audio-dev] JACK data transfers In-Reply-To: <160c13350701240802l6f848587kdaf739b98ab624ae@mail.gmail.com> References: <160c13350701240802l6f848587kdaf739b98ab624ae@mail.gmail.com> Message-ID: <70a871c80701241036n3d6648fckd2cfa04667761ee7@mail.gmail.com> On 1/24/07, Stefano D'Angelo wrote: > I'm wondering if JACK is suitable to transfer non-audio data beetween > applications (my particular case is to transfer control data to > processing plugins). Is that "naturally" possible, is it an hack or is > it impossible at all? create new port type. or just use jackmidi. > And another thing (I'm too lazy to check it out myself :-P): then you have no chances. > does jack > transfers data by copying or uses something like shared memory or > whatever? it uses shared memory. Dmitry. From radarsat1 at gmail.com Wed Jan 24 13:44:49 2007 From: radarsat1 at gmail.com (Stephen Sinclair) Date: Wed Jan 24 14:24:24 2007 Subject: [linux-audio-dev] a new patent for us to challenge In-Reply-To: <1169656102.446.361.camel@localhost.localdomain> References: <1169656102.446.361.camel@localhost.localdomain> Message-ID: <9b3e2dc20701241044o5a2a22e8xc9ab1b28299e2083@mail.gmail.com> here's the uspto page for it: http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.html&r=1&f=G&l=50&s1=%2220060074637%22.PGNR.&OS=DN/20060074637&RS=DN/20060074637 I see that it is dated April 6, 2006. is this the date of application or the date that it was granted? steve On 1/24/07, Paul Davis wrote: > http://www.freshpatents.com/Low-latency-real-time-audio-streaming-dt20060406ptan20060074637.php?type=description > > in which Microsoft patents designs partially implemented by OSS 10 years > ago and fully implemented by ALSA 5 years ago. Wrapping this up in > windows API nonsense obscures the basic fact this design is not > innovative in any way unless compared only to existing Windows audio > driver architectures. > > > From k.s.matheussen at notam02.no Wed Jan 24 14:42:38 2007 From: k.s.matheussen at notam02.no (Kjetil S. Matheussen) Date: Wed Jan 24 15:02:35 2007 Subject: [linux-audio-dev] Re: Sound processing objects architecture, is it possible? In-Reply-To: <20070124184057.301C35F7FBF7@music.columbia.edu> References: <20070124184057.301C35F7FBF7@music.columbia.edu> Message-ID: Paul Davis: > > On Wed, 2007-01-24 at 16:06 +0100, Jay Vaughan wrote: >> At 20:08 +0100 22/1/07, Stefano D'Angelo wrote: >>> What I'd like to work on is a sound processing architecture (LADSPA, >>> VST, DSSI, etc.) wrapper, which hides the details of a particular >>> implementation to audio program developers. >> >> Nice idea. Already done: >> >> http://teragon.org/products/PluginCore/ >> >>> What do you think about it? >> >> Would be nice if there were a GPL effort in the same way .. > > ARDOUR::Plugin ? > > which currently wraps VST, LADSPA and will soon do either LV2 or > DSSI ... > > yeah, ok, so its partly in jest, but not entirely. > Another one is the "Juce Audio Plugin Framework", which wraps VSTs, RTAS and AudioUnits. http://www.rawmaterialsoftware.com/juce/download.php It doesn't support ladspa though, but Julian said that he should look at LV2. (He also said that he hadn't heard of LV2 before, so maybe he hasn't heard about ladspa either. :-) So if someone request ladspa, he might do that as well...) From k.s.matheussen at notam02.no Wed Jan 24 14:56:45 2007 From: k.s.matheussen at notam02.no (Kjetil S. Matheussen) Date: Wed Jan 24 15:14:22 2007 Subject: [linux-audio-dev] Re: Sound processing objects architecture, is it possible? In-Reply-To: References: <20070124184057.301C35F7FBF7@music.columbia.edu> Message-ID: On Wed, 24 Jan 2007, Kjetil S. Matheussen wrote: > > Paul Davis: >> >> On Wed, 2007-01-24 at 16:06 +0100, Jay Vaughan wrote: >> > At 20:08 +0100 22/1/07, Stefano D'Angelo wrote: >> > > What I'd like to work on is a sound processing architecture (LADSPA, >> > > VST, DSSI, etc.) wrapper, which hides the details of a particular >> > > implementation to audio program developers. >> > >> > Nice idea. Already done: >> > >> > http://teragon.org/products/PluginCore/ >> > >> > > What do you think about it? >> > >> > Would be nice if there were a GPL effort in the same way .. >> >> ARDOUR::Plugin ? >> >> which currently wraps VST, LADSPA and will soon do either LV2 or >> DSSI ... >> >> yeah, ok, so its partly in jest, but not entirely. >> > > Another one is the "Juce Audio Plugin Framework", which > wraps VSTs, RTAS and AudioUnits. > http://www.rawmaterialsoftware.com/juce/download.php > > It doesn't support ladspa though, but Julian said that he should > look at LV2. (He also said that he hadn't heard of LV2 before, > so maybe he hasn't heard about ladspa either. :-) So if someone > request ladspa, he might do that as well...) > Looking more closely at both PluginCore and the Juce Audio Plugin Framework, the latter is actually a GPL effort in the same way[1], except that it supports RTAS which PluginCore doesn't. So what you thought would be nice actually exists, except that the GPL alternative supports more formats. :-) [2] They are both wrappers to _write_ plugins, while Ardour is a wrapper to _run_ plugins. From danni.coy at gmail.com Wed Jan 24 16:28:09 2007 From: danni.coy at gmail.com (danni) Date: Wed Jan 24 16:28:39 2007 Subject: [linux-audio-dev] JACK data transfers In-Reply-To: <20070124184057.1AC145F7FBF6@music.columbia.edu> References: <20070124184057.1AC145F7FBF6@music.columbia.edu> Message-ID: <200701250728.10004.danni.coy@gmail.com> On a side note there is a discussion on the freebob list of whether to add a control api to Jack or just for freebob. On Thursday 25 January 2007 04:40, linux-audio-dev-request@music.columbia.edu wrote: > On 24 Jan 2007, at 16:02, Stefano D'Angelo wrote: > > Well... I know I'm quite a boring person, but I need some informations > > for my project and so I'm going to stress you a bit ;-) > > I'm wondering if JACK is suitable to transfer non-audio data beetween > > applications (my particular case is to transfer control data to > > processing plugins). Is that "naturally" possible, is it an hack or is > > it impossible at all? > > You could encode control data in the audio stream, or build a bespoke ? > JACK that add additional data types, or you could use the nascent ? > JACK-MIDI stuff. > > You could also look at OSC, which, depending on your syncronisation ? > needs could be a better fit. > > > And another thing (I'm too lazy to check it out myself :-P): does jack > > transfers data by copying or uses something like shared memory or > > whatever? > > It uses shared memory where possible. > > - Steve -- When it comes to broken marriages most husbands will split the blame -- half his wife's fault, and half her mother's. From steve at plugin.org.uk Thu Jan 25 03:43:51 2007 From: steve at plugin.org.uk (Steve Harris) Date: Thu Jan 25 03:44:04 2007 Subject: [linux-audio-dev] Sound processing objects architecture, is it possible? In-Reply-To: <160c13350701241004s4474627by3da6bacfb1c061a9@mail.gmail.com> References: <160c13350701221108r1a5fff41v6130a9dc40e396d3@mail.gmail.com> <10531CB9-F5A1-42D1-B584-28C36739C529@plugin.org.uk> <160c13350701241004s4474627by3da6bacfb1c061a9@mail.gmail.com> Message-ID: On 24 Jan 2007, at 18:04, Stefano D'Angelo wrote: > 2007/1/24, Steve Harris : >> The way to help, IMHO, would be to make the existing systems >> compatible, using bridges/reflectors/wrappers, rather than creating >> more specs. >> >> - Steve > > Honestly I don't know about PluginCore, however that's not > necessairly true. > Although it is a completely different thing, take as an example > GStreamer. If you compare a processing plugin to a media file and > plugin development APIs to encodings... in the end they're quite > similar! > As I stated before, while in most cases bridges/reflectors/wrappers > can be made quicker and safer, it must be ensured that there's logical > equivalence beetween the two standards (or that the one you're writing > the plugin for is logically a subset of the one you're going to use). Not necessarily. In my opinion, often a 90% solution that reuses existing technology is better than a 100% one that involves reinventing the wheel. Even if the new wheel is a bit more round :) It's all somewhat a matter of taste though. - Steve From shakti at bayarea.net Thu Jan 25 08:10:51 2007 From: shakti at bayarea.net (Tracey Hytry) Date: Thu Jan 25 08:18:09 2007 Subject: [OT] Zionism and LAD (was: Re: [linux-audio-dev] an relevant link about Vista) In-Reply-To: <1169650857.5563.8.camel@localhost> References: <1169640192.2232.115.camel@orchid.arb.net> <1169650857.5563.8.camel@localhost> Message-ID: <20070125051051.224dcb0a.shakti@bayarea.net> Leonard Ritter says: > FYI: you are all stupid monkeys - fact (it is. (really.)). > > now get back to work. Now that you have stated that which we all know is reality, yet refuse to acknowledge? Thanks, and great software write you do. If I was more daring I'd consider taking it for a spin and dream about going all the way with her. Tracey. From capocasa at gmx.net Thu Jan 25 12:26:49 2007 From: capocasa at gmx.net (Carlo Capocasa) Date: Thu Jan 25 12:27:23 2007 Subject: [linux-audio-dev] Re: a new patent for us to challenge In-Reply-To: <1169656102.446.361.camel@localhost.localdomain> References: <1169656102.446.361.camel@localhost.localdomain> Message-ID: Quick linux audio user's guide to challenging patents? From seablaede at gmail.com Thu Jan 25 13:40:34 2007 From: seablaede at gmail.com (Thomas Vecchione) Date: Thu Jan 25 13:33:33 2007 Subject: [linux-audio-dev] a new patent for us to challenge In-Reply-To: <9b3e2dc20701241044o5a2a22e8xc9ab1b28299e2083@mail.gmail.com> References: <1169656102.446.361.camel@localhost.localdomain> <9b3e2dc20701241044o5a2a22e8xc9ab1b28299e2083@mail.gmail.com> Message-ID: <45B8F9A2.70001@gmail.com> > > I see that it is dated April 6, 2006. is this the date of application > or the date that it was granted? Filed: October 1, 2004 I would then assume that is the granted date, either way it was most certainly not filed before the 5 year mark that Paul mentioned. Seablade From zanga.mail at gmail.com Thu Jan 25 13:34:00 2007 From: zanga.mail at gmail.com (Stefano D'Angelo) Date: Thu Jan 25 13:35:05 2007 Subject: [linux-audio-dev] Sound processing objects architecture, is it possible? In-Reply-To: References: <160c13350701221108r1a5fff41v6130a9dc40e396d3@mail.gmail.com> <10531CB9-F5A1-42D1-B584-28C36739C529@plugin.org.uk> <160c13350701241004s4474627by3da6bacfb1c061a9@mail.gmail.com> Message-ID: <160c13350701251034h6f1cb89cs10875c2b31fdfdf@mail.gmail.com> > It's all somewhat a matter of taste though. I do agree :-) From zanga.mail at gmail.com Thu Jan 25 13:34:27 2007 From: zanga.mail at gmail.com (Stefano D'Angelo) Date: Thu Jan 25 13:36:08 2007 Subject: [linux-audio-dev] JACK data transfers In-Reply-To: <200701250728.10004.danni.coy@gmail.com> References: <20070124184057.1AC145F7FBF6@music.columbia.edu> <200701250728.10004.danni.coy@gmail.com> Message-ID: <160c13350701251034r2d5eeeb3pc4d47c08823cfef3@mail.gmail.com> Thanks a lot to everyone :-) Stefano From capocasa at gmx.net Thu Jan 25 14:28:35 2007 From: capocasa at gmx.net (Carlo Capocasa) Date: Thu Jan 25 14:28:33 2007 Subject: [linux-audio-dev] Re: an relevant link about Vista In-Reply-To: <3c808a150701160244i65d470bbhee5cb17127059a31@mail.gmail.com> References: <45AB8DB1.1050307@woh.rr.com> <20070115223056.123ebe08@localhost> <20070116031322.0c33c628@localhost.localdomain> <3c808a150701160244i65d470bbhee5cb17127059a31@mail.gmail.com> Message-ID: > We need more moderators on the list, mail me ;-) Hey ho, thought police! Let us all think right and be right and have someone else decide on what that 'right' actually means! What I'm getting at is, you have absolutely no way of knowing whether or not Israel actually is an Apartheid state, or how that might or might not be relevant to this list. What's with the people who might want to write a song about Israel and/or Apartheid? Oh right, that's not important, we have more important things to do, we are all about National Security, and stray thinkers are a danger, so we must silence them with whatever means necessary to us. So in come the moderators and you have to watch your step around here before you say anything about Jews or you get busted. Now personally I couldn't give a bit more about what Jews aren't or are doing, but it seems every time you mention them everybody goes nuts. What goes? What's REALLY behind this? Carlo From mobarre at gmail.com Fri Jan 26 07:49:39 2007 From: mobarre at gmail.com (Marc-Olivier Barre) Date: Fri Jan 26 07:49:59 2007 Subject: [linux-audio-dev] Apologies (was: Re: an relevant link about Vista) Message-ID: <3c808a150701260449h4b4590bfg6cc167891757d74f@mail.gmail.com> On 1/25/07, Carlo Capocasa wrote: > > We need more moderators on the list, mail me ;-) > > Hey ho, thought police! Let us all think right and be right and have > someone else decide on what that 'right' actually means! > > What I'm getting at is, you have absolutely no way of knowing whether or > not Israel actually is an Apartheid state, or how that might or might > not be relevant to this list. > > What's with the people who might want to write a song about Israel > and/or Apartheid? Oh right, that's not important, we have more important > things to do, we are all about National Security, and stray thinkers are > a danger, so we must silence them with whatever means necessary to us. > > So in come the moderators and you have to watch your step around here > before you say anything about Jews or you get busted. > > Now personally I couldn't give a bit more about what Jews aren't or are > doing, but it seems every time you mention them everybody goes nuts. > What goes? What's REALLY behind this? > > Carlo > > I think I own everyone an apology for being part of all the fuss that has been going on the list for a few days now. When I wrote the above quoted sentence I did not imagine the (disproportionate) consequences this would have, and more importantly never intended to imply that a moderator was here to control if what was said on the list was right or wrong thinking. Although I do think that as a moderator and administrator myself I need to make sure a certain ethic is respected, the best way to deal with the original problematic message was just to ignore it, since the replies only caused a flame war. Concerning the need to decrease the work load of moderating the list, I propose another approach : As discussed previously on the list, we will certainly move to linuxaudio.org. Let's use this opportunity to tune mailman to our needs. There are not so much actual message that fall into the 'in-need-of-moderation' category. There are two actually : non-member messages and HTML messages. The biggest part of the job is to filter spam. My idea is to find a way to tweak (or apply an existing patch to) mailman so that messages marked as spam get discarded automatically, and also to be able to feed spamassassin with new spam samples directly from the moderation page. If you are willing to help, if you know of an existing solution or if you happen to have ideas concerning this, please, drop me an email. It is as of this momment the best way to help, and is the first step towards making moderation faster for every one. Again accept all my appologies. __________________ Marc-Olivier Barre, Markinoko. From frsmith at gmail.com Tue Jan 23 08:45:05 2007 From: frsmith at gmail.com (Frank Smith) Date: Fri Jan 26 08:02:24 2007 Subject: [linux-audio-dev] interview with Rui Nuno Capela In-Reply-To: <45B60AF6.7030700@woh.rr.com> References: <45B60AF6.7030700@woh.rr.com> Message-ID: HI Dave It could be time for another book of yours!! How's going? Just got back on the lists myself. They doing the thing in Bristol again this year? Bob (bearmusic) Now wavesound On 23/01/07, Dave Phillips wrote: > > Greetings: > > I've placed online an interview with Rui Capela, the creator of > QJackCtl, QSynth, QSampler, and QTractor. You can read it here: > > http://www.linuxjournal.com > > Enjoy! > > Best, > > dp > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20070123/042abc97/attachment.html From frsmith at gmail.com Tue Jan 23 13:49:38 2007 From: frsmith at gmail.com (Frank Smith) Date: Fri Jan 26 08:02:29 2007 Subject: [linux-audio-dev] Sample Rate Converter Comparison In-Reply-To: <4398.192.168.1.15.1169573712.squirrel@www.infotecna.lcl> References: <20070123085313.7d2fe3ae.mle+la@mega-nerd.com> <4398.192.168.1.15.1169573712.squirrel@www.infotecna.lcl> Message-ID: Hi I need help!! I have just installed 64studio on a SATA disk (Hitachi 250 gig) I have windoze on the first disk (HDA) and Ubuntu 32bit on the Secondary Master HDC (?) I did have an ide 150 gig but SMART informed me it was bad this originally had 64studio on it. I have removed the 150 and got the sata 250 for 64studio. After installing It asked to write the boot to the MBR I said yes. Now I can't boot at all no grub nothing just a cursor blinking at me, black screen. Any ideas how I get my stuff back the ubuntu stuff I really need. Cheers Bob -------------- next part -------------- An HTML attachment was scrubbed... URL: http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20070123/10210eea/attachment.html From frsmith at gmail.com Tue Jan 23 15:15:01 2007 From: frsmith at gmail.com (Frank Smith) Date: Fri Jan 26 08:02:33 2007 Subject: [linux-audio-dev] Cannot boot 64Studio from SATA frive Message-ID: HI Just wondering if this will get through from my Gmail act. I have loaded 64studio onto my only new SATA drive and now cannot boot at all ( black screen cursor only) Anyone any idea how I goot the machine? Or do I need to reinstall it all again. ( It did ask to install grub to the MBR and I said yes) Many thanks Bob wavesound -------------- next part -------------- An HTML attachment was scrubbed... URL: http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20070123/431ec8ff/attachment.html From klaus_zimmermann at gmx.de Fri Jan 26 08:15:22 2007 From: klaus_zimmermann at gmx.de (Klaus Zimmermann) Date: Fri Jan 26 08:15:38 2007 Subject: [linux-audio-dev] Cannot boot 64Studio from SATA frive In-Reply-To: References: Message-ID: <1169817322.7686.5.camel@localhost> I don't think you need to reinstall. Doesn't ubuntu include a live cd? Boot that one (or in fact any other live linux cd), chroot to your ubuntu root, mount boot and execute grub-install. Of course first verify that it's not only a booting sequence gone awry :) In details: 1) Boot live cd. 2) Get to a console as root. In ubuntu: Applications->Tools(?)->Terminal, sudo gnome-terminal. 3) Chroot to root: i) mount your ubuntu root somewhere (let's assume /media/ubu) ii) chroot /media/ubu 4) mount -a 5) grub-install /dev/sda1, where /dev/sda1 is your booter. Good luck, Klaus From mdeboer at iua.upf.edu Fri Jan 26 09:39:57 2007 From: mdeboer at iua.upf.edu (Maarten de Boer) Date: Fri Jan 26 09:42:40 2007 Subject: [linux-audio-dev] Apologies (was: Re: an relevant link about Vista) In-Reply-To: <3c808a150701260449h4b4590bfg6cc167891757d74f@mail.gmail.com> References: <3c808a150701260449h4b4590bfg6cc167891757d74f@mail.gmail.com> Message-ID: <20070126153957.52b9ee46.mdeboer@iua.upf.es> > spam. My idea is to find a way to tweak (or apply an existing patch > to) mailman so that messages marked as spam get discarded > automatically mailman on my mailserver (Ubuntu Dapper out of the box) has this option: Privacy options... [Spam filters] Header filters Filter rules to match against the headers of a message. In my case, I use the following: regex: Subject:.*\{Spam\?\} Action: reject From fraser at arkhostings.com Sat Jan 27 00:05:58 2007 From: fraser at arkhostings.com (Fraser) Date: Sat Jan 27 00:11:56 2007 Subject: [linux-audio-dev] LADSPA needs & wishes Message-ID: <38603.150.101.126.38.1169874358.squirrel@mail.arkhostings.com> Hi All, I've been converting my old VST plugins over to LADSPA and have come across something in the api which I really miss - the inability separate the algorithmic to the displayed value of a parameter. I'm finding this inability is leading to non-ideal programming habits. Let me show what I mean with a few examples. I have a control that represents a gain knob (say -12dB -> 12dB): What's best for the run function is a value that represents the ratio which I can simply multiply the audio by as it it keeps the maths simple (0.25 -> 4). What's best for display is decibels (as that is way gain is understood). I can't do this with LADSPA - so as I programmer I'm left with a lose-lose choice. * I either choose a parameter range of -12 -> 12 (dB) and convert that to a ratio every time the run function is called: fGain = pow(10, *(psMyPlugin->m_pfControlGain) /20); Which is an unnecessary use of cpu. (and as someone who has mixed many albums on computers you need every scap of cpu you can get) * Or I choose to use 0.25 -> 4 as my range. Now users are faced with a parameter they don't intuitively understand (it is contrary to every other bit of audio gear they have ever used) - most people cannot do 20*Log10(Gain) in their heads to work out the equivalent value in dB. Of the two choices I choose the first, better to eat up too much cpu than to have an interface that is unintuitive, but this is not ideal. This gets worse when you have a control for something like 'warmth'. The user does not need to know the range of values required to apply warmth in an efficient manner (it won't mean anything to them), they just need to know how much (0%-100%). Another example - presets I have a control that allows an operator to chose one of fifty presets (say a reverb with small room, medium room, large room, hall etc). I don't have a choice this time. Internally using an integer to represent the different presets is fine, it's exactly all I need. However even though I know what the preset is, I cannot display it's name back to the user, so our user is left with a set of meaningless numbers which they must resolve into names by some other means (print the doco out and stick it on the wall?) What I'd find useful in the api is an optional 'get_display' function which allows the host app to get a human interpretation of a parameter for display. It would only need to be called when a plugin windows is opened or when a parameter is changed. Since the host has to convert the parameter to a string in order to display it anyway, this is not a extra step overall. We are just bringing it into the realm of the plugin. /* pseudo code */ void GetMyDisplay(char *stDisplay, int Size, unsigned long Port) { stTemp[LADSPA_MAX_EVER_DISPLAY_SIZE); switch(Port) { case MY_GAINCONTROL: sprintf(stTemp,"%4.1f dB",20*log10(PortValue)); stTemp[Size-1]='\0'; /* truncate it to what the host wants*/ strncopy(stDisplay,stTemp,Size); break; case MY_WARMTHCONTROL: sprintf(stTemp,"%4.1f %%",some_complex_function(PortValue)); stTemp[Size-1]='\0'; /* truncate it to what the host wants*/ strncopy(stDisplay,stTemp,Size); break; } } Now for a wish. GUI - under OSX or windows this isn't such a big drama, there's only one GUI environment to deal with. under Linux it's a different matter. I sometimes think the best thing to do is to provide enough hints to the host so it can render a more comprehensive gui, if it desires, rather than the plugin drawing the gui as is traditionally done. This would entail a few things. 1) Utilize ports of type: LADSPA_PORT_OUTPUT | LADSPA_PORT_CONTROL what is that? -> it's a meter, a light, etc We'd just need some hints defined and the rest is up to the host (most host apps already have their own audio specific widgets. we just need to tell them which ones we want to use). These all need to be bounded as any other control would be. /* a peak meter, expects a ratio not a dB value */ LADSPA_HINT_METER_PEAK /* a vu meter, expects a ratio not a dB value */ LADSPA_HINT_METER_VU /* Some meters like gain reduction meters in a compressor meter backwards, ie illuminated from max value downwards rather than minimum value upwards */ LADSPA_HINT_METER_REVERSED /* a simple on/off light */ LADSPA_HINT_LIGHT_ONOFF /* a light which has intesity */ LADSPA_HINT_LIGHT_INTENSITY 2) Add control layout to the port definitions Could be done as by defining arbitrary bounding boxes. /* * +----------+------+ * | gain | | * +----------+ meter| * | warmth | | * +----------+------+ */ PortLayoutHints[MY_GAIN].top=0; PortLayoutHints[MY_GAIN].bot=1; PortLayoutHints[MY_GAIN].left=0; PortLayoutHints[MY_GAIN].right=3; PortLayoutHints[MY_WARMTH].top=1; PortLayoutHints[MY_WARMTH].bot=2; PortLayoutHints[MY_WARMTH].left=0; PortLayoutHints[MY_WARMTH].right=3; PortLayoutHints[MY_METER].top=0; PortLayoutHints[MY_METER].bot=2; PortLayoutHints[MY_METER].left=3; PortLayoutHints[MY_METER].right=5; 3) Customization - control colours in the layout hints - background & logo images in the descriptor etc This would all be optional for the host Thanks for taking the time to read though all this, turned out to be longer than I anticipated! regards, Fraser From loki.davison at gmail.com Sat Jan 27 00:47:09 2007 From: loki.davison at gmail.com (Loki Davison) Date: Sat Jan 27 00:47:24 2007 Subject: [linux-audio-dev] LADSPA needs & wishes In-Reply-To: <38603.150.101.126.38.1169874358.squirrel@mail.arkhostings.com> References: <38603.150.101.126.38.1169874358.squirrel@mail.arkhostings.com> Message-ID: On 1/27/07, Fraser wrote: > Hi All, > > I've been converting my old VST plugins over to LADSPA and have come > across something in the api which I really miss - the inability separate > the algorithmic to the displayed value of a parameter. > I'm finding this inability is leading to non-ideal programming habits. > > why are you coding new stuff for a depreciated system??Why not LV2? It's extensible so if anything is missing you can add it. http://lv2plug.in/ Loki p.s. hiking in yunnan / tibet border area is pretty awesome! From lars.luthman at gmail.com Sat Jan 27 01:09:04 2007 From: lars.luthman at gmail.com (Lars Luthman) Date: Sat Jan 27 01:09:55 2007 Subject: [linux-audio-dev] LADSPA needs & wishes In-Reply-To: <38603.150.101.126.38.1169874358.squirrel@mail.arkhostings.com> References: <38603.150.101.126.38.1169874358.squirrel@mail.arkhostings.com> Message-ID: <1169878144.3674.14.camel@box.lars> On Sat, 2007-01-27 at 16:05 +1100, Fraser wrote: > Hi All, > > I've been converting my old VST plugins over to LADSPA and have come > across something in the api which I really miss - the inability separate > the algorithmic to the displayed value of a parameter. > I'm finding this inability is leading to non-ideal programming habits. There is the LADSPA_HINT_LOGARITHMIC port hint, which does part of what you want - it tells the host that any knob or slider should use a logarithmic mapping, but it doesn't give any display values. In LV2 this will be done with the :scalePoint property, which you can use to label the real value 1 as "0dB", 0.5 as "-3dB" and so on. > Another example - presets > > I have a control that allows an operator to chose one of fifty presets > (say a reverb with small room, medium room, large room, hall etc). I don't > have a choice this time. Internally using an integer to represent the > different presets is fine, it's exactly all I need. > However even though I know what the preset is, I cannot display it's name > back to the user, so our user is left with a set of meaningless numbers > which they must resolve into names by some other means (print the doco out > and stick it on the wall?) Presets are done in LADSPA using the additional library liblrdf, which a number of hosts (though not all) support. "Internal" presets could be done in LV2 using an integer port and scalePoint labels. > Now for a wish. > > GUI - under OSX or windows this isn't such a big drama, there's only one > GUI environment to deal with. under Linux it's a different matter. > > I sometimes think the best thing to do is to provide enough hints to the > host so it can render a more comprehensive gui, if it desires, rather than > the plugin drawing the gui as is traditionally done. This would entail a > few things. There have been some suggestions for GUI "markup" standards for LADSPA, I don't know if any real hosts have supported them. It's not a bad idea as such. Another approach is DSSI (http://dssi.sf.net, an "instrument" extension of the LADSPA spec) which does GUIs using standalone programs distributed with the plugin that communicates with the host using OSC. --ll -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20070127/77d2f181/attachment.bin From rj at spamatica.se Sat Jan 27 06:36:09 2007 From: rj at spamatica.se (Robert Jonsson) Date: Sat Jan 27 06:37:43 2007 Subject: [linux-audio-dev] LADSPA needs & wishes In-Reply-To: References: <38603.150.101.126.38.1169874358.squirrel@mail.arkhostings.com> Message-ID: <200701271236.09850.rj@spamatica.se> On Saturday 27 January 2007 06:47, Loki Davison wrote: > On 1/27/07, Fraser wrote: > > Hi All, > > > > I've been converting my old VST plugins over to LADSPA and have come > > across something in the api which I really miss - the inability separate > > the algorithmic to the displayed value of a parameter. > > I'm finding this inability is leading to non-ideal programming habits. > > why are you coding new stuff for a depreciated system? Why not LV2? And why should you code for a plugin standard that nothing supports? Besides, is LV2 even finished? Suggesting that LADSPA is deprecated is a bit of a stretch. It may not be perfect, but it's well supported. /Robert > It's extensible so if anything is missing you can add it. > http://lv2plug.in/ > > Loki > > p.s. > > hiking in yunnan / tibet border area is pretty awesome! From paul at linuxaudiosystems.com Sat Jan 27 08:07:00 2007 From: paul at linuxaudiosystems.com (Paul Davis) Date: Sat Jan 27 08:07:37 2007 Subject: [linux-audio-dev] LADSPA needs & wishes In-Reply-To: <38603.150.101.126.38.1169874358.squirrel@mail.arkhostings.com> References: <38603.150.101.126.38.1169874358.squirrel@mail.arkhostings.com> Message-ID: <1169903220.18649.50.camel@localhost.localdomain> On Sat, 2007-01-27 at 16:05 +1100, Fraser wrote: > Hi All, > > I've been converting my old VST plugins over to LADSPA and have come > across something in the api which I really miss - the inability separate > the algorithmic to the displayed value of a parameter. > I'm finding this inability is leading to non-ideal programming habits. > the first issue you raise is a basic flaw in LADSPA's design that we tried to patch over with the hint stuff. there is no real solution for it that i know of - its just a dumb piece of design on our part. however, it and i think all the other issues you raise are all solved by LV2 (LADSPA Version 2), which has come about in part from other people's difficulties with the same range of problems as you. i would personally recommend: 1) do a LADSPA version and just suck up to the nasty display issues of showing the user the raw value unless its an SR-related parameter 2) be ready to take the core of your plugin and release it as an LV2 plugin once adoption of it by a couple of hosts emerges. it will be very easy to do this, and will open up a world of new possibilities. the bottom line is that the problems you have identified have been identified before, and the solution is LV2. they will not be fixed as part of LADSPA v1 because the fix has already been designed and in some senses implemented. --p From nedko at arnaudov.name Sat Jan 27 13:57:26 2007 From: nedko at arnaudov.name (Nedko Arnaudov) Date: Sat Jan 27 15:59:25 2007 Subject: [linux-audio-dev] LADSPA needs & wishes In-Reply-To: <200701271236.09850.rj@spamatica.se> (Robert Jonsson's message of "Sat, 27 Jan 2007 12:36:09 +0100") References: <38603.150.101.126.38.1169874358.squirrel@mail.arkhostings.com> <200701271236.09850.rj@spamatica.se> Message-ID: <87sldwz4a1.fsf@arnaudov.name> Robert Jonsson writes: > On Saturday 27 January 2007 06:47, Loki Davison wrote: >> On 1/27/07, Fraser wrote: >> > Hi All, >> > >> > I've been converting my old VST plugins over to LADSPA and have come >> > across something in the api which I really miss - the inability separate >> > the algorithmic to the displayed value of a parameter. >> > I'm finding this inability is leading to non-ideal programming habits. >> >> why are you coding new stuff for a depreciated system? Why not LV2? > > And why should you code for a plugin standard that nothing supports? > Besides, is LV2 even finished? > Suggesting that LADSPA is deprecated is a bit of a stretch. It may not be > perfect, but it's well supported. > nothing? i'm aware of 3 hosts that can host lv2 plugins. maybe there are others i'm not aware of. -- Nedko Arnaudov -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20070127/f8458d2d/attachment-0001.bin From cannam at all-day-breakfast.com Sat Jan 27 16:53:16 2007 From: cannam at all-day-breakfast.com (Chris Cannam) Date: Sat Jan 27 16:52:19 2007 Subject: [linux-audio-dev] LADSPA needs & wishes In-Reply-To: <87sldwz4a1.fsf@arnaudov.name> References: <38603.150.101.126.38.1169874358.squirrel@mail.arkhostings.com> <200701271236.09850.rj@spamatica.se> <87sldwz4a1.fsf@arnaudov.name> Message-ID: <200701272153.16994.cannam@all-day-breakfast.com> On Saturday 27 Jan 2007 18:57, Nedko Arnaudov wrote: > Robert Jonsson writes: > > On Saturday 27 January 2007 06:47, Loki Davison wrote: > >> why are you coding new stuff for a depreciated system? Why not > >> LV2? > > > > And why should you code for a plugin standard that nothing > > supports? [...] > > nothing? i'm aware of 3 hosts that can host lv2 plugins. What are they? Do they do anything else, besides host LV2 plugins? There does seem to be a habit here for people to describe things as "deprecated", when what they mean is they don't like them very much themselves, they no longer consider them state of the art, and there's a technically better alternative that isn't widely supported yet. (The ALSA sequencer API is another current example.) It's an arrogant and antisocial habit. For someone who wants to write effects plugins for a reasonably large audience of Linux users to use right now, there's one choice: LADSPA. DSSI has been a technically better choice for a few years now, but it has few hosts and I'm not sure whether all of those even support DSSI plugins as effects -- although they should. LV2 is also a technically better choice, but even less widely supported so far. That will change, but it's far too soon to be suggesting it's the only Linux plugin API worth writing for, especially as porting from LADSPA to LV2 (and/or supporting both) should be easy enough. You can argue for driving adoption of LV2 by writing cool plugins for it, but that's quite different from saying you shouldn't be writing for LADSPA at all. Chris From ico at vt.edu Sat Jan 27 18:33:59 2007 From: ico at vt.edu (Ivica Ico Bukvic) Date: Sat Jan 27 18:36:25 2007 Subject: [linux-audio-dev] LADSPA needs & wishes In-Reply-To: <87sldwz4a1.fsf@arnaudov.name> Message-ID: <001a01c7426b$a0b1a8c0$0702a8c0@64BitBadass> > > Suggesting that LADSPA is deprecated is a bit of a stretch. It may not > be > > perfect, but it's well supported. What would be really nice for LA scene is to clean up the available Ladspa plugins so that they all "just work" while there is still a momentum to maintain these. Unless this has changed recently, LADSPA libs are like a minefield--some work while others crash bringing down the whole audio setup with them. Has there been any progress made on this? Best wishes, Ico From fraser at arkhostings.com Sun Jan 28 00:07:54 2007 From: fraser at arkhostings.com (Fraser) Date: Sun Jan 28 00:09:04 2007 Subject: [linux-audio-dev] LADSPA needs & wishes In-Reply-To: <1169903220.18649.50.camel@localhost.localdomain> References: <1169903220.18649.50.camel@localhost.localdomain> Message-ID: <44150.150.101.126.38.1169960874.squirrel@mail.arkhostings.com> Hi Paul, > however, it and i think all the other issues you raise are all solved by > LV2 (LADSPA Version 2), which has come about in part from other people's > difficulties with the same range of problems as you. ahh, so there is a V2 coming, not too much info about it yet out there (unless you know where to look) >From my quick look at the LV2 spec there's something I'd like to see (this is just my 2c): The plugin doesn't know when a parameter has changed, so it must calculate it's internal values from the displayed parameter 'as often as possible' - once per run() call (doing it in the for loop itself is just too extreme). ie from http://lv2plug.in/plugins/Amp-example.lv2/amp.c #define DB_CO(g) ((g) > -90.0f ? powf(10.0f, (g) * 0.05f) : 0.0f) static void runAmp(LV2_Handle instance, unsigned long sample_count) { Amp *plugin_data = (Amp *)instance; const float gain = *(plugin_data->gain); const float * const input = plugin_data->input; float * const output = plugin_data->output; unsigned long pos; float coef = DB_CO(gain); <----- for (pos = 0; pos < sample_count; pos++) { output[pos] = input[pos] * coef; } } better (to me anyway) is to get the run loop down to actually processing audio and do the conversion elsewhere ie static void runAmp(LV2_Handle instance, unsigned long sample_count) { Amp *plugin_data = (Amp *)instance; const float * const input = plugin_data->input; float * const output = plugin_data->output; unsigned long pos; for (pos = 0; pos < sample_count; pos++) { output[pos] = input[pos] * plugin_data->MyTranslatedGain; } } To do that though the plugin needs to be told when a parameter has changed so it can work out the new internal value. #define DB_CO(g) ((g) > -90.0f ? powf(10.0f, (g) * 0.05f) : 0.0f) static void paramAmp(LV2_Handle instance, unsigned long port) { Amp *plugin_data = (Amp *)instance; switch (port) { case AMP_GAIN: plugin_data->MyTranslatedGain = DB_CO(*(plugin_data->gain)); break; } } and a new function in the descriptor ampDescriptor->param = paramAmp; This has the following advantages 1) run() just runs (saved a bit of cpu) 2) internal values are only calculated when the parameter they are associated with changes 3) changes to parameters can be presented to the run() function immediately 4) the plugin knows when a parameter changed and so can smooth jumps in values itself (rather then hoping to host is doing it) with 1 param it's not a big deal, but when you have 10 and end up with half a page of complex maths in your run() just in case a parameter changed from the last call you begin to wish it was elsewhere... > i would personally recommend: > > 1) do a LADSPA version and just suck up to the nasty display issues > of showing the user the raw value unless its an SR-related parameter > > 2) be ready to take the core of your plugin and release it as an LV2 > plugin once adoption of it by a couple of hosts emerges. it will be very > easy to do this, and will open up a world of new possibilities. ok will do, looking forward to LV2 regards, Fraser From loki.davison at gmail.com Sun Jan 28 08:01:04 2007 From: loki.davison at gmail.com (Loki Davison) Date: Sun Jan 28 08:02:14 2007 Subject: [linux-audio-dev] LADSPA needs & wishes In-Reply-To: <200701272153.16994.cannam@all-day-breakfast.com> References: <38603.150.101.126.38.1169874358.squirrel@mail.arkhostings.com> <200701271236.09850.rj@spamatica.se> <87sldwz4a1.fsf@arnaudov.name> <200701272153.16994.cannam@all-day-breakfast.com> Message-ID: On 1/28/07, Chris Cannam wrote: > On Saturday 27 Jan 2007 18:57, Nedko Arnaudov wrote: > > Robert Jonsson writes: > > > On Saturday 27 January 2007 06:47, Loki Davison wrote: > > >> why are you coding new stuff for a depreciated system? Why not > > >> LV2? > > > > > > And why should you code for a plugin standard that nothing > > > supports? [...] > > > > nothing? i'm aware of 3 hosts that can host lv2 plugins. > > What are they? Do they do anything else, besides host LV2 plugins? > > There does seem to be a habit here for people to describe things as > "deprecated", when what they mean is they don't like them very much > themselves, they no longer consider them state of the art, and there's > a technically better alternative that isn't widely supported yet. (The > ALSA sequencer API is another current example.) It's an arrogant and > antisocial habit. > > mmm. I'm sorry for my arrogant and antisocial habits. I had once again a little bit of food poisioning or something and i'd just been hiking near tibet and hadn't had a shower for 1 and half weeks. I was more aiming at getting at there is not point in suggesting problems/issues with the ladspa spec as it is no longer being developed. So either you deal with it's downsides or you write LV2 plugins. It's not like i can really talk as i haven't ported any of my own ladspa plugins to LV2. As far as hosts go ingen supports lv2 and is a quite powerful host. Then again no sequencer or DAW that i know of... ;) then again i'm quite out of the loop at the moment. Loki p.s i hope this doesn't come across as arrogant, your comments about nothing may seem that way to the authors of those hosts. From steve at plugin.org.uk Sun Jan 28 10:01:26 2007 From: steve at plugin.org.uk (Steve Harris) Date: Sun Jan 28 11:07:23 2007 Subject: [linux-audio-dev] LADSPA needs & wishes In-Reply-To: <44150.150.101.126.38.1169960874.squirrel@mail.arkhostings.com> References: <1169903220.18649.50.camel@localhost.localdomain> <44150.150.101.126.38.1169960874.squirrel@mail.arkhostings.com> Message-ID: <07CA2065-FC53-4BBE-B211-C4D83755AE0C@plugin.org.uk> On 28 Jan 2007, at 05:07, Fraser wrote: > >> however, it and i think all the other issues you raise are all >> solved by >> LV2 (LADSPA Version 2), which has come about in part from other >> people's >> difficulties with the same range of problems as you. > > ahh, so there is a V2 coming, not too much info about it yet out there > (unless you know where to look) Which is deliberate, as it's not quite finished yet. There was quite a lot of discussion here though. On the "natural" parameter values, I really rather like it that way. Sure, it costs a bit of CPU to do the conversion, but it means that different plugins of the same type are more likely to be compatible, and it makes wiring up things in a modular synth style easier. It also means that things like preset files contain the same values as the live display, which is helpful. When it comes to burning a bit of extra CPU power to make the users life easier, I'm all for it. >> From my quick look at the LV2 spec there's something I'd like to >> see (this > is just my 2c): > > The plugin doesn't know when a parameter has changed, so it must > calculate > it's internal values from the displayed parameter 'as often as > possible' - > once per run() call (doing it in the for loop itself is just too > extreme). Sure. This was an issue in LADSPA, though not a significant enough one that anyone wanted it changed. I would suspect you're overestimating the burden compared to the function call overhead and cache thrashing. I'd be interested to see figures indicating otherwise though. There will obviously be cases where it's faster to set values using callbacks, but I'll bet it's not universal. It's also quite convenient for both the plugin and host not to have to provide/call callbacks for every parameter. ... > This has the following advantages > 1) run() just runs (saved a bit of cpu) But costs you some extra function calls, and makes the CPU load dependent on the frequency of changes, which makes predictably hitting RT deadlines harder. > 2) internal values are only calculated when the parameter they are > associated with changes True. > 3) changes to parameters can be presented to the run() function > immediately I don't see how it makes any difference in this area? > 4) the plugin knows when a parameter changed and so can smooth > jumps in > values itself (rather then hoping to host is doing it) Either way the plugin is free to do parameter smoothing. Typically I just do a linear interpolation and/or a 1st order LP filter. - Steve From zanga.mail at gmail.com Sun Jan 28 13:39:04 2007 From: zanga.mail at gmail.com (Stefano D'Angelo) Date: Sun Jan 28 14:07:31 2007 Subject: [linux-audio-dev] Sound processing plugins' crashes Message-ID: <160c13350701281039i4de74646ia7cb4c7d27ca91fb@mail.gmail.com> Hi, maybe it's just another of my dumb questions, however I would like to know whether it is happened to you that a sound processing plugin (LADSPA, LV2, VST, etc.) crashed (segm. faults, etc.). In such case, can you estimate how often does it happen that such plugins are misprogrammed? Thanks in advance, Stefano From fraser at arkhostings.com Sun Jan 28 21:18:11 2007 From: fraser at arkhostings.com (Fraser) Date: Sun Jan 28 21:18:30 2007 Subject: [linux-audio-dev] LADSPA needs & wishes In-Reply-To: <07CA2065-FC53-4BBE-B211-C4D83755AE0C@plugin.org.uk> References: <07CA2065-FC53-4BBE-B211-C4D83755AE0C@plugin.org.uk> Message-ID: <40555.150.101.126.38.1170037091.squirrel@mail.arkhostings.com> Hi Steve, >> ahh, so there is a V2 coming, not too much info about it yet out there >> (unless you know where to look) > > Which is deliberate, as it's not quite finished yet. There was quite > a lot of discussion here though. I took me a while to find this list. The http://www.ladspa.org site refers to the linux audio developers mailing list as being here: http://www.linuxaudiodev.com/ which has had nothing but a holding page since the middle of last year... > Sure. This was an issue in LADSPA, though not a significant enough > one that anyone wanted it changed. I would suspect you're > overestimating the burden compared to the function call overhead and > cache thrashing. I'd be interested to see figures indicating > otherwise though. There will obviously be cases where it's faster to > set values using callbacks, but I'll bet it's not universal. Perhaps I am yes. I am more thinking about the consequences of this when running 40+ plugins as the same time (mixing in VST for example I'll use that many plugins easily). With that many the conversions would add up to something but like you say it could be neglible. I'll try to benchmark it and post some results. I had a thought last night about this - if I am worried about the load from converting parameters I can always do something like: if(current_control_value1 != last_control_value1) { recalculate internal_value1 } in the run loop BTW this all came about from one of the plugins I'm working one - 10 parameters from which 50 internals are calculated - lots of sin,cos,tan,pow & sqrt's going on. By keeping track of the previous values at least I can recalculate when I detect a change rather than every run() call. >> 3) changes to parameters can be presented to the run() function >> immediately > > I don't see how it makes any difference in this area? in the example code this line: const float gain = *(plugin_data->gain); is outside the for loop in the run() function so changes to the gain are not picked up till the next run() call. whereas in my example I had my (magically converted) parameter inside the for loop - so any changes are picked up immediately: for (pos = 0; pos < sample_count; pos++) { output[pos] = input[pos] * plugin_data->MyTranslatedGain; } When you consider plugin parameters can be automated and music is all about timing, having an unpredictable delay between when a parameter is changed and when the new value is applied could be an issue (ie you can't make the sound being produced by a plugin change 'on the beat'). With my setup, blocks of audio are 2048 fames in size, so my run() function will pick up changes every 46ms - which is an audible delay (yes I agree this is a small deal and if really matters to the plugin there are ways around it) regards, Fraser From nedko at arnaudov.name Mon Jan 29 02:30:09 2007 From: nedko at arnaudov.name (Nedko Arnaudov) Date: Mon Jan 29 02:24:22 2007 Subject: [linux-audio-dev] LADSPA needs & wishes In-Reply-To: <44150.150.101.126.38.1169960874.squirrel@mail.arkhostings.com> (fraser@arkhostings.com's message of "Sun, 28 Jan 2007 16:07:54 +1100 (EST)") References: <1169903220.18649.50.camel@localhost.localdomain> <44150.150.101.126.38.1169960874.squirrel@mail.arkhostings.com> Message-ID: <87bqkicmta.fsf@arnaudov.name> "Fraser" writes: > The plugin doesn't know when a parameter has changed, so it must calculate > it's internal values from the displayed parameter 'as often as possible' - > once per run() call (doing it in the for loop itself is just too extreme). dynparam LV2 extension handles parameter changes using callbacks. It is not finished yet (but it is working at some degree). http://home.gna.org/lv2dynparam/ Recalculating params on each run would be pain for zynadd, because it has *many* parameters. -- Nedko Arnaudov -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20070129/db681f6f/attachment.bin From nedko at arnaudov.name Mon Jan 29 02:39:29 2007 From: nedko at arnaudov.name (Nedko Arnaudov) Date: Mon Jan 29 02:33:40 2007 Subject: [linux-audio-dev] LADSPA needs & wishes In-Reply-To: <200701272153.16994.cannam@all-day-breakfast.com> (Chris Cannam's message of "Sat, 27 Jan 2007 21:53:16 +0000") References: <38603.150.101.126.38.1169874358.squirrel@mail.arkhostings.com> <200701271236.09850.rj@spamatica.se> <87sldwz4a1.fsf@arnaudov.name> <200701272153.16994.cannam@all-day-breakfast.com> Message-ID: <8764aqcmdq.fsf@arnaudov.name> Chris Cannam writes: > What are they? Do they do anything else, besides host LV2 plugins? I'm aware of these LV2 hosts: * jack_host from libslv2 project, by Dave Robillard * elven from ll-plugins project, by Lars Luthman * zynjacku, by me * maybe ingen (om), by Dave Robillard, LV2 support is ready too What else you want them to do? (zynjacku feature list is still open) P.S. Antisocial humans don't read mailing lists. -- Nedko Arnaudov -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20070129/86a5173e/attachment.bin From steve at plugin.org.uk Mon Jan 29 03:08:37 2007 From: steve at plugin.org.uk (Steve Harris) Date: Mon Jan 29 03:08:50 2007 Subject: [linux-audio-dev] LADSPA needs & wishes In-Reply-To: <40555.150.101.126.38.1170037091.squirrel@mail.arkhostings.com> References: <07CA2065-FC53-4BBE-B211-C4D83755AE0C@plugin.org.uk> <40555.150.101.126.38.1170037091.squirrel@mail.arkhostings.com> Message-ID: <7B134EC7-22FB-41F0-89F4-80D568ED0584@plugin.org.uk> On 29 Jan 2007, at 02:18, Fraser wrote: > Hi Steve, Hi Fraser, >> Sure. This was an issue in LADSPA, though not a significant enough >> one that anyone wanted it changed. I would suspect you're >> overestimating the burden compared to the function call overhead and >> cache thrashing. I'd be interested to see figures indicating >> otherwise though. There will obviously be cases where it's faster to >> set values using callbacks, but I'll bet it's not universal. > > I had a thought last night about this - if I am worried about the load > from converting parameters I can always do something like: > > if(current_control_value1 != last_control_value1) > { > recalculate internal_value1 > } > > in the run loop Yes, exactly. It's slightly more expensive as you have a conditional, but you save the function call overhead, which is something like 1000-1500 cycles IIRC. >>> 3) changes to parameters can be presented to the run() function >>> immediately >> >> I don't see how it makes any difference in this area? > > in the example code this line: > > const float gain = *(plugin_data->gain); > > is outside the for loop in the run() function > so changes to the gain are not picked up till the next run() call. Ah, well the host is not supposed to change port values during run() anyway, the idea in LADSPA (and LV2) is that the host should chop the run() block where port values change. In practice not all hosts do that, some just pick a suitably small block size, eg. 32 frames and quantise the changes to that rate. - Steve From cannam at all-day-breakfast.com Mon Jan 29 08:49:45 2007 From: cannam at all-day-breakfast.com (Chris Cannam) Date: Mon Jan 29 09:06:28 2007 Subject: [linux-audio-dev] LADSPA needs & wishes In-Reply-To: <8764aqcmdq.fsf@arnaudov.name> References: <38603.150.101.126.38.1169874358.squirrel@mail.arkhostings.com> <200701272153.16994.cannam@all-day-breakfast.com> <8764aqcmdq.fsf@arnaudov.name> Message-ID: <200701291349.45401.cannam@all-day-breakfast.com> On Monday 29 Jan 2007 07:39, Nedko Arnaudov wrote: > Chris Cannam writes: > > What are they? Do they do anything else, besides host LV2 plugins? > > I'm aware of these LV2 hosts: > * jack_host from libslv2 project, by Dave Robillard > * elven from ll-plugins project, by Lars Luthman > * zynjacku, by me > * maybe ingen (om), by Dave Robillard, LV2 support is ready too Thanks. Is there any more information about Elven (besides the code)? Is Zynjacku specific to Zyn in any way, or is it just named that way because you wanted an LV2 host when you happened to be working on Zyn-based plugins? > What else you want them to do? (zynjacku feature list is still open) Oh, I don't mind. I was just wondering. I suppose I was also wondering if any previously-existing applications besides Om/Ingen had started adding LV2 support yet. It's evident from my and Robert's posts in this thread that Rosegarden and MusE haven't, but there are plenty of others that might have. What about Dino? > P.S. Antisocial humans don't read mailing lists. Yeah, they do. Me for example. Sorry for being so grumpy. Chris From lars.luthman at gmail.com Mon Jan 29 09:41:30 2007 From: lars.luthman at gmail.com (Lars Luthman) Date: Mon Jan 29 09:42:31 2007 Subject: [linux-audio-dev] LADSPA needs & wishes In-Reply-To: <200701291349.45401.cannam@all-day-breakfast.com> References: <38603.150.101.126.38.1169874358.squirrel@mail.arkhostings.com> <200701272153.16994.cannam@all-day-breakfast.com> <8764aqcmdq.fsf@arnaudov.name> <200701291349.45401.cannam@all-day-breakfast.com> Message-ID: <1170081691.3639.6.camel@box.lars> On Mon, 2007-01-29 at 13:49 +0000, Chris Cannam wrote: > On Monday 29 Jan 2007 07:39, Nedko Arnaudov wrote: > > Chris Cannam writes: > > > What are they? Do they do anything else, besides host LV2 plugins? > > > > I'm aware of these LV2 hosts: > > * jack_host from libslv2 project, by Dave Robillard > > * elven from ll-plugins project, by Lars Luthman > > * zynjacku, by me > > * maybe ingen (om), by Dave Robillard, LV2 support is ready too > > Thanks. Is there any more information about Elven (besides the code)? Elven is not really meant to be used. It's an experimental host and a perpetual work-in-progress that I'm writing to test new extensions and to see how hard it is to write a basic LV2 host from scratch, including Turtle parsing and RDF subgraph querying (conclusion: not very hard). > What about Dino? Dino doesn't do audio. It could maybe use LV2 for filtering and generating MIDI, but I can't think of any real uses for that that wouldn't be easier to do as a part of the actual program instead of a plugin. --ll -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20070129/c60744da/attachment.bin From steve at plugin.org.uk Mon Jan 29 10:15:15 2007 From: steve at plugin.org.uk (Steve Harris) Date: Mon Jan 29 10:15:36 2007 Subject: [linux-audio-dev] LADSPA needs & wishes In-Reply-To: <1170081691.3639.6.camel@box.lars> References: <38603.150.101.126.38.1169874358.squirrel@mail.arkhostings.com> <200701272153.16994.cannam@all-day-breakfast.com> <8764aqcmdq.fsf@arnaudov.name> <200701291349.45401.cannam@all-day-breakfast.com> <1170081691.3639.6.camel@box.lars> Message-ID: <53886BE7-B940-493A-BC0D-8392630045B5@plugin.org.uk> On 29 Jan 2007, at 14:41, Lars Luthman wrote: > On Mon, 2007-01-29 at 13:49 +0000, Chris Cannam wrote: >> On Monday 29 Jan 2007 07:39, Nedko Arnaudov wrote: >>> Chris Cannam writes: >>>> What are they? Do they do anything else, besides host LV2 plugins? >>> >>> I'm aware of these LV2 hosts: >>> * jack_host from libslv2 project, by Dave Robillard >>> * elven from ll-plugins project, by Lars Luthman >>> * zynjacku, by me >>> * maybe ingen (om), by Dave Robillard, LV2 support is ready too >> >> Thanks. Is there any more information about Elven (besides the >> code)? > > Elven is not really meant to be used. It's an experimental host and a > perpetual work-in-progress that I'm writing to test new extensions and > to see how hard it is to write a basic LV2 host from scratch, > including > Turtle parsing and RDF subgraph querying (conclusion: not very hard). I would hope that there aren't many more than this, as it's still a draft spec, and it's not all nailed down. I'd hate for too many people to implement a draft before it's finalised. - Steve From pw_lists at slinkp.com Mon Jan 29 10:23:40 2007 From: pw_lists at slinkp.com (Paul Winkler) Date: Mon Jan 29 10:23:56 2007 Subject: [linux-audio-dev] LADSPA needs & wishes In-Reply-To: <7B134EC7-22FB-41F0-89F4-80D568ED0584@plugin.org.uk> References: <07CA2065-FC53-4BBE-B211-C4D83755AE0C@plugin.org.uk> <40555.150.101.126.38.1170037091.squirrel@mail.arkhostings.com> <7B134EC7-22FB-41F0-89F4-80D568ED0584@plugin.org.uk> Message-ID: <20070129152340.GA7368@slinkp.com> On Mon, Jan 29, 2007 at 08:08:37AM +0000, Steve Harris wrote: > Ah, well the host is not supposed to change port values during run() > anyway, the idea in LADSPA (and LV2) is that the host should chop the > run() block where port values change. /delurk What does "chop the run block" mean? /relurk -- Paul Winkler http://www.slinkp.com From steve at plugin.org.uk Mon Jan 29 10:30:06 2007 From: steve at plugin.org.uk (Steve Harris) Date: Mon Jan 29 10:30:32 2007 Subject: [linux-audio-dev] LADSPA needs & wishes In-Reply-To: <20070129152340.GA7368@slinkp.com> References: <07CA2065-FC53-4BBE-B211-C4D83755AE0C@plugin.org.uk> <40555.150.101.126.38.1170037091.squirrel@mail.arkhostings.com> <7B134EC7-22FB-41F0-89F4-80D568ED0584@plugin.org.uk> <20070129152340.GA7368@slinkp.com> Message-ID: On 29 Jan 2007, at 15:23, Paul Winkler wrote: > On Mon, Jan 29, 2007 at 08:08:37AM +0000, Steve Harris wrote: >> Ah, well the host is not supposed to change port values during run() >> anyway, the idea in LADSPA (and LV2) is that the host should chop the >> run() block where port values change. > > /delurk > > What does "chop the run block" mean? > > /relurk Imagine you have a block of 1024 samples, and at sample 24 a control value changes from 1 to 2, you could do: plugin->port = 2.0; plugin->run(1024); which puts the control value change in slightly the wrong place, or you could do: (chopping) plugin->port = 1.0; plugin->run(24); plugin->port = 2.0; plugin->run(1000); It's not a technical term or anything, I just needed a word :) - Steve From lars.luthman at gmail.com Mon Jan 29 10:33:11 2007 From: lars.luthman at gmail.com (Lars Luthman) Date: Mon Jan 29 10:34:05 2007 Subject: [linux-audio-dev] LADSPA needs & wishes In-Reply-To: <20070129152340.GA7368@slinkp.com> References: <07CA2065-FC53-4BBE-B211-C4D83755AE0C@plugin.org.uk> <40555.150.101.126.38.1170037091.squirrel@mail.arkhostings.com> <7B134EC7-22FB-41F0-89F4-80D568ED0584@plugin.org.uk> <20070129152340.GA7368@slinkp.com> Message-ID: <1170084791.3639.11.camel@box.lars> On Mon, 2007-01-29 at 10:23 -0500, Paul Winkler wrote: > On Mon, Jan 29, 2007 at 08:08:37AM +0000, Steve Harris wrote: > > Ah, well the host is not supposed to change port values during run() > > anyway, the idea in LADSPA (and LV2) is that the host should chop the > > run() block where port values change. > > What does "chop the run block" mean? If the host is normally running with period size 1024 (mandated by JACK for example) but at some point wants to change one of the plugin's control parameters 326 frames into a period, it will have to chop the period into two pieces, [0-325] and [326-1023]. It will then call run(326) in the plugin to generate/process the first 326 frames, then change the control parameter value, then call run(698) to generate/process the rest of the frames. --ll -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20070129/bf1e689e/attachment.bin From mista.tapas at gmx.net Mon Jan 29 11:51:32 2007 From: mista.tapas at gmx.net (Florian Schmidt) Date: Mon Jan 29 12:10:35 2007 Subject: [linux-audio-dev] LV2 buffersize extensions (was: LADSPA...) In-Reply-To: <7B134EC7-22FB-41F0-89F4-80D568ED0584@plugin.org.uk> References: <07CA2065-FC53-4BBE-B211-C4D83755AE0C@plugin.org.uk> <40555.150.101.126.38.1170037091.squirrel@mail.arkhostings.com> <7B134EC7-22FB-41F0-89F4-80D568ED0584@plugin.org.uk> Message-ID: <200701291751.32227.mista.tapas@gmx.net> On Monday 29 January 2007 09:08, Steve Harris wrote: > Ah, well the host is not supposed to change port values during run() > anyway, the idea in LADSPA (and LV2) is that the host should chop the > run() block where port values change. In practice not all hosts do > that, some just pick a suitably small block size, eg. 32 frames and > quantise the changes to that rate. Hi, let me chime in because it kidna fits into the subject. I have defined two (very very simple LV2 extensions): "The extension?s URI is http://tapas.affenbande.org/lv2/ext/fixed-buffersize All that a plugin needs to check is whether a host feature with this URI exists and the data will be a uint32 containing the buffersize. The host is only allowed to call the plugin?s run function with a buffersize equal to the one specified by the host feature. There?s a second extension: http://tapas.affenbande.org/lv2/ext/power-of-two-buffersize which is identical to above but with the additional requirement that the fixed buffersize has to be a power of two." I don't need to have the URI point to my site. If you want to integrate it into the official LV2 standard i'd be more than happy.. For anyone who might ask: "why do we need this"? Well the answer is that some algorithms (especially fft based) perform much better when the buffer size is known (because they must operate with a fixed buffersize internally). With anyone of these two extensions provided by the host, those plugins can avoid additional delay from buffering, etc.. We discussed on #lad whether a guarantee that the framecount of subsequent run () calls add up to a fixed buffersize is enough.. I wasn't sure about this. But i think now, that it's not a good idea. Here's a good counterargument: Imagine an fft based plugin that uses the host buffer size as internal fft size. Then with this guarantee it would have to collect data until an fft buffer is full. While waiting for this and processing subsequent these smaller buffers, it will have to produce output, but it doesn't have the fft result yet. Thus causing unavoidable delay (of one total buffersize).. Flo -- Palimm Palimm! http://tapas.affenbande.org From steve at plugin.org.uk Mon Jan 29 12:22:38 2007 From: steve at plugin.org.uk (Steve Harris) Date: Mon Jan 29 12:36:02 2007 Subject: [linux-audio-dev] LV2 buffersize extensions (was: LADSPA...) In-Reply-To: <200701291751.32227.mista.tapas@gmx.net> References: <07CA2065-FC53-4BBE-B211-C4D83755AE0C@plugin.org.uk> <40555.150.101.126.38.1170037091.squirrel@mail.arkhostings.com> <7B134EC7-22FB-41F0-89F4-80D568ED0584@plugin.org.uk> <200701291751.32227.mista.tapas@gmx.net> Message-ID: On 29 Jan 2007, at 16:51, Florian Schmidt wrote: > On Monday 29 January 2007 09:08, Steve Harris wrote: > >> Ah, well the host is not supposed to change port values during run() >> anyway, the idea in LADSPA (and LV2) is that the host should chop the >> run() block where port values change. In practice not all hosts do >> that, some just pick a suitably small block size, eg. 32 frames and >> quantise the changes to that rate. > > Hi, let me chime in because it kidna fits into the subject. > > I have defined two (very very simple LV2 extensions): > > "The extension?s URI is > http://tapas.affenbande.org/lv2/ext/fixed-buffersize > > All that a plugin needs to check is whether a host feature with > this URI > exists and the data will be a uint32 containing the buffersize. > > The host is only allowed to call the plugin?s run function with a > buffersize > equal to the one specified by the host feature. > There?s a second extension: > > http://tapas.affenbande.org/lv2/ext/power-of-two-buffersize > > which is identical to above but with the additional requirement > that the fixed > buffersize has to be a power of two." Great idea. I've got some plugins that will benefit a lot by this. We should link to known extensions on the http://lv2plug.in/ site. FWIW, my provisional plan was to wait until it seemed like time for a LV2 1.1 (hopefully not too soon :), then roll all the "popular" extensions into that. It doesn't make a huge amount of difference whether their included or not though. Before you ask, no I don't have a definition for "popular". - Steve From mista.tapas at gmx.net Mon Jan 29 12:57:00 2007 From: mista.tapas at gmx.net (Florian Schmidt) Date: Mon Jan 29 12:57:15 2007 Subject: [linux-audio-dev] LV2 buffersize extensions (was: LADSPA...) In-Reply-To: References: <07CA2065-FC53-4BBE-B211-C4D83755AE0C@plugin.org.uk> <200701291751.32227.mista.tapas@gmx.net> Message-ID: <200701291857.00707.mista.tapas@gmx.net> On Monday 29 January 2007 18:22, Steve Harris wrote: > > http://tapas.affenbande.org/lv2/ext/fixed-buffersize > > http://tapas.affenbande.org/lv2/ext/power-of-two-buffersize > Great idea. I've got some plugins that will benefit a lot by this. We > should link to known extensions on the http://lv2plug.in/ site. > > FWIW, my provisional plan was to wait until it seemed like time for a > LV2 1.1 (hopefully not too soon :), then roll all the "popular" > extensions into that. Ah, i don't mean this extension has to become part of the core LV2 spec. Nonono. I was just wondering whether it makes sense that i maintain this seperately and keep the extension URI to my site. Is there a plan to host some very common extensions on the lv2 site (URI having lv2plug.in in it and docs on the lv2 site), too? If so i would like to see these extensions included. > It doesn't make a huge amount of difference whether their included or > not though. Well, just a visibility thing. By having some extensions documented and "hosted" on lv2plug.in they probably get more visibility than others. For certain "almost core" functionality this would make sense i think. > > Before you ask, no I don't have a definition for "popular". Hehe :) Flo -- Palimm Palimm! http://tapas.affenbande.org From steve at plugin.org.uk Mon Jan 29 13:20:28 2007 From: steve at plugin.org.uk (Steve Harris) Date: Mon Jan 29 13:21:17 2007 Subject: [linux-audio-dev] LV2 buffersize extensions (was: LADSPA...) In-Reply-To: <200701291857.00707.mista.tapas@gmx.net> References: <07CA2065-FC53-4BBE-B211-C4D83755AE0C@plugin.org.uk> <200701291751.32227.mista.tapas@gmx.net> <200701291857.00707.mista.tapas@gmx.net> Message-ID: <1C71F2F5-C7E0-449C-8A42-67649116791E@plugin.org.uk> On 29 Jan 2007, at 17:57, Florian Schmidt wrote: > On Monday 29 January 2007 18:22, Steve Harris wrote: > >>> http://tapas.affenbande.org/lv2/ext/fixed-buffersize > >>> http://tapas.affenbande.org/lv2/ext/power-of-two-buffersize > >> Great idea. I've got some plugins that will benefit a lot by this. We >> should link to known extensions on the http://lv2plug.in/ site. >> >> FWIW, my provisional plan was to wait until it seemed like time for a >> LV2 1.1 (hopefully not too soon :), then roll all the "popular" >> extensions into that. > > Ah, i don't mean this extension has to become part of the core LV2 > spec. > Nonono. I was just wondering whether it makes sense that i maintain > this > seperately and keep the extension URI to my site. > > Is there a plan to host some very common extensions on the lv2 site > (URI > having lv2plug.in in it and docs on the lv2 site), too? If so i > would like to > see these extensions included. Ah, I see. In principle that's fine, but in practice I suspect it's easier for you to edit the content on your own site. OTOH if people are happy to maintain the content via WebDAV then I'm happy to host extensions at http://lv2plugin.in/extension/foo or similar. There should definitely be links to the extensions from the spec site either way. >> It doesn't make a huge amount of difference whether their included or >> not though. > > Well, just a visibility thing. By having some extensions documented > and "hosted" on lv2plug.in they probably get more visibility than > others. For > certain "almost core" functionality this would make sense i think. Well, for any really. URIs are free and we're not going to run out ;) - Steve From nedko at arnaudov.name Mon Jan 29 12:57:24 2007 From: nedko at arnaudov.name (Nedko Arnaudov) Date: Mon Jan 29 14:59:34 2007 Subject: [linux-audio-dev] LADSPA needs & wishes In-Reply-To: <200701291349.45401.cannam@all-day-breakfast.com> (Chris Cannam's message of "Mon, 29 Jan 2007 13:49:45 +0000") References: <38603.150.101.126.38.1169874358.squirrel@mail.arkhostings.com> <200701272153.16994.cannam@all-day-breakfast.com> <8764aqcmdq.fsf@arnaudov.name> <200701291349.45401.cannam@all-day-breakfast.com> Message-ID: <87k5z567i3.fsf@arnaudov.name> Chris Cannam writes: > Is Zynjacku specific to Zyn in any way, or is it just named that way because > you wanted an LV2 host when you happened to be working on Zyn-based plugins? It is not specific. I loaded and produced sound with some of LV2 plugins From ll-plugins and with one LV2 sampler plugin. ATM zynjacku cannot show UIs for plugins that don't support the lv2dynparam extension and currently the only synth that supports lv2dynparam extension is zynadd. It will be able to generate generic UI for any plugin (based on its RDF file) and to show custom UIs once approach for them is stable enough. AFAIK only Lars Luthman is working on custom UI approach and once he publishes the extension I'll add support for it. -- Nedko Arnaudov -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20070129/19c85be8/attachment.bin From drobilla at connect.carleton.ca Mon Jan 29 18:25:33 2007 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Mon Jan 29 18:25:41 2007 Subject: [linux-audio-dev] LV2 buffersize extensions (was: LADSPA...) In-Reply-To: References: <07CA2065-FC53-4BBE-B211-C4D83755AE0C@plugin.org.uk> <40555.150.101.126.38.1170037091.squirrel@mail.arkhostings.com> <7B134EC7-22FB-41F0-89F4-80D568ED0584@plugin.org.uk> <200701291751.32227.mista.tapas@gmx.net> Message-ID: <1170113133.5099.3.camel@localhost.localdomain> On Mon, 2007-01-29 at 17:22 +0000, Steve Harris wrote: > On 29 Jan 2007, at 16:51, Florian Schmidt wrote: > > > On Monday 29 January 2007 09:08, Steve Harris wrote: > > > >> Ah, well the host is not supposed to change port values during run() > >> anyway, the idea in LADSPA (and LV2) is that the host should chop the > >> run() block where port values change. In practice not all hosts do > >> that, some just pick a suitably small block size, eg. 32 frames and > >> quantise the changes to that rate. > > > > Hi, let me chime in because it kidna fits into the subject. > > > > I have defined two (very very simple LV2 extensions): > > > > "The extension?s URI is > > http://tapas.affenbande.org/lv2/ext/fixed-buffersize > > > > All that a plugin needs to check is whether a host feature with > > this URI > > exists and the data will be a uint32 containing the buffersize. > > > > The host is only allowed to call the plugin?s run function with a > > buffersize > > equal to the one specified by the host feature. > > There?s a second extension: > > > > http://tapas.affenbande.org/lv2/ext/power-of-two-buffersize > > > > which is identical to above but with the additional requirement > > that the fixed > > buffersize has to be a power of two." > > Great idea. I've got some plugins that will benefit a lot by this. We > should link to known extensions on the http://lv2plug.in/ site. > > FWIW, my provisional plan was to wait until it seemed like time for a > LV2 1.1 (hopefully not too soon :), then roll all the "popular" > extensions into that. > It doesn't make a huge amount of difference whether their included or > not though. > > Before you ask, no I don't have a definition for "popular". I think it might be a better idea to reserve some URI prefix (http://lv2plug/extensions ?) for "popular" extensions and keep the spec itself simple, just for the sake of having a simple understandable core spec regardless of how the more fancy things evolve. Thoughts? -DR- From fraser at arkhostings.com Mon Jan 29 20:25:20 2007 From: fraser at arkhostings.com (Fraser) Date: Mon Jan 29 20:25:35 2007 Subject: [linux-audio-dev] LADSPA needs & wishes In-Reply-To: <7B134EC7-22FB-41F0-89F4-80D568ED0584@plugin.org.uk> References: <7B134EC7-22FB-41F0-89F4-80D568ED0584@plugin.org.uk> Message-ID: <17732.203.11.81.236.1170120320.squirrel@mail.arkhostings.com> Hi Steve, > Ah, well the host is not supposed to change port values during run() > anyway, the idea in LADSPA (and LV2) is that the host should chop the > run() block where port values change. In practice not all hosts do > that, some just pick a suitably small block size, eg. 32 frames and > quantise the changes to that rate. I didn't realise that - perhaps I glossed over that bit of the spec. A block size of 32 frames would really exagerate unnecessary paramter conversion... regards, Fraser From bharat.gusain at st.com Tue Jan 30 01:19:29 2007 From: bharat.gusain at st.com (Bharat Singh GUSAIN) Date: Tue Jan 30 01:19:56 2007 Subject: [linux-audio-dev] Usb audio problem Message-ID: <000901c74436$9e604320$04000100@dlh.st.com> Hi all, I am trying to record audio from my STM webcam the driver for it's sound card's driver is loaded automatically as snd-usb-audio. But When I try to record through sound recorder, it did't record anything. On seeing at the catc traces I came to know that the sound recorder even don't set the streaming alternates. Any suggestions? Best Regards ---- Bharat Singh Gusain ST Microelectronics HPC/PMG-Imaging RD&I Plot no-1, Knowledge Park III Greater Noida - 201308, India Mobile - 9911121667 PSTN: 0120-4003414 PH: 0120-2352999 EXTN: 2772 www.st.com From steve at plugin.org.uk Tue Jan 30 03:53:07 2007 From: steve at plugin.org.uk (Steve Harris) Date: Tue Jan 30 03:53:19 2007 Subject: [linux-audio-dev] LADSPA needs & wishes In-Reply-To: <17732.203.11.81.236.1170120320.squirrel@mail.arkhostings.com> References: <7B134EC7-22FB-41F0-89F4-80D568ED0584@plugin.org.uk> <17732.203.11.81.236.1170120320.squirrel@mail.arkhostings.com> Message-ID: On 30 Jan 2007, at 01:25, Fraser wrote: > Hi Steve, > > >> Ah, well the host is not supposed to change port values during run() >> anyway, the idea in LADSPA (and LV2) is that the host should chop the >> run() block where port values change. In practice not all hosts do >> that, some just pick a suitably small block size, eg. 32 frames and >> quantise the changes to that rate. > > I didn't realise that - perhaps I glossed over that bit of the spec. > A block size of 32 frames would really exagerate unnecessary paramter > conversion... Sure, which is why people do tend to do the if (oldval != newval) thing on expensive parameter calculations. 32 is really the extreme end, I would think that typically its higher than that. JACK systems do run down to the 32 frame buffer level, so you have to be able to handle it anyway. It's quite inefficient as the cost of calling the run() function of every plugin for every block is significant. - Steve From most at museresearch.com Tue Jan 30 12:03:43 2007 From: most at museresearch.com (Michael Ost) Date: Tue Jan 30 12:04:54 2007 Subject: [linux-audio-dev] Old hat - comparison against windows Message-ID: <45BF7A6F.9080205@museresearch.com> Can anyone suggest ways to compare audio/midi performance between Linux and Windows that (1) are relevant to non-technical musicians and (2) make Linux compare favorably? Not things like "I just don't like Windows" or software feature comparisons or the politics of open vs. closed source, but rather things like responsiveness to audio interrupts, RAM footprint of the OS and ...? I work for a company that sells a Linux based piece of hardware that plays windows VSTs. We spend alot of time on compatibility, especially on getting the plugins to work with Wine. I often get asked about switching to Windows and I don't have a good answer. My sense is that the main benefit of Linux is that audio interrupts are serviced faster and more predictably than in Windows because of SCHED_FIFO and Linux's low overhead. And clearly musicians could feel that, especially at lower buffer size settings so that's the kind of thing that could matter. But is it _really_ true? Is there a standard way to measure it? Or published results about it? Are there any other things to compare? Thanks for any input. I _want_ to believe! %) ... mo PS: apologies for any confusion that comes from posting to both linux-dev and linux-user. I wasn't sure which list this is more appropriate to...? From letz at grame.fr Tue Jan 30 12:12:13 2007 From: letz at grame.fr (=?ISO-8859-1?Q?St=E9phane_Letz?=) Date: Tue Jan 30 12:15:35 2007 Subject: [linux-audio-dev] Old hat - comparison against windows In-Reply-To: <45BF7A6F.9080205@museresearch.com> References: <45BF7A6F.9080205@museresearch.com> Message-ID: <70E6E18B-34AE-4E79-80A9-76863E3209F8@grame.fr> Le 30 janv. 07 ? 18:03, Michael Ost a ?crit : > Can anyone suggest ways to compare audio/midi performance between > Linux > and Windows that (1) are relevant to non-technical musicians and (2) > make Linux compare favorably? > > Not things like "I just don't like Windows" or software feature > comparisons or the politics of open vs. closed source, but rather > things > like responsiveness to audio interrupts, RAM footprint of the OS > and ...? > > I work for a company that sells a Linux based piece of hardware that > plays windows VSTs. We spend alot of time on compatibility, > especially > on getting the plugins to work with Wine. I often get asked about > switching to Windows and I don't have a good answer. > > My sense is that the main benefit of Linux is that audio interrupts > are > serviced faster and more predictably than in Windows because of > SCHED_FIFO and Linux's low overhead. And clearly musicians could feel > that, especially at lower buffer size settings so that's the kind of > thing that could matter. > > But is it _really_ true? Is there a standard way to measure it? Or > published results about it? > > Are there any other things to compare? Thanks for any input. I > _want_ to > believe! %) ... mo > > PS: apologies for any confusion that comes from posting to both > linux-dev and linux-user. I wasn't sure which list this is more > appropriate to...? > You'll probably first have to decide which Windows version you're comparing since Vista is supposed to be better than XP: See: http://createdigitalmusic.com/2007/01/19/vista-for-music-pro- audio-exclusive-under-the-hood-with-cakewalks-cto/ Regards Stephane Letz From most at museresearch.com Tue Jan 30 12:25:04 2007 From: most at museresearch.com (Michael Ost) Date: Tue Jan 30 12:27:34 2007 Subject: [linux-audio-dev] Old hat - comparison against windows In-Reply-To: <70E6E18B-34AE-4E79-80A9-76863E3209F8@grame.fr> References: <45BF7A6F.9080205@museresearch.com> <70E6E18B-34AE-4E79-80A9-76863E3209F8@grame.fr> Message-ID: <45BF7F70.6040008@museresearch.com> St?phane Letz wrote: > You'll probably first have to decide which Windows version you're > comparing since Vista is supposed to be better than XP: > > See: > http://createdigitalmusic.com/2007/01/19/vista-for-music-pro-audio-exclusive-under-the-hood-with-cakewalks-cto/ Thanks for the link. There sure were alot of "ifs" and qualifications in that article. But I could see an advantage once you can get a proper WaveRT driver for your hardware. - mo From lars.luthman at gmail.com Tue Jan 30 12:42:09 2007 From: lars.luthman at gmail.com (Lars Luthman) Date: Tue Jan 30 12:43:29 2007 Subject: [linux-audio-dev] Old hat - comparison against windows In-Reply-To: <45BF7A6F.9080205@museresearch.com> References: <45BF7A6F.9080205@museresearch.com> Message-ID: <1170178929.3639.16.camel@box.lars> On Tue, 2007-01-30 at 09:03 -0800, Michael Ost wrote: > Can anyone suggest ways to compare audio/midi performance between Linux > and Windows that (1) are relevant to non-technical musicians and (2) > make Linux compare favorably? > > Not things like "I just don't like Windows" or software feature > comparisons or the politics of open vs. closed source, but rather things > like responsiveness to audio interrupts, RAM footprint of the OS and ...? Any comparison would depend on what Linux you're using. Vanilla code from kernel.org, binary packages from some distribution, RT-patch or not? There are hundreds (thousands?) of kernel configuration parameters that affect the speed and code size. --ll -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20070130/e68c6b3b/attachment.bin From steve at plugin.org.uk Tue Jan 30 13:16:02 2007 From: steve at plugin.org.uk (Steve Harris) Date: Tue Jan 30 13:18:03 2007 Subject: [linux-audio-dev] Old hat - comparison against windows In-Reply-To: <45BF7A6F.9080205@museresearch.com> References: <45BF7A6F.9080205@museresearch.com> Message-ID: <51AEE533-2661-4243-9E71-08B56EAE58E2@plugin.org.uk> On 30 Jan 2007, at 17:03, Michael Ost wrote: > Can anyone suggest ways to compare audio/midi performance between > Linux > and Windows that (1) are relevant to non-technical musicians and (2) > make Linux compare favorably? > > Not things like "I just don't like Windows" or software feature > comparisons or the politics of open vs. closed source, but rather > things > like responsiveness to audio interrupts, RAM footprint of the OS > and ...? > > I work for a company that sells a Linux based piece of hardware that > plays windows VSTs. We spend alot of time on compatibility, > especially > on getting the plugins to work with Wine. I often get asked about > switching to Windows and I don't have a good answer. > > My sense is that the main benefit of Linux is that audio interrupts > are > serviced faster and more predictably than in Windows because of > SCHED_FIFO and Linux's low overhead. And clearly musicians could feel > that, especially at lower buffer size settings so that's the kind of > thing that could matter. I would have thought that the best way to measure scheduler performance is to write a simple VST plugin that writes the precise time at which it was called into a ram buffer, and writes the buffer out to disk after a few tens of thousands of calls. You can the measure the times between adjacent runs and work out if there's any significant difference in jitter. I would think that the RAM footprint is essentially impossible to measure, as you can't tell what proportion of the kernel space is buffers etc. From a commercial point of view, your are at the very least saving licence fees for each piece of hardware, that would surely eat into your profit margin. - Steve From rah at bash.sh Tue Jan 30 16:05:50 2007 From: rah at bash.sh (Bob Ham) Date: Tue Jan 30 16:13:59 2007 Subject: [linux-audio-dev] Old hat - comparison against windows In-Reply-To: <45BF7A6F.9080205@museresearch.com> References: <45BF7A6F.9080205@museresearch.com> Message-ID: <1170191150.2232.427.camel@orchid.arb.net> On Tue, 2007-01-30 at 09:03 -0800, Michael Ost wrote: > Can anyone suggest ways to compare audio/midi performance between Linux > and Windows that ... make Linux compare favorably? > I work for a company that sells a Linux based piece of hardware that > plays windows VSTs. The word "FUD" comes to mind. No idea why. Bob -- Bob Ham -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20070130/6b7cc148/attachment.bin From rah at bash.sh Tue Jan 30 16:18:06 2007 From: rah at bash.sh (Bob Ham) Date: Tue Jan 30 16:24:47 2007 Subject: [linux-audio-dev] Old hat - comparison against windows In-Reply-To: <1170191150.2232.427.camel@orchid.arb.net> References: <45BF7A6F.9080205@museresearch.com> <1170191150.2232.427.camel@orchid.arb.net> Message-ID: <1170191886.2232.431.camel@orchid.arb.net> On Tue, 2007-01-30 at 21:05 +0000, Bob Ham wrote: > On Tue, 2007-01-30 at 09:03 -0800, Michael Ost wrote: > > Can anyone suggest ways to compare audio/midi performance between Linux > > and Windows that ... make Linux compare favorably? > > > I work for a company that sells a Linux based piece of hardware that > > plays windows VSTs. > > The word "FUD" comes to mind. No idea why. Further to that, something constructive: perhaps you could try telling your customers why *you* chose linux, rather than trying to find reasons to tell them *they* should. Bob -- Bob Ham -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20070130/1482a2bd/attachment.bin From torbenh at gmx.de Tue Jan 30 17:30:56 2007 From: torbenh at gmx.de (torbenh@gmx.de) Date: Tue Jan 30 17:25:51 2007 Subject: [linux-audio-dev] Old hat - comparison against windows In-Reply-To: <1170191886.2232.431.camel@orchid.arb.net> References: <45BF7A6F.9080205@museresearch.com> <1170191150.2232.427.camel@orchid.arb.net> <1170191886.2232.431.camel@orchid.arb.net> Message-ID: <20070130223028.GB9733@mobilat> On Tue, Jan 30, 2007 at 09:18:06PM +0000, Bob Ham wrote: > On Tue, 2007-01-30 at 21:05 +0000, Bob Ham wrote: > > On Tue, 2007-01-30 at 09:03 -0800, Michael Ost wrote: > > > Can anyone suggest ways to compare audio/midi performance between Linux > > > and Windows that ... make Linux compare favorably? > > > > > I work for a company that sells a Linux based piece of hardware that > > > plays windows VSTs. > > > > The word "FUD" comes to mind. No idea why. > > Further to that, something constructive: perhaps you could try telling > your customers why *you* chose linux, rather than trying to find reasons > to tell them *they* should. the customers dont notice. they still use windows or no computers at all. it looks rather like a question from the management. > > Bob > > -- > Bob Ham -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From rj at spamatica.se Wed Jan 31 04:43:58 2007 From: rj at spamatica.se (Robert Jonsson) Date: Wed Jan 31 04:44:44 2007 Subject: [linux-audio-dev] Old hat - comparison against windows In-Reply-To: <20070130223028.GB9733@mobilat> References: <45BF7A6F.9080205@museresearch.com> <1170191150.2232.427.camel@orchid.arb.net> <1170191886.2232.431.camel@orchid.arb.net> <20070130223028.GB9733@mobilat> Message-ID: <45C064DE.90905@spamatica.se> Hi, torbenh@gmx.de skrev: > On Tue, Jan 30, 2007 at 09:18:06PM +0000, Bob Ham wrote: > >> On Tue, 2007-01-30 at 21:05 +0000, Bob Ham wrote: >> >>> On Tue, 2007-01-30 at 09:03 -0800, Michael Ost wrote: >>> >>>> Can anyone suggest ways to compare audio/midi performance between Linux >>>> and Windows that ... make Linux compare favorably? >>>> >>>> I work for a company that sells a Linux based piece of hardware that >>>> plays windows VSTs. >>>> >>> The word "FUD" comes to mind. No idea why. >>> >> Further to that, something constructive: perhaps you could try telling >> your customers why *you* chose linux, rather than trying to find reasons >> to tell them *they* should. >> > > the customers dont notice. they still use windows or no computers at > all. > > it looks rather like a question from the management. > Whatever the reasons, it's a valid and interesting question. In truth Linux is often touted (not the least with respect to audio) as a better performer than Windows. Though I can't say that I have personally experienced this. It is hard work getting a Linux system "tuned", I have actually never succeeded without some drawback that have forced me back to generic configurations. Not that I complain, my current (k)ubuntu kernel performs "good enough"tm, but I am certain it would be no problem getting equal performance under Windows. My choice of using Linux has more to do with the freedom of opensourceness (it's a word!..now atleast). Steve's idea with a vst timing plugin sounds very interesting. One using LADSPA would be equally interesting for comparing Linux to Linux. Are there other performance measurements that would be nice? xruns under load I suppose. Having a test suite for system performance would be great! I would not rule out that Linux is found to perform worse under some circumstances. But that is ok. Adaptability is one of the strong points of open source, once we know the problems we can start fixing them. Regards, Robert From rah at bash.sh Wed Jan 31 06:27:26 2007 From: rah at bash.sh (Bob Ham) Date: Wed Jan 31 06:36:59 2007 Subject: [linux-audio-dev] Old hat - comparison against windows In-Reply-To: <20070130223028.GB9733@mobilat> References: <45BF7A6F.9080205@museresearch.com> <1170191150.2232.427.camel@orchid.arb.net> <1170191886.2232.431.camel@orchid.arb.net> <20070130223028.GB9733@mobilat> Message-ID: <1170242846.2232.461.camel@orchid.arb.net> On Tue, 2007-01-30 at 23:30 +0100, torbenh@gmx.de wrote: > On Tue, Jan 30, 2007 at 09:18:06PM +0000, Bob Ham wrote: > > On Tue, 2007-01-30 at 21:05 +0000, Bob Ham wrote: > > > On Tue, 2007-01-30 at 09:03 -0800, Michael Ost wrote: > > > > Can anyone suggest ways to compare audio/midi performance between Linux > > > > and Windows that ... make Linux compare favorably? > > > > > > > I work for a company that sells a Linux based piece of hardware that > > > > plays windows VSTs. > > > > > > The word "FUD" comes to mind. No idea why. > > > > Further to that, something constructive: perhaps you could try telling > > your customers why *you* chose linux, rather than trying to find reasons > > to tell them *they* should. > > the customers dont notice. they still use windows or no computers at > all. > > it looks rather like a question from the management. You are correct there. From the modern business perspective, though, management are Michael's personal customers. I think the argument still applies. If your goal is to convince someone that your choice of linux is correct, telling them why you chose linux in the first place seems, to me at least, to be the best method, rather than seeking out reasons which you yourself haven't been concerned with previously. Bob -- Bob Ham -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20070131/ed6780b0/attachment.bin From steve at plugin.org.uk Wed Jan 31 06:41:08 2007 From: steve at plugin.org.uk (Steve Harris) Date: Wed Jan 31 06:41:16 2007 Subject: [linux-audio-dev] Old hat - comparison against windows In-Reply-To: <1170242846.2232.461.camel@orchid.arb.net> References: <45BF7A6F.9080205@museresearch.com> <1170191150.2232.427.camel@orchid.arb.net> <1170191886.2232.431.camel@orchid.arb.net> <20070130223028.GB9733@mobilat> <1170242846.2232.461.camel@orchid.arb.net> Message-ID: <2F8CE890-02EB-4BD1-B18C-A438E196C462@plugin.org.uk> On 31 Jan 2007, at 11:27, Bob Ham wrote: > On Tue, 2007-01-30 at 23:30 +0100, torbenh@gmx.de wrote: >> On Tue, Jan 30, 2007 at 09:18:06PM +0000, Bob Ham wrote: >>> On Tue, 2007-01-30 at 21:05 +0000, Bob Ham wrote: >>>> On Tue, 2007-01-30 at 09:03 -0800, Michael Ost wrote: >>>>> Can anyone suggest ways to compare audio/midi performance >>>>> between Linux >>>>> and Windows that ... make Linux compare favorably? >>>> >>>>> I work for a company that sells a Linux based piece of hardware >>>>> that >>>>> plays windows VSTs. >>>> >>>> The word "FUD" comes to mind. No idea why. >>> >>> Further to that, something constructive: perhaps you could try >>> telling >>> your customers why *you* chose linux, rather than trying to find >>> reasons >>> to tell them *they* should. >> >> the customers dont notice. they still use windows or no computers at >> all. >> >> it looks rather like a question from the management. > > You are correct there. From the modern business perspective, though, > management are Michael's personal customers. > > I think the argument still applies. If your goal is to convince > someone > that your choice of linux is correct, telling them why you chose linux > in the first place seems, to me at least, to be the best method, > rather > than seeking out reasons which you yourself haven't been concerned > with > previously. I don't think that's necessarily the case, just because Linux had better RT performance in 2000 doesn't mean it still does today, with Vista and general improvements. I think it's reasonable for management to question if it's still the best choice. - Steve From robin at gareus.org Wed Jan 31 07:54:45 2007 From: robin at gareus.org (Robin Gareus) Date: Wed Jan 31 07:54:55 2007 Subject: [linux-audio-dev] Old hat - comparison against windows In-Reply-To: <2F8CE890-02EB-4BD1-B18C-A438E196C462@plugin.org.uk> References: <45BF7A6F.9080205@museresearch.com> <1170191150.2232.427.camel@orchid.arb.net> <1170191886.2232.431.camel@orchid.arb.net> <20070130223028.GB9733@mobilat> <1170242846.2232.461.camel@orchid.arb.net> <2F8CE890-02EB-4BD1-B18C-A438E196C462@plugin.org.uk> Message-ID: <45C09194.2070306@gareus.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Steve Harris wrote: > > On 31 Jan 2007, at 11:27, Bob Ham wrote: >> [...] > > I don't think that's necessarily the case, just because Linux had better > RT performance in 2000 doesn't mean it still does today, with Vista and > general improvements. > > I think it's reasonable for management to question if it's still the > best choice. > pick two out of three: cheap, quick, good. - Who's in the management? :) IMO most modern PC/PPC hardware and OS are equally good enough for non-hi-end audio engineering. -> tweak your personal flavor! [hardware-]end-users are concerned about low-latency, scalability and reliability. (audio-processing-quality, easy-use, etc. are irrelevant here) Pro's for gnu/Linux that come to my mind: - flexibility (all kinds of... GNU) - reliability (you have the option to see what's the OS/HW is doing) - existing "free" Live-cds - active and open developer community ;-) - ... Cons; If "windows wants" it can perform better than a fully fledged rt-unix-kernel. - but that remains to be proven for Vista! It would be nice to have a software-suite to compare linux-audio-realtime performance .. - For linux/linux tests there seem to be various code-snippets out there... does anyone care to share pointers? robin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFwJGUeVUk8U+VK0IRAlBcAJ92OtWRExkXGwzf1OFxdCTlXW2KLQCgpX+9 AbZjWHeYCQ47Zy5OnRebsnY= =incw -----END PGP SIGNATURE----- From lars.luthman at gmail.com Wed Jan 31 08:01:52 2007 From: lars.luthman at gmail.com (Lars Luthman) Date: Wed Jan 31 08:10:18 2007 Subject: [linux-audio-dev] Old hat - comparison against windows In-Reply-To: <45C09194.2070306@gareus.org> References: <45BF7A6F.9080205@museresearch.com> <1170191150.2232.427.camel@orchid.arb.net> <1170191886.2232.431.camel@orchid.arb.net> <20070130223028.GB9733@mobilat> <1170242846.2232.461.camel@orchid.arb.net> <2F8CE890-02EB-4BD1-B18C-A438E196C462@plugin.org.uk> <45C09194.2070306@gareus.org> Message-ID: <1170248513.4947.0.camel@box.lars> On Wed, 2007-01-31 at 13:54 +0100, Robin Gareus wrote: > Cons; > If "windows wants" it can perform better than a fully fledged > rt-unix-kernel. - but that remains to be proven for Vista! Are you saying that this is true for XP? Are there any references for that? --ll From robin at gareus.org Wed Jan 31 09:06:02 2007 From: robin at gareus.org (Robin Gareus) Date: Wed Jan 31 09:06:18 2007 Subject: [linux-audio-dev] Old hat - comparison against windows In-Reply-To: <1170248513.4947.0.camel@box.lars> References: <45BF7A6F.9080205@museresearch.com> <1170191150.2232.427.camel@orchid.arb.net> <1170191886.2232.431.camel@orchid.arb.net> <20070130223028.GB9733@mobilat> <1170242846.2232.461.camel@orchid.arb.net> <2F8CE890-02EB-4BD1-B18C-A438E196C462@plugin.org.uk> <45C09194.2070306@gareus.org> <1170248513.4947.0.camel@box.lars> Message-ID: <45C0A24A.1050908@gareus.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lars Luthman wrote: > On Wed, 2007-01-31 at 13:54 +0100, Robin Gareus wrote: >> Cons; >> If "windows wants" it can perform better than a fully fledged >> rt-unix-kernel. - but that remains to be proven for Vista! > > Are you saying that this is true for XP? Are there any references for > that? maybe not for audio-apps. I once read some books about "subverting the windows kernel" - one can do marvelous stuff and get great performance out of it!! - only half kiddingly. - luckily I have not booted into XP for years and this "Con" might just be crap... however some instinct tells me that a UNIX - no matter how pre-emptive or tweaked - will always have more overhead than some DirectX-app. - but IMO this is irrelevant for "normal" audio apps on modern machines.. - memory management and -locking are more crucial.. robin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFwKJJeVUk8U+VK0IRAguvAKC5WkK6enqRl5YXpuqoY6hpdcjiCwCeKxSG Mqz4u/A+Eg8g/LD21Jvrlbc= =+Sl0 -----END PGP SIGNATURE----- From steve at plugin.org.uk Wed Jan 31 11:57:31 2007 From: steve at plugin.org.uk (Steve Harris) Date: Wed Jan 31 11:59:08 2007 Subject: [linux-audio-dev] Old hat - comparison against windows In-Reply-To: <45C0A24A.1050908@gareus.org> References: <45BF7A6F.9080205@museresearch.com> <1170191150.2232.427.camel@orchid.arb.net> <1170191886.2232.431.camel@orchid.arb.net> <20070130223028.GB9733@mobilat> <1170242846.2232.461.camel@orchid.arb.net> <2F8CE890-02EB-4BD1-B18C-A438E196C462@plugin.org.uk> <45C09194.2070306@gareus.org> <1170248513.4947.0.camel@box.lars> <45C0A24A.1050908@gareus.org> Message-ID: <2DF0C32F-E602-4F30-9710-1AAF27E4C1D5@plugin.org.uk> On 31 Jan 2007, at 14:06, Robin Gareus wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Lars Luthman wrote: >> On Wed, 2007-01-31 at 13:54 +0100, Robin Gareus wrote: >>> Cons; >>> If "windows wants" it can perform better than a fully fledged >>> rt-unix-kernel. - but that remains to be proven for Vista! >> >> Are you saying that this is true for XP? Are there any references for >> that? > > maybe not for audio-apps. > > I once read some books about "subverting the windows kernel" - one can > do marvelous stuff and get great performance out of it!! - only half > kiddingly. - luckily I have not booted into XP for years and this > "Con" > might just be crap... > > however some instinct tells me that a UNIX - no matter how pre-emptive > or tweaked - will always have more overhead than some DirectX-app. > - but > IMO this is irrelevant for "normal" audio apps on modern machines.. - > memory management and -locking are more crucial.. I don't know if it's still the case, but a few years ago the NT kernel was very heavyweight compared to the UNIX kernel, and too a long time to do things like context switches. - Steve From dlphillips at woh.rr.com Wed Jan 31 12:04:28 2007 From: dlphillips at woh.rr.com (Dave Phillips) Date: Wed Jan 31 12:32:32 2007 Subject: [linux-audio-dev] Old hat - comparison against windows In-Reply-To: <1170248513.4947.0.camel@box.lars> References: <45BF7A6F.9080205@museresearch.com> <1170191150.2232.427.camel@orchid.arb.net> <1170191886.2232.431.camel@orchid.arb.net> <20070130223028.GB9733@mobilat> <1170242846.2232.461.camel@orchid.arb.net> <2F8CE890-02EB-4BD1-B18C-A438E196C462@plugin.org.uk> <45C09194.2070306@gareus.org> <1170248513.4947.0.camel@box.lars> Message-ID: <45C0CC1C.8000609@woh.rr.com> Greetings: Michael Gogins recently tested Csound5 with Windows XP Media Center Edition and with Ubuntu 6.10. His tests indicated that Linux was the slightly better performer, you can check out his post and commentary on the Csound mail list archive : http://sourceforge.net/mailarchive/forum.php?thread_id=31517593&forum_id=43699 Best, dp From frsmith at gmail.com Tue Jan 30 13:33:37 2007 From: frsmith at gmail.com (Frank Smith) Date: Wed Jan 31 13:48:40 2007 Subject: [linux-audio-dev] Old hat - comparison against windows In-Reply-To: <51AEE533-2661-4243-9E71-08B56EAE58E2@plugin.org.uk> References: <45BF7A6F.9080205@museresearch.com> <51AEE533-2661-4243-9E71-08B56EAE58E2@plugin.org.uk> Message-ID: Hi I can only give you a musicians 'real world' comment. I had Sonar on my XP box and used it a lot for multitracking. It was an a Athlon 3400 64 ( running 32 xp) 1 gig ram and an RME card for sound. It ran fine on the XP box but still had a few wobblies re dropout after about 10 tracks. Can I point out I use all instruments live and record them to disk, haven't got Midi working yet. Thing is as you changed the tracks redoing some live again I noticed a slight compression on the tracks. It seemed to build up as you used more stuff on the tracks IE: reverbs and such. Not long after I installed 64studio and used Ardour doing the same kind of stuff, running 46 of course, and I didn't get this effect even on more tracks and using effects. To my ears the end result sounds cleaner and more like the original. Just my 2 p's worth! Cheers Bob wavesound On 30/01/07, Steve Harris wrote: > > > On 30 Jan 2007, at 17:03, Michael Ost wrote: > > > Can anyone suggest ways to compare audio/midi performance between > > Linux > > and Windows that (1) are relevant to non-technical musicians and (2) > > make Linux compare favorably? > > > > Not things like "I just don't like Windows" or software feature > > comparisons or the politics of open vs. closed source, but rather > > things > > like responsiveness to audio interrupts, RAM footprint of the OS > > and ...? > > > > I work for a company that sells a Linux based piece of hardware that > > plays windows VSTs. We spend alot of time on compatibility, > > especially > > on getting the plugins to work with Wine. I often get asked about > > switching to Windows and I don't have a good answer. > > > > My sense is that the main benefit of Linux is that audio interrupts > > are > > serviced faster and more predictably than in Windows because of > > SCHED_FIFO and Linux's low overhead. And clearly musicians could feel > > that, especially at lower buffer size settings so that's the kind of > > thing that could matter. > > I would have thought that the best way to measure scheduler > performance is to write a simple VST plugin that writes the precise > time at which it was called into a ram buffer, and writes the buffer > out to disk after a few tens of thousands of calls. > > You can the measure the times between adjacent runs and work out if > there's any significant difference in jitter. > > I would think that the RAM footprint is essentially impossible to > measure, as you can't tell what proportion of the kernel space is > buffers etc. > > From a commercial point of view, your are at the very least saving > licence fees for each piece of hardware, that would surely eat into > your profit margin. > > - Steve > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20070130/03d8257e/attachment.html From frsmith at gmail.com Wed Jan 31 05:00:41 2007 From: frsmith at gmail.com (Frank Smith) Date: Wed Jan 31 13:48:46 2007 Subject: [linux-audio-dev] Old hat - comparison against windows In-Reply-To: <45C064DE.90905@spamatica.se> References: <45BF7A6F.9080205@museresearch.com> <1170191150.2232.427.camel@orchid.arb.net> <1170191886.2232.431.camel@orchid.arb.net> <20070130223028.GB9733@mobilat> <45C064DE.90905@spamatica.se> Message-ID: I would not rule out that Linux is found to perform worse under some circumstances. But that is ok. Adaptability is one of the strong points of open source, once we know the problems we can start fixing them. Nice point and this is the strength of OS. the problems are addressed far quicker than in Prop' software. Cheers Bob On 31/01/07, Robert Jonsson wrote: > > Hi, > > torbenh@gmx.de skrev: > > On Tue, Jan 30, 2007 at 09:18:06PM +0000, Bob Ham wrote: > > > >> On Tue, 2007-01-30 at 21:05 +0000, Bob Ham wrote: > >> > >>> On Tue, 2007-01-30 at 09:03 -0800, Michael Ost wrote: > >>> > >>>> Can anyone suggest ways to compare audio/midi performance between > Linux > >>>> and Windows that ... make Linux compare favorably? > >>>> > >>>> I work for a company that sells a Linux based piece of hardware that > >>>> plays windows VSTs. > >>>> > >>> The word "FUD" comes to mind. No idea why. > >>> > >> Further to that, something constructive: perhaps you could try telling > >> your customers why *you* chose linux, rather than trying to find > reasons > >> to tell them *they* should. > >> > > > > the customers dont notice. they still use windows or no computers at > > all. > > > > it looks rather like a question from the management. > > > > Whatever the reasons, it's a valid and interesting question. In truth > Linux is often touted (not the least with respect to audio) as a better > performer than Windows. > Though I can't say that I have personally experienced this. It is hard > work getting a Linux system "tuned", I have actually never succeeded > without some drawback that have forced me back to generic configurations. > > Not that I complain, my current (k)ubuntu kernel performs "good > enough"tm, but I am certain it would be no problem getting equal > performance under Windows. My choice of using Linux has more to do with > the freedom of opensourceness (it's a word!..now atleast). > > Steve's idea with a vst timing plugin sounds very interesting. One using > LADSPA would be equally interesting for comparing Linux to Linux. Are > there other performance measurements that would be nice? xruns under > load I suppose. > Having a test suite for system performance would be great! > > I would not rule out that Linux is found to perform worse under some > circumstances. But that is ok. Adaptability is one of the strong points > of open source, once we know the problems we can start fixing them. > > Regards, > Robert > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20070131/56560063/attachment.html From most at museresearch.com Wed Jan 31 14:32:30 2007 From: most at museresearch.com (Michael Ost) Date: Wed Jan 31 14:33:08 2007 Subject: [linux-audio-dev] Old hat - comparison against windows In-Reply-To: <20070130222551.94CFC61E1A86@music.columbia.edu> References: <20070130222551.94CFC61E1A86@music.columbia.edu> Message-ID: <45C0EECE.1060407@museresearch.com> > On Tue, 2007-01-30 at 21:05 +0000, Bob Ham wrote: > Further to that, something constructive: perhaps you could try telling > your customers why *you* chose linux, rather than trying to find reasons > to tell them *they* should. My reasons, from back in about 2000, were "cost" and "interesting". First off the license costs were not hard to sell. And secondly that I personally wanted to program in Linux. I thought it would be interesting --- and it has been fun. Also the company was kind of a crapshoot and I wanted the professional experience on my resume if I needed to go get another job. Embedded Linux sounded good to me. I want to stick with Linux and hoped there were some measurable performance differences to tout. Sounds like there aren't, really. And now for some more kind of Dilbert-esque background for the curious... A couple of years ago, we tried answering this question by measuring the time between a midi impulse on a rigged midi cable and audio output on an oscilloscope. We tested Receptor vs Windows 2000 running VStack. The Receptor was not more responsive but was less jittery in its reponse. We engineers didn't feel that the results were carefully enough generated to be publicly announced, but we felt that our hunch was being confirmed. Then I made some perhaps loose comments about how Linux is less bloated than Windows. True, but not quantifiable. Then there is the general (and vague) perception among many in the music biz that Windows is not for pro audio. All of these factors led our non-tech people here to start saying that our OS was better. Being an engineer, and not being able to quantify "better", I would cringe when they would say that and qualify endlessly. But I also couldn't prove anything either way, so I kind of left it. As time has passed, I have found that I was naive about the costs of Wine (VST compatibility, Linux (hardware compatibility, especially USB and firewire audio/midi devices) and the costs of getting programmers productive on Linux as a development platform. Now it is time for a leap to a newer OS --- 2.4 isn't giving us SATA drive support and our Wine is getting old (vinegar? %). Our code could do Windows pretty easily. Should I push for that, or move to a newer Linux? There you have it. Life in the software business. By the way, I appreciate all of the comments. I expected it might be a loaded question! ... mo From rlrevell at joe-job.com Wed Jan 31 14:44:48 2007 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Jan 31 14:44:53 2007 Subject: [linux-audio-dev] Old hat - comparison against windows In-Reply-To: <45C0EECE.1060407@museresearch.com> References: <20070130222551.94CFC61E1A86@music.columbia.edu> <45C0EECE.1060407@museresearch.com> Message-ID: <75b66ecd0701311144u4f3a9257u88e85817af2c7158@mail.gmail.com> On 1/31/07, Michael Ost wrote: > Now it is time for a leap to a newer OS --- 2.4 isn't giving us SATA > drive support and our Wine is getting old (vinegar? %). Our code could > do Windows pretty easily. Should I push for that, or move to a newer Linux? I would say it depends on how much Windows would cost per unit, and whether you can tolerate being at the mercy of vendors and Microsoft to fix any bugs you find. However I didn't realize that you were using 2.4. 2.6 with the -rt patches should definitely give better latency than Windows. In fact it's capable of uselessly low latencies like 0.66ms on some hardware, which is exactly the kind of thing the marketing guys love ;-) Lee From richard.spindler at gmail.com Wed Jan 31 14:46:22 2007 From: richard.spindler at gmail.com (Richard Spindler) Date: Wed Jan 31 14:46:27 2007 Subject: [linux-audio-dev] Old hat - comparison against windows In-Reply-To: <45C0EECE.1060407@museresearch.com> References: <20070130222551.94CFC61E1A86@music.columbia.edu> <45C0EECE.1060407@museresearch.com> Message-ID: <4af8d6ff0701311146s18afb7d8ie1de212de3e45378@mail.gmail.com> 2007/1/31, Michael Ost : > Now it is time for a leap to a newer OS --- 2.4 isn't giving us SATA > drive support and our Wine is getting old (vinegar? %). Our code could > do Windows pretty easily. Should I push for that, or move to a newer Linux? I think there is no general answer, however it mostly depends on the people, do you have any significant experience programming on the win32 platform? Do your engineers have any significant experience? I've made the observation on myself, that once you are immersed in an open and free platform, it is very hard to go back to something like win32. You just get used to a lot of things that are natural on your platform, which are hardly available outside. Every once in a while I port some software from Linux to Windows, and beforehead I think: "Can't be that hard, all the tools are available." And then the cursing starts. Have try, and do some work on windows, if you think you can handle it, it might be an option. But if you have any doubts, drop it. It seems that you have a lot of Linux-Experience. This is a serious investment that I wouldn't throw away lightly. Cheers -Richard -- Are you teaching the What and the How but without the Why and the When? From most at museresearch.com Wed Jan 31 15:02:50 2007 From: most at museresearch.com (Michael Ost) Date: Wed Jan 31 15:03:25 2007 Subject: [linux-audio-dev] Old hat - comparison against windows In-Reply-To: <75b66ecd0701311144u4f3a9257u88e85817af2c7158@mail.gmail.com> References: <20070130222551.94CFC61E1A86@music.columbia.edu> <45C0EECE.1060407@museresearch.com> <75b66ecd0701311144u4f3a9257u88e85817af2c7158@mail.gmail.com> Message-ID: <45C0F5EA.2080202@museresearch.com> Lee Revell wrote: > However I didn't realize that you were using 2.4. 2.6 with the -rt > patches should definitely give better latency than Windows. In fact > it's capable of uselessly low latencies like 0.66ms on some hardware, > which is exactly the kind of thing the marketing guys love ;-) We have a 32 sample setting (.7 msecs) in Receptor which I have yet to see in a Windows driver. And it actually works with some plugins, even a large sampler like Synthogy Ivory --- if you don't try to play too many notes. %) So, yes, thanks, that's an idea. - mo From most at museresearch.com Wed Jan 31 15:14:36 2007 From: most at museresearch.com (Michael Ost) Date: Wed Jan 31 15:15:12 2007 Subject: [linux-audio-dev] Old hat - comparison against windows In-Reply-To: <20070131194455.7EC326245460@music.columbia.edu> References: <20070131194455.7EC326245460@music.columbia.edu> Message-ID: <45C0F8AC.10603@museresearch.com> > "Frank Smith" > Nice point and this is the strength of OS. the problems are addressed > far quicker than in Prop' software. Yes, that's good. Microsoft doesn't give a hoot about professional audio. We can actually tweak the OS, and Wine, to improve performance of our specific application. We got an improvement of Wine's CRITICAL_SECTION implementation in (using futexes) that helped DFH perform during heavy use of a particular drum. - mo From david at olofson.net Wed Jan 31 15:35:16 2007 From: david at olofson.net (David Olofson) Date: Wed Jan 31 15:37:02 2007 Subject: [linux-audio-dev] Old hat - comparison against windows In-Reply-To: <45C0F5EA.2080202@museresearch.com> References: <20070130222551.94CFC61E1A86@music.columbia.edu> <75b66ecd0701311144u4f3a9257u88e85817af2c7158@mail.gmail.com> <45C0F5EA.2080202@museresearch.com> Message-ID: <200701312135.16185.david@olofson.net> On Wednesday 31 January 2007 21:02, Michael Ost wrote: [...] > We have a 32 sample setting (.7 msecs) in Receptor which I have yet > to see in a Windows driver. And it actually works with some plugins, > even a large sampler like Synthogy Ivory --- if you don't try to > play too many notes. %) [...] Have you considered RTAI/LXRT (microsecond scale hard real time in user space, sort of) for really insane latencies? ;-) You would have to wire any API calls used in real time threads to implementations over RTAI, as you'll be switched back to normal SCHED_FIFO if you try to make any normal system calls. Further, you'd have to use shared memory (ie raw DMA buffer) mode, and some "external" synchronization mechanism, so you can avoid talking directly to the audio driver from the RT thread. Now, you still can't get below the minimum latency of the sound card, which is usually defined by the PCI DMA burst size. Scheduling jitter can be low enough to process one sample at a time at 44.1 kHz, but the only real use for that is better CPU utilization; that is, you can push closer to 100% load without getting dropouts. Of course, all of this is pretty much moot, unless all code that runs in the real time thread is strictly deterministic. My point is just that with an Open Source OS, at least in environments where you can have total control over the whole system, you don't have to stop at "sensible" solutions. There really is no limit to what you can do, if you really have to or want to, and have the time and resources at hand. //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --' From paul at linuxaudiosystems.com Wed Jan 31 15:45:51 2007 From: paul at linuxaudiosystems.com (Paul Davis) Date: Wed Jan 31 15:46:35 2007 Subject: [linux-audio-dev] Old hat - comparison against windows In-Reply-To: <200701312135.16185.david@olofson.net> References: <20070130222551.94CFC61E1A86@music.columbia.edu> <75b66ecd0701311144u4f3a9257u88e85817af2c7158@mail.gmail.com> <45C0F5EA.2080202@museresearch.com> <200701312135.16185.david@olofson.net> Message-ID: <1170276351.18649.263.camel@localhost.localdomain> On Wed, 2007-01-31 at 21:35 +0100, David Olofson wrote: > On Wednesday 31 January 2007 21:02, Michael Ost wrote: > [...] > > We have a 32 sample setting (.7 msecs) in Receptor which I have yet > > to see in a Windows driver. And it actually works with some plugins, > > even a large sampler like Synthogy Ivory --- if you don't try to > > play too many notes. %) > [...] > > Have you considered RTAI/LXRT (microsecond scale hard real time in > user space, sort of) for really insane latencies? ;-) there are no drivers for any audio interfaces that run in RTAI kernel space or in user space. theoretically, its cool an' all; practically speaking, i think its useless. --p From david at olofson.net Wed Jan 31 16:20:28 2007 From: david at olofson.net (David Olofson) Date: Wed Jan 31 16:22:09 2007 Subject: [linux-audio-dev] Old hat - comparison against windows In-Reply-To: <1170276351.18649.263.camel@localhost.localdomain> References: <20070130222551.94CFC61E1A86@music.columbia.edu> <200701312135.16185.david@olofson.net> <1170276351.18649.263.camel@localhost.localdomain> Message-ID: <200701312220.28732.david@olofson.net> On Wednesday 31 January 2007 21:45, Paul Davis wrote: > On Wed, 2007-01-31 at 21:35 +0100, David Olofson wrote: > > On Wednesday 31 January 2007 21:02, Michael Ost wrote: > > [...] > > > We have a 32 sample setting (.7 msecs) in Receptor which I have > > > yet to see in a Windows driver. And it actually works with some > > > plugins, even a large sampler like Synthogy Ivory --- if you > > > don't try to play too many notes. %) > > [...] > > > > Have you considered RTAI/LXRT (microsecond scale hard real time in > > user space, sort of) for really insane latencies? ;-) > > there are no drivers for any audio interfaces that run in RTAI > kernel space or in user space. > > theoretically, its cool an' all; practically speaking, i think its > useless. There are a few hacks for RTAI and/or RTLinux, actually, but AFAIK, nothing for any serious hardware... (I did one myself a few years ago, for RTLinux and AudioPCI cards, IIRC.) Anyway, this is why I'm suggesting memory mapped mode. Instead of blocking in the driver calls, the audio thread would block on a periodic RTAI timer. The timer would be kept in sync with the hardware using an RTAI interrupt handler on the sound card IRQ, or (possibly simpler but less accurate) by a SCHED_FIFO thread that does talk to the driver. It's pretty much the same method used by many PC game and demo sounds systems back in the DOS days. Instead of running the audio code in the interrupt context (if there was any!), it was run either in the video main loop or in some timer interrupt, while the DMA just kept looping over a buffer of 64 kB or so. For running audio code under RTAI, it would probably be more appropriate to adjust the timer interval to keep the fragment size constant, but of course, the other way around may work too, depending on the plugin API and/or plugin implementations. You'd have to infer the timings either way, unless you can somehow read the current DMA position from the RTAI thread. All that said, MIDI I/O would still be restricted to SCHED_FIFO scheduling. Missing MIDI deadlines is usually a lot less serious than missing audio deadlines, though, so it may not be a real issue. //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --' From rlrevell at joe-job.com Wed Jan 31 16:49:47 2007 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Jan 31 16:50:06 2007 Subject: [linux-audio-dev] Old hat - comparison against windows In-Reply-To: <200701312220.28732.david@olofson.net> References: <20070130222551.94CFC61E1A86@music.columbia.edu> <200701312135.16185.david@olofson.net> <1170276351.18649.263.camel@localhost.localdomain> <200701312220.28732.david@olofson.net> Message-ID: <75b66ecd0701311349l68cadb15pcb40c17cd4869c11@mail.gmail.com> On 1/31/07, David Olofson wrote: > There are a few hacks for RTAI and/or RTLinux, actually, but AFAIK, > nothing for any serious hardware... (I did one myself a few years > ago, for RTLinux and AudioPCI cards, IIRC.) There's no point these days - the 2.6 -rt kernel can already deliver latencies down to the hardware limit. Lee From david at olofson.net Wed Jan 31 17:23:57 2007 From: david at olofson.net (David Olofson) Date: Wed Jan 31 17:25:36 2007 Subject: [linux-audio-dev] Old hat - comparison against windows In-Reply-To: <75b66ecd0701311349l68cadb15pcb40c17cd4869c11@mail.gmail.com> References: <20070130222551.94CFC61E1A86@music.columbia.edu> <200701312220.28732.david@olofson.net> <75b66ecd0701311349l68cadb15pcb40c17cd4869c11@mail.gmail.com> Message-ID: <200701312323.57745.david@olofson.net> On Wednesday 31 January 2007 22:49, Lee Revell wrote: > On 1/31/07, David Olofson wrote: > > There are a few hacks for RTAI and/or RTLinux, actually, but > > AFAIK, nothing for any serious hardware... (I did one myself a few > > years ago, for RTLinux and AudioPCI cards, IIRC.) > > There's no point these days - the 2.6 -rt kernel can already deliver > latencies down to the hardware limit. Yes, but that's not all there is to it. Jitter reduces the amount of CPU time available for real time processing. Worst case jitter of N ms means you can't safely use more than M - N ms per fragment, where M is the fragment period. Triple buffering or dynamic fragment size may cut you some extra slack in relation to total latency (same logic as triple buffering with OpenGL), but this isn't supported by all hardware. Related to this, making efficient use of multiple CPUs and/or cores requires much tighter timing than UP processing, unless you can get away with running multiple independent audio "pipes" in parallell. The inter-thread sync can be solved with lock free mechanisms, but that doesn't help much if threads with tight interdependencies get out of phase due to scheduling latencies. That said, as you can't use all CPU time on a UP machine anyway, and as cache issues seem to make multithreaded processing virtually pointless (with the possible exception of multicore CPUs), it's entirely possible that there is no real gain in cutting latencies below what 2.6-rt can provide. I don't know, but it might be worth some experiments... //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --' From rlrevell at joe-job.com Wed Jan 31 17:39:59 2007 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Jan 31 17:40:06 2007 Subject: [linux-audio-dev] Old hat - comparison against windows In-Reply-To: <200701312323.57745.david@olofson.net> References: <20070130222551.94CFC61E1A86@music.columbia.edu> <200701312220.28732.david@olofson.net> <75b66ecd0701311349l68cadb15pcb40c17cd4869c11@mail.gmail.com> <200701312323.57745.david@olofson.net> Message-ID: <75b66ecd0701311439i2a1cd4c6tdfca4e1cb9eb90e8@mail.gmail.com> On 1/31/07, David Olofson wrote: > That said, as you can't use all CPU time on a UP machine anyway, and > as cache issues seem to make multithreaded processing virtually > pointless (with the possible exception of multicore CPUs), it's > entirely possible that there is no real gain in cutting latencies > below what 2.6-rt can provide. I don't know, but it might be worth > some experiments... Maximum jitter with 2.6-rt is 20-50 microseconds last time I checked. So less than 5% even at a marginally useful period sizes like 32 frames. Lee From david at olofson.net Wed Jan 31 17:43:29 2007 From: david at olofson.net (David Olofson) Date: Wed Jan 31 17:45:08 2007 Subject: [linux-audio-dev] Old hat - comparison against windows In-Reply-To: <75b66ecd0701311439i2a1cd4c6tdfca4e1cb9eb90e8@mail.gmail.com> References: <20070130222551.94CFC61E1A86@music.columbia.edu> <200701312323.57745.david@olofson.net> <75b66ecd0701311439i2a1cd4c6tdfca4e1cb9eb90e8@mail.gmail.com> Message-ID: <200701312343.29821.david@olofson.net> On Wednesday 31 January 2007 23:39, Lee Revell wrote: > On 1/31/07, David Olofson wrote: > > That said, as you can't use all CPU time on a UP machine anyway, > > and > > as cache issues seem to make multithreaded processing virtually > > pointless (with the possible exception of multicore CPUs), it's > > entirely possible that there is no real gain in cutting latencies > > below what 2.6-rt can provide. I don't know, but it might be worth > > some experiments... > > Maximum jitter with 2.6-rt is 20-50 microseconds last time I > checked. > So less than 5% even at a marginally useful period sizes like 32 > frames. Well, that's not even an order of magnitude away from what you can get with a "true" RTOS on this type of hardware. (You can get a lot worse with crappy motherboards, regardless of OS...) If that's really the worst case, I don't think there is room for any significant improvement, even in theory. :-) //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --'