From v2 at iki.fi Wed Mar 1 03:22:26 2006 From: v2 at iki.fi (Sampo Savolainen) Date: Wed Mar 1 03:22:31 2006 Subject: [linux-audio-dev] Juce now has ALSA support! Message-ID: <1141201346.440559c272cad@www2.helsinki.fi> Quoting Julian Storer : > Hi folks > > A while ago there was some talk on the newsgroup about my Juce library, > and people were asking if/when I'd add support for audio under Linux.. > well it's taken me a while to get round to it, but I finally battled > through the hostile, undocumented jungle of ALSA, and the latest Juce > release does finally make a noise under Linux! This is truly great news. I really appreciate the effort you have put into the port, and to supporting Linux. Alas, ALSA. It's very unfortunate that you chose ALSA as the API for Linux. For me, applications without jack support are of zero interest. I live in a world where i can just connect every soft synth and drum machine and midi sequencer via jack to ardour, sync them via jack transport, do mastering inside this environment with Jamin. I'm capable of exporting & mastering faster-than-realtime, because all the software inside the "jack loop" will all run in perfect sync, in-time & on-time with jack instead of the soundcard. These are the benefits from jack. This is why I will give almost no consideration for an application which isn't jackd compatible. The worst thing that can happen is that you get disencouraged. I really do hope you won't get. Like Paul said, the jackd api is super-simple, you should have no trouble at all making a driver for JUCE which uses jackd. Please, pretty please, with sugar, whip cream and a coctail cherry on top. Don't give up! :) (And i guess you've already worked through the GUI & input issues of porting JUCE to Linux, so one more driver should be a breeze) Sampo From james at dis-dot-dat.net Wed Mar 1 04:10:14 2006 From: james at dis-dot-dat.net (james@dis-dot-dat.net) Date: Wed Mar 1 03:58:15 2006 Subject: [linux-audio-dev] [ANN] arcangel (and result of widget discussion) In-Reply-To: References: <20060226135333.GB8325@phlunky.Belkin> Message-ID: <20060301091014.GA14117@phlunky.Belkin> On Tue, 28 Feb, 2006 at 10:19PM +0100, Julien Claassen spake thus: > Hi James! > Could you do a ladspa-plugin for it? OK. I just hope writing LADSPA plugins is less of a challenge than writing LADSPA hosts. > Kindest regards > Julien > > Music was my first love and it will be my last (John Miles) > > ======== FIND MY WEB-PROJECT AT: ======== > http://ltsb.sourceforge.net - the Linux TextBased Studio guide > -- "I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you." (By Vance Petree, Virginia Power) From jules at rawmaterialsoftware.com Wed Mar 1 04:02:31 2006 From: jules at rawmaterialsoftware.com (Julian Storer) Date: Wed Mar 1 04:02:42 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <1141186434.5860.94.camel@mindpipe> References: <20060301035629.2144.qmail@web60712.mail.yahoo.com> <1141186434.5860.94.camel@mindpipe> Message-ID: <44056327.7050507@rawmaterialsoftware.com> Ok, thanks Lee - I deliberately used the hw pcm devices though, as they gave better performance than the default one. I guess it just needs support for some extra data formats. Lee Revell wrote: >On Wed, 2006-03-01 at 03:56 +0000, Kevin Hremeviuc wrote: > > >>Hi Julian, >> >>Just compiled juce and tried the demo programme. Got >>the error contained in the attached screen capture. I >>don't normally have any problems running alsa audio >>apps, however the fault may be in my alsa setup. >> >>Kev >> >> > >It appears that Juce is opening the "hw" PCM which only support S32_LE >on your device. It should be opening the "default" PCM which will >automagically convert whatever format Juce uses to S32_LE. > >Lee > > > > > > From loki.davison at gmail.com Wed Mar 1 04:26:26 2006 From: loki.davison at gmail.com (Loki Davison) Date: Wed Mar 1 04:26:31 2006 Subject: [linux-audio-dev] Re: arcangel (and result of widget discussion) In-Reply-To: <20060301091014.GA14117@phlunky.Belkin> References: <20060226135333.GB8325@phlunky.Belkin> <20060301091014.GA14117@phlunky.Belkin> Message-ID: On 3/1/06, james@dis-dot-dat.net wrote: > On Tue, 28 Feb, 2006 at 10:19PM +0100, Julien Claassen spake thus: > > Hi James! > > Could you do a ladspa-plugin for it? > > OK. I just hope writing LADSPA plugins is less of a challenge than > writing LADSPA hosts. > Ladspa plugins are easy to write, or dssi's if you want a gui as well. You're prog really suits being a plugin. You can use the ladspa's in omins as an example, most are quite simple and cleanly written, well the ones that arn't my horrible physical synthesis code. If you do it as a ladspa plugin i'm sure the omins crew would be keen to have it in our collection, if you want to distribute it like that. Loki From James at superbug.co.uk Wed Mar 1 05:42:08 2006 From: James at superbug.co.uk (James Courtier-Dutton) Date: Wed Mar 1 05:42:23 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <44056327.7050507@rawmaterialsoftware.com> References: <20060301035629.2144.qmail@web60712.mail.yahoo.com> <1141186434.5860.94.camel@mindpipe> <44056327.7050507@rawmaterialsoftware.com> Message-ID: <44057A80.2040402@superbug.co.uk> Julian Storer wrote: > Ok, thanks Lee - I deliberately used the hw pcm devices though, as > they gave better performance than the default one. I guess it just > needs support for some extra data formats. > What do you mean? Better performance in what way? The "default" will have no performance hit is the sound card supports the same format as the application, otherwise, "default" will automatically do sample format conversion. In any case, the ALSA device name to use should be user configurable. James This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. From jules at rawmaterialsoftware.com Wed Mar 1 06:56:17 2006 From: jules at rawmaterialsoftware.com (Julian Storer) Date: Wed Mar 1 06:56:39 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <44057A80.2040402@superbug.co.uk> References: <20060301035629.2144.qmail@web60712.mail.yahoo.com> <1141186434.5860.94.camel@mindpipe> <44056327.7050507@rawmaterialsoftware.com> <44057A80.2040402@superbug.co.uk> Message-ID: <44058BE1.2030202@rawmaterialsoftware.com> Am I right in assuming that by default you mean the "plughw:" devices? On my machine the plughw: device glitched constantly, but the hw: devices worked really well. There was also some other reason I chose that.. can't remember offhand what it was though. James Courtier-Dutton wrote: > Julian Storer wrote: > >> Ok, thanks Lee - I deliberately used the hw pcm devices though, as >> they gave better performance than the default one. I guess it just >> needs support for some extra data formats. >> > What do you mean? Better performance in what way? > The "default" will have no performance hit is the sound card supports > the same format as the application, otherwise, "default" will > automatically do sample format conversion. > In any case, the ALSA device name to use should be user configurable. > > James > > > > This e-mail and any attachment is for authorised use by the intended > recipient(s) only. It may contain proprietary material, confidential > information and/or be subject to legal privilege. It should not be > copied, disclosed to, retained or used by, any other party. If you are > not an intended recipient then please promptly delete this e-mail and > any attachment and all copies and inform the sender. Thank you. > > > From James at superbug.co.uk Wed Mar 1 07:31:09 2006 From: James at superbug.co.uk (James Courtier-Dutton) Date: Wed Mar 1 07:31:43 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <44058BE1.2030202@rawmaterialsoftware.com> References: <20060301035629.2144.qmail@web60712.mail.yahoo.com> <1141186434.5860.94.camel@mindpipe> <44056327.7050507@rawmaterialsoftware.com> <44057A80.2040402@superbug.co.uk> <44058BE1.2030202@rawmaterialsoftware.com> Message-ID: <4405940D.6090409@superbug.co.uk> Julian Storer wrote: > Am I right in assuming that by default you mean the "plughw:" devices? > On my machine the plughw: device glitched constantly, but the hw: > devices worked really well. There was also some other reason I chose > that.. can't remember offhand what it was though. "default" means just that. use the name "default" instead of plughw:.... or hw:0,0 If the device glitched when using "plughw:" then it is a bug in ALSA or your application. How is you application deciding on sample rate? There is no sensible reason to ever use the "hw:0,0" device. Always use the "plug:front" and friends. If an application only works with "hw:0,0" it has been written wrongly. James P.S. Please don't top post. This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. From ix at replic.net Wed Mar 1 07:44:07 2006 From: ix at replic.net (cdr) Date: Wed Mar 1 07:44:12 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <4405940D.6090409@superbug.co.uk> References: <20060301035629.2144.qmail@web60712.mail.yahoo.com> <1141186434.5860.94.camel@mindpipe> <44056327.7050507@rawmaterialsoftware.com> <44057A80.2040402@superbug.co.uk> <44058BE1.2030202@rawmaterialsoftware.com> <4405940D.6090409@superbug.co.uk> Message-ID: <20060301124407.GA10910@replic.net> On Wed Mar 01, 2006 at 12:31:09PM +0000, James Courtier-Dutton wrote: > Julian Storer wrote: yeah, this is good news , a windows/mac developer who has ventured into the fray. awfully rare in this day and age. to most of these people, its as if this world doesnt exist. > >Am I right in assuming that by default you mean the "plughw:" devices? > >On my machine the plughw: device glitched constantly, but the hw: > >devices worked really well. There was also some other reason I chose > >that.. can't remember offhand what it was though. > "default" means just that. use the name "default" instead of plughw:.... > or hw:0,0 > If the device glitched when using "plughw:" then it is a bug in ALSA or > your application. > How is you application deciding on sample rate? > > There is no sensible reason to ever use the "hw:0,0" device. Always use > the "plug:front" and friends. > If an application only works with "hw:0,0" it has been written wrongly. > > James > > P.S. Please don't top post. what does this mean. put the reply below the quoted content? in most readers i can think of off the top of myy head, the top is the best place to put a reply,. since it is more likely to show up in a brief synopsis, ,and not require paging down.. but then most of the world likes to prewrap their messages which is annoyingly narrow on a big screen or suffers from linebreak-hell on a cellphone, , so i guess i'll remain on the fringes of acceptability > > > > This e-mail and any attachment is for authorised use by the intended > recipient(s) only. It may contain proprietary material, confidential > information and/or be subject to legal privilege. It should not be copied, > disclosed to, retained or used by, any other party. If you are not an > intended recipient then please promptly delete this e-mail and any > attachment and all copies and inform the sender. Thank you. From jules at rawmaterialsoftware.com Wed Mar 1 07:51:46 2006 From: jules at rawmaterialsoftware.com (Julian Storer) Date: Wed Mar 1 07:52:04 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <4405940D.6090409@superbug.co.uk> References: <20060301035629.2144.qmail@web60712.mail.yahoo.com> <1141186434.5860.94.camel@mindpipe> <44056327.7050507@rawmaterialsoftware.com> <44057A80.2040402@superbug.co.uk> <44058BE1.2030202@rawmaterialsoftware.com> <4405940D.6090409@superbug.co.uk> Message-ID: <440598E2.8010402@rawmaterialsoftware.com> James Courtier-Dutton wrote: > Julian Storer wrote: > >> Am I right in assuming that by default you mean the "plughw:" >> devices? On my machine the plughw: device glitched constantly, but >> the hw: devices worked really well. There was also some other reason >> I chose that.. can't remember offhand what it was though. > > "default" means just that. use the name "default" instead of > plughw:.... or hw:0,0 > If the device glitched when using "plughw:" then it is a bug in ALSA > or your application. > How is you application deciding on sample rate? > There is no sensible reason to ever use the "hw:0,0" device. Always > use the "plug:front" and friends. > If an application only works with "hw:0,0" it has been written wrongly. > Ok, at the risk of "spreading the myth" that the ALSA documentation is bad... is this stuff actually explained anywhere?? It took me a day of googling just to find out what the two numbers after "hw" meant! I never saw anything mention "default" or "plug:front", etc. Not sure if it'd be appropriate anyway, though, as my API exposes a list of drivers and lets the user choose which one to use, and the sample rate, rather than just using the default driver. > James > > P.S. Please don't top post. > From b0ef at esben-stien.name Wed Mar 1 10:47:14 2006 From: b0ef at esben-stien.name (Esben Stien) Date: Wed Mar 1 08:57:41 2006 Subject: [linux-audio-dev] Fwd: OT -- USB History In-Reply-To: <1140219411.2733.103.camel@mindpipe> (Lee Revell's message of "Fri, 17 Feb 2006 18:36:51 -0500") References: <200602162006.43276.ce@christeck.de> <20060217131135.GB11415@ifiu25.informatik.uni-halle.de> <200602172144.04620.ce@christeck.de> <1140219411.2733.103.camel@mindpipe> Message-ID: <87slq2qi9p.fsf@esben-stien.name> Lee Revell writes: > It's called "firewire" Shouldn't we call it 1394?. As I understand it, if you want to sell a product with the firewire name you'd have to pay. -- Esben Stien is b0ef@e s a http://www. s t n m irc://irc. b - i . e/%23contact [sip|iax]: e e jid:b0ef@ n n From larsl at users.sourceforge.net Wed Mar 1 11:26:53 2006 From: larsl at users.sourceforge.net (Lars Luthman) Date: Wed Mar 1 11:26:06 2006 Subject: [linux-audio-dev] [ANN] arcangel (and result of widget discussion) In-Reply-To: <20060301091014.GA14117@phlunky.Belkin> References: <20060226135333.GB8325@phlunky.Belkin> <20060301091014.GA14117@phlunky.Belkin> Message-ID: <1141230413.8876.7.camel@c213-100-50-8.swipnet.se> On Wed, 2006-03-01 at 09:10 +0000, james@dis-dot-dat.net wrote: > On Tue, 28 Feb, 2006 at 10:19PM +0100, Julien Claassen spake thus: > > Hi James! > > Could you do a ladspa-plugin for it? > > OK. I just hope writing LADSPA plugins is less of a challenge than > writing LADSPA hosts. It is - the whole point of a plugin system is to let the host do as much of the plumbing as possible so the plugin writer can focus on whatever it is that the plugin should be doing. LADSPAs still need a certain amount of boilerplate code to work though, but you should be able to just steal that from an existing plugin. Or you could use this library that I use for my plugins: http://ll-plugins.sourceforge.net/dsl/dssi-support-libs-0.5.35.tar.gz It's mostly for DSSIs, but it contains a small static library that you can link with to create LADSPA plugins as well. The code for a basic LADSPA plugin would then look something like this: http://ll-plugins.sourceforge.net/dsl/0.5.35/html/classLADSPAPlugin.html#_details The library has not been released yet, so no backwards compatibility is guaranteed - if you want to use it the best way may be to simply steal ladspaplugin.hpp and ladspaplugin.cpp from the source package and compile them with your plugin. -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- 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/20060301/f09bf237/attachment.bin From rlrevell at joe-job.com Wed Mar 1 12:23:44 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Mar 1 12:23:53 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <44056327.7050507@rawmaterialsoftware.com> References: <20060301035629.2144.qmail@web60712.mail.yahoo.com> <1141186434.5860.94.camel@mindpipe> <44056327.7050507@rawmaterialsoftware.com> Message-ID: <1141233825.5860.124.camel@mindpipe> On Wed, 2006-03-01 at 09:02 +0000, Julian Storer wrote: > Ok, thanks Lee - I deliberately used the hw pcm devices though, as they > gave better performance than the default one. I guess it just needs > support for some extra data formats. This is broken - you'd have to embed knowledge of every single format that ALSA supports in your app, or else your app will only support certain soundcards! Please, at least make this configurable. Lee From rlrevell at joe-job.com Wed Mar 1 12:26:00 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Mar 1 12:26:10 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <440598E2.8010402@rawmaterialsoftware.com> References: <20060301035629.2144.qmail@web60712.mail.yahoo.com> <1141186434.5860.94.camel@mindpipe> <44056327.7050507@rawmaterialsoftware.com> <44057A80.2040402@superbug.co.uk> <44058BE1.2030202@rawmaterialsoftware.com> <4405940D.6090409@superbug.co.uk> <440598E2.8010402@rawmaterialsoftware.com> Message-ID: <1141233961.5860.126.camel@mindpipe> On Wed, 2006-03-01 at 12:51 +0000, Julian Storer wrote: > James Courtier-Dutton wrote: > > > Julian Storer wrote: > > > >> Am I right in assuming that by default you mean the "plughw:" > >> devices? On my machine the plughw: device glitched constantly, but > >> the hw: devices worked really well. There was also some other reason > >> I chose that.. can't remember offhand what it was though. > > > > "default" means just that. use the name "default" instead of > > plughw:.... or hw:0,0 > > If the device glitched when using "plughw:" then it is a bug in ALSA > > or your application. > > How is you application deciding on sample rate? > > > There is no sensible reason to ever use the "hw:0,0" device. Always > > use the "plug:front" and friends. > > If an application only works with "hw:0,0" it has been written wrongly. > > > Ok, at the risk of "spreading the myth" that the ALSA documentation is > bad... is this stuff actually explained anywhere?? It took me a day of > googling just to find out what the two numbers after "hw" meant! I never > saw anything mention "default" or "plug:front", etc. > > Not sure if it'd be appropriate anyway, though, as my API exposes a list > of drivers and lets the user choose which one to use, and the sample > rate, rather than just using the default driver. Yes, see the links to the ALSA documentation I posted in my last message. You also could have searched the mailing list archives. Lee From ce at christeck.de Wed Mar 1 12:33:10 2006 From: ce at christeck.de (Christoph Eckert) Date: Wed Mar 1 12:33:27 2006 Subject: [linux-audio-dev] Re: Freebob-devices In-Reply-To: <440309CC.7090405@joow.be> References: <200602162006.43276.ce@christeck.de> <200602181554.07125.ce@christeck.de> <440309CC.7090405@joow.be> Message-ID: <200603011833.10809.ce@christeck.de> > Midi is currently supported through an ALSA sequencer 'client', i.e. > the freebob device acts as an ALSA sequencer client providing access > to all hardware MIDI ports. Hey, sounds cool. I really didn't expect that there's already code for the MIDI ports. Best regards ce From james at dis-dot-dat.net Wed Mar 1 12:48:30 2006 From: james at dis-dot-dat.net (james@dis-dot-dat.net) Date: Wed Mar 1 12:36:27 2006 Subject: [linux-audio-dev] [ANN] arcangel (and result of widget discussion) In-Reply-To: <1141230413.8876.7.camel@c213-100-50-8.swipnet.se> References: <20060226135333.GB8325@phlunky.Belkin> <20060301091014.GA14117@phlunky.Belkin> <1141230413.8876.7.camel@c213-100-50-8.swipnet.se> Message-ID: <20060301174830.GA21304@phlunky.Belkin> On Wed, 01 Mar, 2006 at 05:26PM +0100, Lars Luthman spake thus: > On Wed, 2006-03-01 at 09:10 +0000, james@dis-dot-dat.net wrote: > > On Tue, 28 Feb, 2006 at 10:19PM +0100, Julien Claassen spake thus: > > > Hi James! > > > Could you do a ladspa-plugin for it? > > > > OK. I just hope writing LADSPA plugins is less of a challenge than > > writing LADSPA hosts. > > It is - the whole point of a plugin system is to let the host do as much > of the plumbing as possible so the plugin writer can focus on whatever > it is that the plugin should be doing. LADSPAs still need a certain > amount of boilerplate code to work though, but you should be able to > just steal that from an existing plugin. Or you could use this library > that I use for my plugins: > > http://ll-plugins.sourceforge.net/dsl/dssi-support-libs-0.5.35.tar.gz > > It's mostly for DSSIs, but it contains a small static library that you > can link with to create LADSPA plugins as well. The code for a basic > LADSPA plugin would then look something like this: > > http://ll-plugins.sourceforge.net/dsl/0.5.35/html/classLADSPAPlugin.html#_details > > The library has not been released yet, so no backwards compatibility is > guaranteed - if you want to use it the best way may be to simply steal > ladspaplugin.hpp and ladspaplugin.cpp from the source package and > compile them with your plugin. Thanks. This actually sounds like a great idea. Fancy doing one for LADSPA hosts, too? :) Don't be offended, but I probably won't use this. I've been meaning to try writing a LADSPA plugin for a while and this is a good excuse. After the first go, I'll certainly be looking for ways to minimise effort but this time I want to see all the details. James -- "I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you." (By Vance Petree, Virginia Power) From rlrevell at joe-job.com Wed Mar 1 12:59:12 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Mar 1 12:59:21 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <440598E2.8010402@rawmaterialsoftware.com> References: <20060301035629.2144.qmail@web60712.mail.yahoo.com> <1141186434.5860.94.camel@mindpipe> <44056327.7050507@rawmaterialsoftware.com> <44057A80.2040402@superbug.co.uk> <44058BE1.2030202@rawmaterialsoftware.com> <4405940D.6090409@superbug.co.uk> <440598E2.8010402@rawmaterialsoftware.com> Message-ID: <1141235953.5860.135.camel@mindpipe> On Wed, 2006-03-01 at 12:51 +0000, Julian Storer wrote: > James Courtier-Dutton wrote: > > > Julian Storer wrote: > > > >> Am I right in assuming that by default you mean the "plughw:" > >> devices? On my machine the plughw: device glitched constantly, but > >> the hw: devices worked really well. There was also some other reason > >> I chose that.. can't remember offhand what it was though. > > > > "default" means just that. use the name "default" instead of > > plughw:.... or hw:0,0 > > If the device glitched when using "plughw:" then it is a bug in ALSA > > or your application. > > How is you application deciding on sample rate? > > > There is no sensible reason to ever use the "hw:0,0" device. Always > > use the "plug:front" and friends. > > If an application only works with "hw:0,0" it has been written wrongly. > > > Ok, at the risk of "spreading the myth" that the ALSA documentation is > bad... is this stuff actually explained anywhere?? It took me a day of > googling just to find out what the two numbers after "hw" meant! I never > saw anything mention "default" or "plug:front", etc. > > Not sure if it'd be appropriate anyway, though, as my API exposes a list > of drivers and lets the user choose which one to use, and the sample > rate, rather than just using the default driver. > Here is some information: http://www.sabi.co.uk/Notes/linuxSoundALSA.html You are right that there's not a lot of "user-level" documentation for ALSA, because it's not really intended to be used by end users - ALSA provides a complete HAL which more user friendly APIs like JACK are built on top of. You would not write a complex app in straight Xlib... The standard approach for open source development is to ask about it on one of the many mailing lists or IRC channels, rather than forging ahead on your own with only Google as your guide. Due to the proliferation of Wikis by less informed users, most of the information that Google returns is half-wrong. Lee From jules at rawmaterialsoftware.com Wed Mar 1 13:42:37 2006 From: jules at rawmaterialsoftware.com (Julian Storer) Date: Wed Mar 1 13:42:48 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <1141235953.5860.135.camel@mindpipe> References: <20060301035629.2144.qmail@web60712.mail.yahoo.com> <1141186434.5860.94.camel@mindpipe> <44056327.7050507@rawmaterialsoftware.com> <44057A80.2040402@superbug.co.uk> <44058BE1.2030202@rawmaterialsoftware.com> <4405940D.6090409@superbug.co.uk> <440598E2.8010402@rawmaterialsoftware.com> <1141235953.5860.135.camel@mindpipe> Message-ID: <4405EB1D.2030101@rawmaterialsoftware.com> Lee Revell wrote: >On Wed, 2006-03-01 at 12:51 +0000, Julian Storer wrote: > > >>James Courtier-Dutton wrote: >> >> >> >>>Julian Storer wrote: >>> >>> >>> >>>>Am I right in assuming that by default you mean the "plughw:" >>>>devices? On my machine the plughw: device glitched constantly, but >>>>the hw: devices worked really well. There was also some other reason >>>>I chose that.. can't remember offhand what it was though. >>>> >>>> >>>"default" means just that. use the name "default" instead of >>>plughw:.... or hw:0,0 >>>If the device glitched when using "plughw:" then it is a bug in ALSA >>>or your application. >>>How is you application deciding on sample rate? >>> >>> >>>There is no sensible reason to ever use the "hw:0,0" device. Always >>>use the "plug:front" and friends. >>>If an application only works with "hw:0,0" it has been written wrongly. >>> >>> >>> >>Ok, at the risk of "spreading the myth" that the ALSA documentation is >>bad... is this stuff actually explained anywhere?? It took me a day of >>googling just to find out what the two numbers after "hw" meant! I never >>saw anything mention "default" or "plug:front", etc. >> >>Not sure if it'd be appropriate anyway, though, as my API exposes a list >>of drivers and lets the user choose which one to use, and the sample >>rate, rather than just using the default driver. >> >> >> > >Here is some information: > >http://www.sabi.co.uk/Notes/linuxSoundALSA.html > >You are right that there's not a lot of "user-level" documentation for >ALSA, because it's not really intended to be used by end users - ALSA >provides a complete HAL which more user friendly APIs like JACK are >built on top of. You would not write a complex app in straight Xlib... > >The standard approach for open source development is to ask about it on >one of the many mailing lists or IRC channels, rather than forging ahead >on your own with only Google as your guide. Due to the proliferation of >Wikis by less informed users, most of the information that Google >returns is half-wrong. > >Lee > > Thanks for the link - I'd not seen that page before. I'll have another look at all this asap. From pedro.lopez.cabanillas at gmail.com Wed Mar 1 13:45:13 2006 From: pedro.lopez.cabanillas at gmail.com (Pedro Lopez-Cabanillas) Date: Wed Mar 1 13:45:23 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <20060301175922.CA5848943AD@music.columbia.edu> References: <20060301175922.CA5848943AD@music.columbia.edu> Message-ID: <200603011945.13993.pedro.lopez.cabanillas@gmail.com> On Wednesday 01 March 2006 12:51, Julian Storer wrote: > James Courtier-Dutton wrote: > > "default" means just that. use the name "default" instead of > > plughw:.... or hw:0,0 [...] > > Ok, at the risk of "spreading the myth" that the ALSA documentation is > bad... is this stuff actually explained anywhere?? It took me a day of > googling just to find out what the two numbers after "hw" meant! I never > saw anything mention "default" or "plug:front", etc. http://www.alsa-project.org/alsa-doc/alsa-lib/pcm.html#pcm_dev_names Regards, Pedro From rlrevell at joe-job.com Wed Mar 1 13:53:26 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Mar 1 13:53:34 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <4405EB1D.2030101@rawmaterialsoftware.com> References: <20060301035629.2144.qmail@web60712.mail.yahoo.com> <1141186434.5860.94.camel@mindpipe> <44056327.7050507@rawmaterialsoftware.com> <44057A80.2040402@superbug.co.uk> <44058BE1.2030202@rawmaterialsoftware.com> <4405940D.6090409@superbug.co.uk> <440598E2.8010402@rawmaterialsoftware.com> <1141235953.5860.135.camel@mindpipe> <4405EB1D.2030101@rawmaterialsoftware.com> Message-ID: <1141239207.5860.158.camel@mindpipe> On Wed, 2006-03-01 at 18:42 +0000, Julian Storer wrote: > Thanks for the link - I'd not seen that page before. I'll have another > look at all this asap. > Really, your time would be better spent getting to know JACK, or even PortAudio, than trying to get your brain around ALSA. But feel free to ask here or on alsa-devel or alsa-user at lists.sourceforge.net if you have any ALSA questions... Lee From rlrevell at joe-job.com Wed Mar 1 14:03:53 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Mar 1 14:04:01 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <200603011945.13993.pedro.lopez.cabanillas@gmail.com> References: <20060301175922.CA5848943AD@music.columbia.edu> <200603011945.13993.pedro.lopez.cabanillas@gmail.com> Message-ID: <1141239834.5860.167.camel@mindpipe> On Wed, 2006-03-01 at 19:45 +0100, Pedro Lopez-Cabanillas wrote: > On Wednesday 01 March 2006 12:51, Julian Storer wrote: > > James Courtier-Dutton wrote: > > > "default" means just that. use the name "default" instead of > > > plughw:.... or hw:0,0 > [...] > > > > Ok, at the risk of "spreading the myth" that the ALSA documentation is > > bad... is this stuff actually explained anywhere?? It took me a day of > > googling just to find out what the two numbers after "hw" meant! I never > > saw anything mention "default" or "plug:front", etc. > > http://www.alsa-project.org/alsa-doc/alsa-lib/pcm.html#pcm_dev_names Actually I think Julian has a point - I can't find the doc anywhere that says you output to the front speakers by opening the "front" device and rear the "rear" device, that apps should open the "default" PCM by default, that "hw:x" should only be used for special cases where direct hardware access is requires (like JACK), etc. We seem to just assume that people will ask on the mailing list, or look at how another app does it. All the docs I can find are targeted at someone who already knows how ALSA works but needs more detail, so most people end up thinking it's WAY more complicated just to get ALSA to produce sound than it is. There's plenty of docs at the advanced developer level but not much below that. Just as it would be pointless to improve the Xlib docs now that GTK+ and QT are available, I don't see this being fixed anytime soon, because we should be steering people towards higher level APIs anyway, and these are quite solid. Maybe we just need an ALSA mini HOWTO. Lee From cannam at all-day-breakfast.com Wed Mar 1 14:57:15 2006 From: cannam at all-day-breakfast.com (Chris Cannam) Date: Wed Mar 1 15:04:56 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <1141239834.5860.167.camel@mindpipe> References: <20060301175922.CA5848943AD@music.columbia.edu> <200603011945.13993.pedro.lopez.cabanillas@gmail.com> <1141239834.5860.167.camel@mindpipe> Message-ID: <200603011957.15166.cannam@all-day-breakfast.com> On Wednesday 01 Mar 2006 19:03, Lee Revell wrote: > Actually I think Julian has a point - I can't find the doc anywhere > that says you output to the front speakers by opening the "front" > device and rear the "rear" device, that apps should open the > "default" PCM by default, that "hw:x" should only be used for special > cases where direct hardware access is requires (like JACK), etc. Only half a dozen people in the world know these things. And here you are leaking them onto a public mailing list! Chris From jayv at synth.net Wed Mar 1 15:09:42 2006 From: jayv at synth.net (Jay Vaughan) Date: Wed Mar 1 15:09:54 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <200603011957.15166.cannam@all-day-breakfast.com> References: <20060301175922.CA5848943AD@music.columbia.edu> <200603011945.13993.pedro.lopez.cabanillas@gmail.com> <1141239834.5860.167.camel@mindpipe> <200603011957.15166.cannam@all-day-breakfast.com> Message-ID: >Only half a dozen people in the world know these things. And here you >are leaking them onto a public mailing list! its in the code, duh .. what more grok do you need? -- ; Jay Vaughan From rlrevell at joe-job.com Wed Mar 1 15:15:35 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Mar 1 15:15:41 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <200603011957.15166.cannam@all-day-breakfast.com> References: <20060301175922.CA5848943AD@music.columbia.edu> <200603011945.13993.pedro.lopez.cabanillas@gmail.com> <1141239834.5860.167.camel@mindpipe> <200603011957.15166.cannam@all-day-breakfast.com> Message-ID: <1141244136.5860.205.camel@mindpipe> On Wed, 2006-03-01 at 19:57 +0000, Chris Cannam wrote: > On Wednesday 01 Mar 2006 19:03, Lee Revell wrote: > > Actually I think Julian has a point - I can't find the doc anywhere > > that says you output to the front speakers by opening the "front" > > device and rear the "rear" device, that apps should open the > > "default" PCM by default, that "hw:x" should only be used for special > > cases where direct hardware access is requires (like JACK), etc. > > Only half a dozen people in the world know these things. And here you > are leaking them onto a public mailing list! aplay -L ... cards 'cards.pcm' front 'cards.pcm.front' rear 'cards.pcm.rear' center_lfe 'cards.pcm.center_lfe' side 'cards.pcm.side' surround40 'cards.pcm.surround40' surround41 'cards.pcm.surround41' surround50 'cards.pcm.surround50' surround51 'cards.pcm.surround51' surround71 'cards.pcm.surround71' iec958 'cards.pcm.iec958' spdif 'cards.pcm.iec958' modem 'cards.pcm.modem' phoneline 'cards.pcm.phoneline' default 'cards.pcm.default' dmix 'cards.pcm.dmix' dsnoop 'cards.pcm.dsnoop' Lee From rlrevell at joe-job.com Wed Mar 1 15:26:00 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Mar 1 15:26:10 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <1141244136.5860.205.camel@mindpipe> References: <20060301175922.CA5848943AD@music.columbia.edu> <200603011945.13993.pedro.lopez.cabanillas@gmail.com> <1141239834.5860.167.camel@mindpipe> <200603011957.15166.cannam@all-day-breakfast.com> <1141244136.5860.205.camel@mindpipe> Message-ID: <1141244761.5860.211.camel@mindpipe> On Wed, 2006-03-01 at 15:15 -0500, Lee Revell wrote: > aplay -L > > ... > cards 'cards.pcm' > front 'cards.pcm.front' > rear 'cards.pcm.rear' > center_lfe 'cards.pcm.center_lfe' > side 'cards.pcm.side' > surround40 'cards.pcm.surround40' > surround41 'cards.pcm.surround41' > surround50 'cards.pcm.surround50' > surround51 'cards.pcm.surround51' > surround71 'cards.pcm.surround71' > iec958 'cards.pcm.iec958' > spdif 'cards.pcm.iec958' > modem 'cards.pcm.modem' > phoneline 'cards.pcm.phoneline' > default 'cards.pcm.default' > dmix 'cards.pcm.dmix' > dsnoop 'cards.pcm.dsnoop' > Seriously, I do think a valid point has been raised (though the problem is not nearly as bad as "ALSA is an undocumented maze"). Besides my previous statement about use of front, rear, default PCMs, what other details might an ALSA mini HOWTO for end users cover? Please don't mention .asoundrc (should be completely invisible to the end user if everything is working right) or alsa-lib API (developer stuff is already well documented). Lee From dak at gnu.org Wed Mar 1 16:32:55 2006 From: dak at gnu.org (David Kastrup) Date: Wed Mar 1 15:33:29 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <1141244136.5860.205.camel@mindpipe> (Lee Revell's message of "Wed, 01 Mar 2006 15:15:35 -0500") References: <20060301175922.CA5848943AD@music.columbia.edu> <200603011945.13993.pedro.lopez.cabanillas@gmail.com> <1141239834.5860.167.camel@mindpipe> <200603011957.15166.cannam@all-day-breakfast.com> <1141244136.5860.205.camel@mindpipe> Message-ID: <85y7ztg8ag.fsf@lola.goethe.zz> Lee Revell writes: > On Wed, 2006-03-01 at 19:57 +0000, Chris Cannam wrote: >> On Wednesday 01 Mar 2006 19:03, Lee Revell wrote: >> > Actually I think Julian has a point - I can't find the doc anywhere >> > that says you output to the front speakers by opening the "front" >> > device and rear the "rear" device, that apps should open the >> > "default" PCM by default, that "hw:x" should only be used for special >> > cases where direct hardware access is requires (like JACK), etc. >> >> Only half a dozen people in the world know these things. And here you >> are leaking them onto a public mailing list! > > aplay -L > > ... > cards 'cards.pcm' > front 'cards.pcm.front' > rear 'cards.pcm.rear' > center_lfe 'cards.pcm.center_lfe' > side 'cards.pcm.side' > surround40 'cards.pcm.surround40' > surround41 'cards.pcm.surround41' > surround50 'cards.pcm.surround50' > surround51 'cards.pcm.surround51' > surround71 'cards.pcm.surround71' > iec958 'cards.pcm.iec958' > spdif 'cards.pcm.iec958' > modem 'cards.pcm.modem' > phoneline 'cards.pcm.phoneline' > default 'cards.pcm.default' > dmix 'cards.pcm.dmix' > dsnoop 'cards.pcm.dsnoop' It is actually more like a hoax. To wit: I have a builtin sound card into my laptop without any spdif/iec958 folderol. Now I plug in an IEC958 adapter into USB (which counts as a soundcard of its own). What happens now if I do aplay -D spdif something.wav ? Most certainly not the soundcard with the S/PDIF output gets used. Instead some nonsense happens. I have found no way whatsoever to get this card to output anything except by using Ubuntu's Sound preference setting to make the ridiculous S/PDIF only sound gadget the default sound device. Only then will I ever get aplay (which in contrast to alsamixer does not have something like a -c 1 option to specify card 1) to use the SPDIF gadget. But I don't want to use the gadget for all of my output. And I have been unable to find any man page or info or web page accessible by Google that would tell me how to do this. It is rather silly. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum From rlrevell at joe-job.com Wed Mar 1 15:50:06 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Mar 1 15:50:14 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <85y7ztg8ag.fsf@lola.goethe.zz> References: <20060301175922.CA5848943AD@music.columbia.edu> <200603011945.13993.pedro.lopez.cabanillas@gmail.com> <1141239834.5860.167.camel@mindpipe> <200603011957.15166.cannam@all-day-breakfast.com> <1141244136.5860.205.camel@mindpipe> <85y7ztg8ag.fsf@lola.goethe.zz> Message-ID: <1141246207.5860.227.camel@mindpipe> On Wed, 2006-03-01 at 22:32 +0100, David Kastrup wrote: > What happens now if I do > aplay -D spdif something.wav > ? Most certainly not the soundcard with the S/PDIF output gets used. > Instead some nonsense happens. > It will try to play to the spdif interface on card 0 (the onboard one) which will fail. aplay -D spdif:1 something.wav should DTRT. I realize this is not the most user friendly scheme (but it's certainly a step forward from "/dev/dspX") - please describe in detail what you think a user friendly interface would look like. Lee From rlrevell at joe-job.com Wed Mar 1 15:53:06 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Mar 1 15:53:14 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <85y7ztg8ag.fsf@lola.goethe.zz> References: <20060301175922.CA5848943AD@music.columbia.edu> <200603011945.13993.pedro.lopez.cabanillas@gmail.com> <1141239834.5860.167.camel@mindpipe> <200603011957.15166.cannam@all-day-breakfast.com> <1141244136.5860.205.camel@mindpipe> <85y7ztg8ag.fsf@lola.goethe.zz> Message-ID: <1141246387.5860.231.camel@mindpipe> On Wed, 2006-03-01 at 22:32 +0100, David Kastrup wrote: > What happens now if I do > aplay -D spdif something.wav > ? Most certainly not the soundcard with the S/PDIF output gets used. > Instead some nonsense happens. That can't ever work because we don't have enough information about all the supported devices to definitively say device $FOO has SPDIF and device $BAR doesn't. Lots of devices look like they have SPDIF to the driver but it's not wired up to anything. Etc. Solving this problem in the way you suggest would require the ALSA developers having all the details about the hardware that the people who write the Windows drivers do. This is not going to happen anytime soon. Lee From dak at gnu.org Wed Mar 1 17:07:17 2006 From: dak at gnu.org (David Kastrup) Date: Wed Mar 1 16:07:01 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <1141246387.5860.231.camel@mindpipe> (Lee Revell's message of "Wed, 01 Mar 2006 15:53:06 -0500") References: <20060301175922.CA5848943AD@music.columbia.edu> <200603011945.13993.pedro.lopez.cabanillas@gmail.com> <1141239834.5860.167.camel@mindpipe> <200603011957.15166.cannam@all-day-breakfast.com> <1141244136.5860.205.camel@mindpipe> <85y7ztg8ag.fsf@lola.goethe.zz> <1141246387.5860.231.camel@mindpipe> Message-ID: <85psl5g6p6.fsf@lola.goethe.zz> Lee Revell writes: > On Wed, 2006-03-01 at 22:32 +0100, David Kastrup wrote: >> What happens now if I do >> aplay -D spdif something.wav >> ? Most certainly not the soundcard with the S/PDIF output gets used. >> Instead some nonsense happens. > > That can't ever work because we don't have enough information about > all the supported devices to definitively say device $FOO has SPDIF > and device $BAR doesn't. Lots of devices look like they have SPDIF > to the driver but it's not wired up to anything. Etc. > > Solving this problem in the way you suggest would require the ALSA > developers having all the details about the hardware that the people > who write the Windows drivers do. This is not going to happen > anytime soon. I am not asking for a solution. I am asking for a clue. The man page to aplay does not mention what a PCM actually is. It just tells you to list them with -L. It does not mention that you can just tack a :1 after it to specify a different sound card. It does not bother to mention that the PCM list from -L is basically static and not depending on the actual available sound card capabilities, applies in this form only and exclusively to the default sound card, and can be used for other sound cards by tacking on little cute suffixes like :1. This sort of stuff is simply undocumented anywhere close to where it would be used. I have not been able to find it, and I asked man pages, general ALSA documentation, HOWTOs and Google. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum From rlrevell at joe-job.com Wed Mar 1 16:11:45 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Mar 1 16:11:52 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <85psl5g6p6.fsf@lola.goethe.zz> References: <20060301175922.CA5848943AD@music.columbia.edu> <200603011945.13993.pedro.lopez.cabanillas@gmail.com> <1141239834.5860.167.camel@mindpipe> <200603011957.15166.cannam@all-day-breakfast.com> <1141244136.5860.205.camel@mindpipe> <85y7ztg8ag.fsf@lola.goethe.zz> <1141246387.5860.231.camel@mindpipe> <85psl5g6p6.fsf@lola.goethe.zz> Message-ID: <1141247505.5860.236.camel@mindpipe> On Wed, 2006-03-01 at 23:07 +0100, David Kastrup wrote: > The man page > to aplay does not mention what a PCM actually is. Well the Windows docs don't say what a "Wave device" is but people seem to figure that out. PCM is merely a more technical term for what is called "Wave" on windows. What does MacOS call it? Lee From rlrevell at joe-job.com Wed Mar 1 16:15:41 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Mar 1 16:15:50 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <85psl5g6p6.fsf@lola.goethe.zz> References: <20060301175922.CA5848943AD@music.columbia.edu> <200603011945.13993.pedro.lopez.cabanillas@gmail.com> <1141239834.5860.167.camel@mindpipe> <200603011957.15166.cannam@all-day-breakfast.com> <1141244136.5860.205.camel@mindpipe> <85y7ztg8ag.fsf@lola.goethe.zz> <1141246387.5860.231.camel@mindpipe> <85psl5g6p6.fsf@lola.goethe.zz> Message-ID: <1141247741.5860.241.camel@mindpipe> On Wed, 2006-03-01 at 23:07 +0100, David Kastrup wrote: > Lee Revell writes: > > > On Wed, 2006-03-01 at 22:32 +0100, David Kastrup wrote: > >> What happens now if I do > >> aplay -D spdif something.wav > >> ? Most certainly not the soundcard with the S/PDIF output gets used. > >> Instead some nonsense happens. > > > > That can't ever work because we don't have enough information about > > all the supported devices to definitively say device $FOO has SPDIF > > and device $BAR doesn't. Lots of devices look like they have SPDIF > > to the driver but it's not wired up to anything. Etc. > > > > Solving this problem in the way you suggest would require the ALSA > > developers having all the details about the hardware that the people > > who write the Windows drivers do. This is not going to happen > > anytime soon. > > I am not asking for a solution. I am asking for a clue. The man page > to aplay does not mention what a PCM actually is. It just tells you > to list them with -L. It does not mention that you can just tack a :1 > after it to specify a different sound card. It does not bother to > mention that the PCM list from -L is basically static and not > depending on the actual available sound card capabilities, applies in > this form only and exclusively to the default sound card, and can be > used for other sound cards by tacking on little cute suffixes like :1. > > This sort of stuff is simply undocumented anywhere close to where it > would be used. I have not been able to find it, and I asked man > pages, general ALSA documentation, HOWTOs and Google. > If someone wants to set up an "ALSA mini HOWTO wiki" I'll start the content, by adding the info from this thread. But it can't stay a Wiki because those fill up with misinformation or extraneous information eventually - when it's done we'll publish it as a static HOWTO. Lee From ce at christeck.de Wed Mar 1 16:17:23 2006 From: ce at christeck.de (Christoph Eckert) Date: Wed Mar 1 16:17:29 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <1141244761.5860.211.camel@mindpipe> References: <20060301175922.CA5848943AD@music.columbia.edu> <1141244136.5860.205.camel@mindpipe> <1141244761.5860.211.camel@mindpipe> Message-ID: <200603012217.24184.ce@christeck.de> > Besides my previous statement about use of front, rear, default PCMs, > what other details might an ALSA mini HOWTO for end users cover? Freely adopted from my talk about linux audio usability at LAC 2005: ?Users dislike reading documentation and hackers dislike writing documentation. So a reasonable thing seems to be to reduce the amount of documentation needed.? See my other post. Best regards ce From dak at gnu.org Wed Mar 1 17:18:10 2006 From: dak at gnu.org (David Kastrup) Date: Wed Mar 1 16:18:01 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <1141247505.5860.236.camel@mindpipe> (Lee Revell's message of "Wed, 01 Mar 2006 16:11:45 -0500") References: <20060301175922.CA5848943AD@music.columbia.edu> <200603011945.13993.pedro.lopez.cabanillas@gmail.com> <1141239834.5860.167.camel@mindpipe> <200603011957.15166.cannam@all-day-breakfast.com> <1141244136.5860.205.camel@mindpipe> <85y7ztg8ag.fsf@lola.goethe.zz> <1141246387.5860.231.camel@mindpipe> <85psl5g6p6.fsf@lola.goethe.zz> <1141247505.5860.236.camel@mindpipe> Message-ID: <85lkvtg671.fsf@lola.goethe.zz> Lee Revell writes: > On Wed, 2006-03-01 at 23:07 +0100, David Kastrup wrote: >> The man page >> to aplay does not mention what a PCM actually is. > > Well the Windows docs don't say what a "Wave device" is but people > seem to figure that out. > > PCM is merely a more technical term for what is called "Wave" on > windows. Is that supposed to be some kind of a sick joke? We are talking about the syntax for specifying PCM devices to ALSA. People don't guess the syntax for Wave devices just all by themselves. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum From dak at gnu.org Wed Mar 1 17:21:53 2006 From: dak at gnu.org (David Kastrup) Date: Wed Mar 1 16:21:26 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <1141247741.5860.241.camel@mindpipe> (Lee Revell's message of "Wed, 01 Mar 2006 16:15:41 -0500") References: <20060301175922.CA5848943AD@music.columbia.edu> <200603011945.13993.pedro.lopez.cabanillas@gmail.com> <1141239834.5860.167.camel@mindpipe> <200603011957.15166.cannam@all-day-breakfast.com> <1141244136.5860.205.camel@mindpipe> <85y7ztg8ag.fsf@lola.goethe.zz> <1141246387.5860.231.camel@mindpipe> <85psl5g6p6.fsf@lola.goethe.zz> <1141247741.5860.241.camel@mindpipe> Message-ID: <85hd6hg60u.fsf@lola.goethe.zz> Lee Revell writes: > On Wed, 2006-03-01 at 23:07 +0100, David Kastrup wrote: >> Lee Revell writes: >> >> > On Wed, 2006-03-01 at 22:32 +0100, David Kastrup wrote: >> >> What happens now if I do >> >> aplay -D spdif something.wav >> >> ? Most certainly not the soundcard with the S/PDIF output gets used. >> >> Instead some nonsense happens. >> > >> > That can't ever work because we don't have enough information about >> > all the supported devices to definitively say device $FOO has SPDIF >> > and device $BAR doesn't. Lots of devices look like they have SPDIF >> > to the driver but it's not wired up to anything. Etc. >> > >> > Solving this problem in the way you suggest would require the ALSA >> > developers having all the details about the hardware that the people >> > who write the Windows drivers do. This is not going to happen >> > anytime soon. >> >> I am not asking for a solution. I am asking for a clue. The man page >> to aplay does not mention what a PCM actually is. It just tells you >> to list them with -L. It does not mention that you can just tack a :1 >> after it to specify a different sound card. It does not bother to >> mention that the PCM list from -L is basically static and not >> depending on the actual available sound card capabilities, applies in >> this form only and exclusively to the default sound card, and can be >> used for other sound cards by tacking on little cute suffixes like :1. >> >> This sort of stuff is simply undocumented anywhere close to where it >> would be used. I have not been able to find it, and I asked man >> pages, general ALSA documentation, HOWTOs and Google. >> > > If someone wants to set up an "ALSA mini HOWTO wiki" I'll start the > content, by adding the info from this thread. But it can't stay a Wiki > because those fill up with misinformation or extraneous information > eventually - when it's done we'll publish it as a static HOWTO. It belongs in the example sections of the man pages, at the very least. Using some PCM of a secondary sound card is important enough to be used as an example for _all_ ALSA-related commands. If it is not there in every man page, at least a clear reference to some man page where it is is required. HOWTOs are supposed to be hands-on extracts of the full documentation. They are not supposed to replace documentation, but give recipes and outlines that make it easier to work with the normal documentation. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum From rlrevell at joe-job.com Wed Mar 1 16:27:32 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Mar 1 16:27:44 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <85hd6hg60u.fsf@lola.goethe.zz> References: <20060301175922.CA5848943AD@music.columbia.edu> <200603011945.13993.pedro.lopez.cabanillas@gmail.com> <1141239834.5860.167.camel@mindpipe> <200603011957.15166.cannam@all-day-breakfast.com> <1141244136.5860.205.camel@mindpipe> <85y7ztg8ag.fsf@lola.goethe.zz> <1141246387.5860.231.camel@mindpipe> <85psl5g6p6.fsf@lola.goethe.zz> <1141247741.5860.241.camel@mindpipe> <85hd6hg60u.fsf@lola.goethe.zz> Message-ID: <1141248453.5860.244.camel@mindpipe> On Wed, 2006-03-01 at 23:21 +0100, David Kastrup wrote: > > HOWTOs are supposed to be hands-on extracts of the full documentation. > They are not supposed to replace documentation, but give recipes and > outlines that make it easier to work with the normal documentation. > Well, tough shit, because all I have time for is a mini HOWTO, unless you're offering to pay me. Lee From drobilla at connect.carleton.ca Wed Mar 1 16:29:48 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Wed Mar 1 16:29:54 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <1141201346.440559c272cad@www2.helsinki.fi> References: <1141201346.440559c272cad@www2.helsinki.fi> Message-ID: <1141248588.2414.6.camel@localhost.localdomain> On Wed, 2006-01-03 at 10:22 +0200, Sampo Savolainen wrote: > Alas, ALSA. It's very unfortunate that you chose ALSA as the API for Linux. > For me, applications without jack support are of zero interest. ++ -DR- From rlrevell at joe-job.com Wed Mar 1 16:37:16 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Mar 1 16:37:23 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <1141248588.2414.6.camel@localhost.localdomain> References: <1141201346.440559c272cad@www2.helsinki.fi> <1141248588.2414.6.camel@localhost.localdomain> Message-ID: <1141249037.5860.249.camel@mindpipe> On Wed, 2006-03-01 at 16:29 -0500, Dave Robillard wrote: > On Wed, 2006-01-03 at 10:22 +0200, Sampo Savolainen wrote: > > Alas, ALSA. It's very unfortunate that you chose ALSA as the API for Linux. > > For me, applications without jack support are of zero interest. > > ++ Don't be too discouraging! If it already supported callback based APIs like ASIO (or ALSA, optionally) it might be very easy to port. Lee From dak at gnu.org Wed Mar 1 17:40:16 2006 From: dak at gnu.org (David Kastrup) Date: Wed Mar 1 16:39:48 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <1141248453.5860.244.camel@mindpipe> (Lee Revell's message of "Wed, 01 Mar 2006 16:27:32 -0500") References: <20060301175922.CA5848943AD@music.columbia.edu> <200603011945.13993.pedro.lopez.cabanillas@gmail.com> <1141239834.5860.167.camel@mindpipe> <200603011957.15166.cannam@all-day-breakfast.com> <1141244136.5860.205.camel@mindpipe> <85y7ztg8ag.fsf@lola.goethe.zz> <1141246387.5860.231.camel@mindpipe> <85psl5g6p6.fsf@lola.goethe.zz> <1141247741.5860.241.camel@mindpipe> <85hd6hg60u.fsf@lola.goethe.zz> <1141248453.5860.244.camel@mindpipe> Message-ID: <854q2hg567.fsf@lola.goethe.zz> Lee Revell writes: > On Wed, 2006-03-01 at 23:21 +0100, David Kastrup wrote: >> >> HOWTOs are supposed to be hands-on extracts of the full documentation. >> They are not supposed to replace documentation, but give recipes and >> outlines that make it easier to work with the normal documentation. >> > > Well, tough shit, because all I have time for is a mini HOWTO, unless > you're offering to pay me. It takes less time to add 2 example lines into the man pages than to answer complaints on the list. And it does more for your user base than fixing a dozen bugs. I happen to be project leader for AUCTeX and preview-latex, and can tell you from that position that shaving time off basics from the standard documentation of the standard commands is not going to improve your total time balance. It will always be more efficient to answer once for thousands of people than to answer a dozen times for a dozen people even if hundreds just give up without a peep. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum From ce at christeck.de Wed Mar 1 16:48:06 2006 From: ce at christeck.de (Christoph Eckert) Date: Wed Mar 1 16:48:19 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <1141246207.5860.227.camel@mindpipe> References: <20060301175922.CA5848943AD@music.columbia.edu> <85y7ztg8ag.fsf@lola.goethe.zz> <1141246207.5860.227.camel@mindpipe> Message-ID: <200603012248.06568.ce@christeck.de> > please describe in detail what you > think a user friendly interface would look like. There are several issues at different points: * alsaconf has done a really great job in the past, but meanwhile I see the need for a replacement which can handle more than one card, support USB (and in the future firewire) devices, can read an existing configuration, set a certain device as the default device and so on. Based on such a new script, we then could build even GUI configuration frontends (Qt, Gtk, KDE, you name it) * ALSA aware applications need to offer the possibility to choose the card to use. Many users have more than one device these days, a cheap AC '97 one and a cool 7.1 USB device. When playing a video file, there should be a possibility to tell the player which device to use. On tour with my notebook I prefer to output audio of a DVD mixed as stereo on my internal speakers while at home or at a friend's I'll better use my USB device * Applications should remember the last used device (not to mention soundservers here) so the user gets a straightforward experience ("I once set it up and since then it simply works(TM)") * Users need a simple GUI to set the default (=most often used) device, maybe renaming the cards, configuring special options easily (asoundrc resp. special options in modules.conf like card ordering) * ALSA runs a driver based on the chipset found. Unfortunately, and I mainly have those AC '97 chips in mind, these have a huge set of features a user never needs or even worse which are not available on the chassis. But ALSA cannot know that because it only knows the chip. Furthermore ALSA builds a generic mixer interface for the chip. That's a really cool piece of software, but have you ever tried on a notebook with an AC '97 chipset to set up your card for VOIP properly? An average user will be lost. Therefore I had the idea to put an additional layer between ALSA and the mixer interface so users can contribute mixer descriptions for wide spread cards. If such an desription doesn't exist, ALSA could still fall back to the generic mixer interface Just my two Cents. Best regards ce From rlrevell at joe-job.com Wed Mar 1 16:49:26 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Mar 1 16:49:35 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <854q2hg567.fsf@lola.goethe.zz> References: <20060301175922.CA5848943AD@music.columbia.edu> <200603011945.13993.pedro.lopez.cabanillas@gmail.com> <1141239834.5860.167.camel@mindpipe> <200603011957.15166.cannam@all-day-breakfast.com> <1141244136.5860.205.camel@mindpipe> <85y7ztg8ag.fsf@lola.goethe.zz> <1141246387.5860.231.camel@mindpipe> <85psl5g6p6.fsf@lola.goethe.zz> <1141247741.5860.241.camel@mindpipe> <85hd6hg60u.fsf@lola.goethe.zz> <1141248453.5860.244.camel@mindpipe> <854q2hg567.fsf@lola.goethe.zz> Message-ID: <1141249767.5860.253.camel@mindpipe> On Wed, 2006-03-01 at 23:40 +0100, David Kastrup wrote: > Lee Revell writes: > > > On Wed, 2006-03-01 at 23:21 +0100, David Kastrup wrote: > >> > >> HOWTOs are supposed to be hands-on extracts of the full documentation. > >> They are not supposed to replace documentation, but give recipes and > >> outlines that make it easier to work with the normal documentation. > >> > > > > Well, tough shit, because all I have time for is a mini HOWTO, unless > > you're offering to pay me. > > It takes less time to add 2 example lines into the man pages than to > answer complaints on the list. > > And it does more for your user base than fixing a dozen bugs. > > I happen to be project leader for AUCTeX and preview-latex, and can > tell you from that position that shaving time off basics from the > standard documentation of the standard commands is not going to > improve your total time balance. It will always be more efficient to > answer once for thousands of people than to answer a dozen times for a > dozen people even if hundreds just give up without a peep. > Well, I didn't develop ALSA originally, I've just contributed patches to a few drivers. You'd have to ask the authors on alsa-devel about the lack of better examples in the man pages. Most users will never have to bother with this stuff - the app will just give them a dialog that lets them select a sound device. Also, a lot of CLI apps don't accept ALSA devices in the standard syntax because they reserve : for something else (mplayer comes to mind). Lee From ce at christeck.de Wed Mar 1 16:55:17 2006 From: ce at christeck.de (Christoph Eckert) Date: Wed Mar 1 16:55:25 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <1141247741.5860.241.camel@mindpipe> References: <20060301175922.CA5848943AD@music.columbia.edu> <85psl5g6p6.fsf@lola.goethe.zz> <1141247741.5860.241.camel@mindpipe> Message-ID: <200603012255.17719.ce@christeck.de> > If someone wants to set up an "ALSA mini HOWTO wiki" I'll start the > content, by adding the info from this thread. a condensation would be really cool. What about http://alsa.opensrc.org ? Best regards ce From ce at christeck.de Wed Mar 1 16:56:58 2006 From: ce at christeck.de (Christoph Eckert) Date: Wed Mar 1 16:57:05 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <1141249767.5860.253.camel@mindpipe> References: <20060301175922.CA5848943AD@music.columbia.edu> <854q2hg567.fsf@lola.goethe.zz> <1141249767.5860.253.camel@mindpipe> Message-ID: <200603012256.59058.ce@christeck.de> > Also, a lot of CLI apps don't accept ALSA devices in the standard > syntax because they reserve : for something else (mplayer comes to > mind). at least it offers the -ao option. Best regards ce From rlrevell at joe-job.com Wed Mar 1 17:04:38 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Mar 1 17:04:44 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <200603012248.06568.ce@christeck.de> References: <20060301175922.CA5848943AD@music.columbia.edu> <85y7ztg8ag.fsf@lola.goethe.zz> <1141246207.5860.227.camel@mindpipe> <200603012248.06568.ce@christeck.de> Message-ID: <1141250678.5860.257.camel@mindpipe> On Wed, 2006-03-01 at 22:48 +0100, Christoph Eckert wrote: > > please describe in detail what you > > think a user friendly interface would look like. > > There are several issues at different points: > > * alsaconf has done a really great job in the past, but meanwhile I see > the need for a replacement which can handle more than one card, support > USB (and in the future firewire) devices, can read an existing > configuration, set a certain device as the default device and so on. > Based on such a new script, we then could build even GUI configuration > frontends (Qt, Gtk, KDE, you name it) Much of this is already done - Gnome provides both a GUI and CLI interface to set the default soundcard, System->Preferences->Sound. It's unfortunate that many apps don't have a way to configure the sound device they use. Lee From dak at gnu.org Wed Mar 1 18:09:37 2006 From: dak at gnu.org (David Kastrup) Date: Wed Mar 1 17:09:14 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <1141246207.5860.227.camel@mindpipe> (Lee Revell's message of "Wed, 01 Mar 2006 15:50:06 -0500") References: <20060301175922.CA5848943AD@music.columbia.edu> <200603011945.13993.pedro.lopez.cabanillas@gmail.com> <1141239834.5860.167.camel@mindpipe> <200603011957.15166.cannam@all-day-breakfast.com> <1141244136.5860.205.camel@mindpipe> <85y7ztg8ag.fsf@lola.goethe.zz> <1141246207.5860.227.camel@mindpipe> Message-ID: <85zmk9ep8u.fsf@lola.goethe.zz> Lee Revell writes: > On Wed, 2006-03-01 at 22:32 +0100, David Kastrup wrote: >> What happens now if I do >> aplay -D spdif something.wav >> ? Most certainly not the soundcard with the S/PDIF output gets used. >> Instead some nonsense happens. >> > > It will try to play to the spdif interface on card 0 (the onboard one) > which will fail. > > aplay -D spdif:1 something.wav should DTRT. aplay -D spdif:1 -f cdr /tmp/mnt/wo1.dat ALSA lib confmisc.c:990:(snd_func_refer) Unable to find definition 'cards.USB-Audio.pcm.iec958.0:CARD=1,AES0=4,AES1=130,AES2=0,AES3=2' ALSA lib conf.c:3479:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory ALSA lib conf.c:3948:(snd_config_expand) Evaluate error: No such file or directory ALSA lib pcm.c:2090:(snd_pcm_open_noupdate) Unknown PCM spdif:1 aplay: main:533: audio open error: No such file or directory -- David Kastrup, Kriemhildstr. 15, 44793 Bochum From ce at christeck.de Wed Mar 1 17:13:49 2006 From: ce at christeck.de (Christoph Eckert) Date: Wed Mar 1 17:13:55 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <1141250678.5860.257.camel@mindpipe> References: <20060301175922.CA5848943AD@music.columbia.edu> <200603012248.06568.ce@christeck.de> <1141250678.5860.257.camel@mindpipe> Message-ID: <200603012313.49781.ce@christeck.de> > Much of this is already done - Gnome provides both a GUI and CLI > interface to set the default soundcard, System->Preferences->Sound. is there a backend script available, distro independant? I'd like to look at it simply for my personal interest. Does it have a name? > It's unfortunate that many apps don't have a way to configure the > sound device they use. Indeed it is. OTOH xmms is a very positive example. Best regards ce From paul at linuxaudiosystems.com Wed Mar 1 17:18:20 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Wed Mar 1 17:15:09 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <85zmk9ep8u.fsf@lola.goethe.zz> References: <20060301175922.CA5848943AD@music.columbia.edu> <200603011945.13993.pedro.lopez.cabanillas@gmail.com> <1141239834.5860.167.camel@mindpipe> <200603011957.15166.cannam@all-day-breakfast.com> <1141244136.5860.205.camel@mindpipe> <85y7ztg8ag.fsf@lola.goethe.zz> <1141246207.5860.227.camel@mindpipe> <85zmk9ep8u.fsf@lola.goethe.zz> Message-ID: <1141251500.2432.176.camel@localhost.localdomain> On Thu, 2006-03-02 at 00:09 +0100, David Kastrup wrote: > Lee Revell writes: > > > On Wed, 2006-03-01 at 22:32 +0100, David Kastrup wrote: > >> What happens now if I do > >> aplay -D spdif something.wav > >> ? Most certainly not the soundcard with the S/PDIF output gets used. > >> Instead some nonsense happens. > >> > > > > It will try to play to the spdif interface on card 0 (the onboard one) > > which will fail. > > > > aplay -D spdif:1 something.wav should DTRT. > > aplay -D spdif:1 -f cdr /tmp/mnt/wo1.dat > ALSA lib confmisc.c:990:(snd_func_refer) Unable to find definition 'cards.USB-Audio.pcm.iec958.0:CARD=1,AES0=4,AES1=130,AES2=0,AES3=2' > ALSA lib conf.c:3479:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:3948:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib pcm.c:2090:(snd_pcm_open_noupdate) Unknown PCM spdif:1 > aplay: main:533: audio open error: No such file or directory now that's what i call a sick joke. if only i had more time, i'd be writing CoreAudio for linux right this very second. --p From rlrevell at joe-job.com Wed Mar 1 17:21:15 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Mar 1 17:21:22 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <85zmk9ep8u.fsf@lola.goethe.zz> References: <20060301175922.CA5848943AD@music.columbia.edu> <200603011945.13993.pedro.lopez.cabanillas@gmail.com> <1141239834.5860.167.camel@mindpipe> <200603011957.15166.cannam@all-day-breakfast.com> <1141244136.5860.205.camel@mindpipe> <85y7ztg8ag.fsf@lola.goethe.zz> <1141246207.5860.227.camel@mindpipe> <85zmk9ep8u.fsf@lola.goethe.zz> Message-ID: <1141251676.5860.264.camel@mindpipe> On Thu, 2006-03-02 at 00:09 +0100, David Kastrup wrote: > Lee Revell writes: > > > On Wed, 2006-03-01 at 22:32 +0100, David Kastrup wrote: > >> What happens now if I do > >> aplay -D spdif something.wav > >> ? Most certainly not the soundcard with the S/PDIF output gets used. > >> Instead some nonsense happens. > >> > > > > It will try to play to the spdif interface on card 0 (the onboard one) > > which will fail. > > > > aplay -D spdif:1 something.wav should DTRT. > > aplay -D spdif:1 -f cdr /tmp/mnt/wo1.dat > ALSA lib confmisc.c:990:(snd_func_refer) Unable to find definition 'cards.USB-Audio.pcm.iec958.0:CARD=1,AES0=4,AES1=130,AES2=0,AES3=2' > ALSA lib conf.c:3479:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:3948:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib pcm.c:2090:(snd_pcm_open_noupdate) Unknown PCM spdif:1 > aplay: main:533: audio open error: No such file or directory > > I think this is just a bug. Can you repost this report to alsa-user at lists.sourceforge.net or report it in the ALSA bug tracker? https://bugtrack.alsa-project.org/alsa-bug/login_select_proj_page.php?ref=bug_report_advanced_page.php Lee From dak at gnu.org Wed Mar 1 18:25:28 2006 From: dak at gnu.org (David Kastrup) Date: Wed Mar 1 17:25:20 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <1141251676.5860.264.camel@mindpipe> (Lee Revell's message of "Wed, 01 Mar 2006 17:21:15 -0500") References: <20060301175922.CA5848943AD@music.columbia.edu> <200603011945.13993.pedro.lopez.cabanillas@gmail.com> <1141239834.5860.167.camel@mindpipe> <200603011957.15166.cannam@all-day-breakfast.com> <1141244136.5860.205.camel@mindpipe> <85y7ztg8ag.fsf@lola.goethe.zz> <1141246207.5860.227.camel@mindpipe> <85zmk9ep8u.fsf@lola.goethe.zz> <1141251676.5860.264.camel@mindpipe> Message-ID: <85oe0peoif.fsf@lola.goethe.zz> Lee Revell writes: > On Thu, 2006-03-02 at 00:09 +0100, David Kastrup wrote: >> Lee Revell writes: >> >> > On Wed, 2006-03-01 at 22:32 +0100, David Kastrup wrote: >> >> What happens now if I do >> >> aplay -D spdif something.wav >> >> ? Most certainly not the soundcard with the S/PDIF output gets used. >> >> Instead some nonsense happens. >> >> >> > >> > It will try to play to the spdif interface on card 0 (the onboard one) >> > which will fail. >> > >> > aplay -D spdif:1 something.wav should DTRT. >> >> aplay -D spdif:1 -f cdr /tmp/mnt/wo1.dat >> ALSA lib confmisc.c:990:(snd_func_refer) Unable to find definition 'cards.USB-Audio.pcm.iec958.0:CARD=1,AES0=4,AES1=130,AES2=0,AES3=2' >> ALSA lib conf.c:3479:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory >> ALSA lib conf.c:3948:(snd_config_expand) Evaluate error: No such file or directory >> ALSA lib pcm.c:2090:(snd_pcm_open_noupdate) Unknown PCM spdif:1 >> aplay: main:533: audio open error: No such file or directory > > I think this is just a bug. Can you repost this report to alsa-user > at lists.sourceforge.net or report it in the ALSA bug tracker? I can't report something as a bug as long as I have no clue whatsoever what the appropriate syntax and expected behavior could be. There certainly is nothing in the documentation saying that "-D spdif:1" could be expected to do anything sensible. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum From rlrevell at joe-job.com Wed Mar 1 17:28:28 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Mar 1 17:28:36 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <1141251500.2432.176.camel@localhost.localdomain> References: <20060301175922.CA5848943AD@music.columbia.edu> <200603011945.13993.pedro.lopez.cabanillas@gmail.com> <1141239834.5860.167.camel@mindpipe> <200603011957.15166.cannam@all-day-breakfast.com> <1141244136.5860.205.camel@mindpipe> <85y7ztg8ag.fsf@lola.goethe.zz> <1141246207.5860.227.camel@mindpipe> <85zmk9ep8u.fsf@lola.goethe.zz> <1141251500.2432.176.camel@localhost.localdomain> Message-ID: <1141252109.5860.269.camel@mindpipe> On Wed, 2006-03-01 at 17:18 -0500, Paul Davis wrote: > now that's what i call a sick joke. > > if only i had more time, i'd be writing CoreAudio for linux right this > very second. Which would magically make 5 zillion different sound devices on the market that you don't have the specs to or even a hardware sample Just Work? Lee From rlrevell at joe-job.com Wed Mar 1 17:35:55 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Mar 1 17:36:10 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <85oe0peoif.fsf@lola.goethe.zz> References: <20060301175922.CA5848943AD@music.columbia.edu> <200603011945.13993.pedro.lopez.cabanillas@gmail.com> <1141239834.5860.167.camel@mindpipe> <200603011957.15166.cannam@all-day-breakfast.com> <1141244136.5860.205.camel@mindpipe> <85y7ztg8ag.fsf@lola.goethe.zz> <1141246207.5860.227.camel@mindpipe> <85zmk9ep8u.fsf@lola.goethe.zz> <1141251676.5860.264.camel@mindpipe> <85oe0peoif.fsf@lola.goethe.zz> Message-ID: <1141252556.5860.272.camel@mindpipe> On Thu, 2006-03-02 at 00:25 +0100, David Kastrup wrote: > I can't report something as a bug as long as I have no clue whatsoever > what the appropriate syntax and expected behavior could be. > > There certainly is nothing in the documentation saying that > "-D spdif:1" could be expected to do anything sensible. What about -D hw:1 or -D plughw:1? USB audio devices are weird, it's much harder to determine sane defaults than for PCI devices. Lee From paul at linuxaudiosystems.com Wed Mar 1 21:40:11 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Wed Mar 1 21:37:00 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <1141252109.5860.269.camel@mindpipe> References: <20060301175922.CA5848943AD@music.columbia.edu> <200603011945.13993.pedro.lopez.cabanillas@gmail.com> <1141239834.5860.167.camel@mindpipe> <200603011957.15166.cannam@all-day-breakfast.com> <1141244136.5860.205.camel@mindpipe> <85y7ztg8ag.fsf@lola.goethe.zz> <1141246207.5860.227.camel@mindpipe> <85zmk9ep8u.fsf@lola.goethe.zz> <1141251500.2432.176.camel@localhost.localdomain> <1141252109.5860.269.camel@mindpipe> Message-ID: <1141267211.8789.16.camel@localhost.localdomain> On Wed, 2006-03-01 at 17:28 -0500, Lee Revell wrote: > On Wed, 2006-03-01 at 17:18 -0500, Paul Davis wrote: > > now that's what i call a sick joke. > > > > if only i had more time, i'd be writing CoreAudio for linux right this > > very second. > > Which would magically make 5 zillion different sound devices on the > market that you don't have the specs to or even a hardware sample Just > Work? no, it would provide names like MOTU 828 mkII channel 1+2 RME HDSP (#1) Builtin Audio to the user. it would also fix a myriad of other problems in ALSA, such as its reliance on interrupts that occur at regular sample-based intervals, its presentation of a multiplicity of programming models, and its lack of reasonable way to present itself to ordinary users. --p From drobilla at connect.carleton.ca Wed Mar 1 23:38:09 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Wed Mar 1 23:38:18 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <1141251500.2432.176.camel@localhost.localdomain> References: <20060301175922.CA5848943AD@music.columbia.edu> <200603011945.13993.pedro.lopez.cabanillas@gmail.com> <1141239834.5860.167.camel@mindpipe> <200603011957.15166.cannam@all-day-breakfast.com> <1141244136.5860.205.camel@mindpipe> <85y7ztg8ag.fsf@lola.goethe.zz> <1141246207.5860.227.camel@mindpipe> <85zmk9ep8u.fsf@lola.goethe.zz> <1141251500.2432.176.camel@localhost.localdomain> Message-ID: <1141274289.2414.15.camel@localhost.localdomain> On Wed, 2006-01-03 at 17:18 -0500, Paul Davis wrote: > On Thu, 2006-03-02 at 00:09 +0100, David Kastrup wrote: > > Lee Revell writes: > > > > > On Wed, 2006-03-01 at 22:32 +0100, David Kastrup wrote: > > >> What happens now if I do > > >> aplay -D spdif something.wav > > >> ? Most certainly not the soundcard with the S/PDIF output gets used. > > >> Instead some nonsense happens. > > >> > > > > > > It will try to play to the spdif interface on card 0 (the onboard one) > > > which will fail. > > > > > > aplay -D spdif:1 something.wav should DTRT. > > > > aplay -D spdif:1 -f cdr /tmp/mnt/wo1.dat > > ALSA lib confmisc.c:990:(snd_func_refer) Unable to find definition 'cards.USB-Audio.pcm.iec958.0:CARD=1,AES0=4,AES1=130,AES2=0,AES3=2' > > ALSA lib conf.c:3479:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > > ALSA lib conf.c:3948:(snd_config_expand) Evaluate error: No such file or directory > > ALSA lib pcm.c:2090:(snd_pcm_open_noupdate) Unknown PCM spdif:1 > > aplay: main:533: audio open error: No such file or directory > > now that's what i call a sick joke. > > if only i had more time, i'd be writing CoreAudio for linux right this > very second. 1) Eliminate alsa-lib 2) Put jackd in kernel 3) Profit! -DR- From capocasa at gmx.net Thu Mar 2 01:51:52 2006 From: capocasa at gmx.net (Carlo Capocasa) Date: Thu Mar 2 01:52:36 2006 Subject: [linux-audio-dev] Shelljam: Help Wanted! Message-ID: Hi, I'm Carlo and I started out Shelljam to provide a way of using any standard computer hardware as an input device to make music with. Uses like altering sounds with joysticks or simply playing chords on keyboards are examples really great uses that come to mind, but there is no inherent limitation. Currently, the most important things that need to be done with Shelljam are SCHED_FIFO realtime implementation and possibly threading implementation (I suspect the threading gains would only start to get visible when a large number of devices are used at once). Personally I would like to minimize my time spent coding and maximize my time spent producing music, although I have a fairly deep insight into C++ and I can work closely with you to produce a Free Software application that has the potential to create a whole movement of young and/or open minded people to enrich our Free Music landscape by reducing the entry cost to produce extremely good-sounding music. Please contact me at capocasa :-:-:AT:-.-.- gmx :--DOT-.-.- Net if you're at all interested! Carlo From dak at gnu.org Wed Mar 1 19:07:55 2006 From: dak at gnu.org (David Kastrup) Date: Thu Mar 2 02:28:04 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <1141252556.5860.272.camel@mindpipe> (Lee Revell's message of "Wed, 01 Mar 2006 17:35:55 -0500") References: <20060301175922.CA5848943AD@music.columbia.edu> <200603011945.13993.pedro.lopez.cabanillas@gmail.com> <1141239834.5860.167.camel@mindpipe> <200603011957.15166.cannam@all-day-breakfast.com> <1141244136.5860.205.camel@mindpipe> <85y7ztg8ag.fsf@lola.goethe.zz> <1141246207.5860.227.camel@mindpipe> <85zmk9ep8u.fsf@lola.goethe.zz> <1141251676.5860.264.camel@mindpipe> <85oe0peoif.fsf@lola.goethe.zz> <1141252556.5860.272.camel@mindpipe> Message-ID: <854q2h1zfo.fsf@lola.goethe.zz> Lee Revell writes: > On Thu, 2006-03-02 at 00:25 +0100, David Kastrup wrote: >> I can't report something as a bug as long as I have no clue whatsoever >> what the appropriate syntax and expected behavior could be. >> >> There certainly is nothing in the documentation saying that >> "-D spdif:1" could be expected to do anything sensible. > > What about -D hw:1 or -D plughw:1? USB audio devices are weird, it's > much harder to determine sane defaults than for PCI devices. $ aplay -D hw:1 -f cdr /tmp/mnt/wo1.dat Playing raw data '/tmp/mnt/wo1.dat' : Signed 16 bit Big Endian, Rate 44100 Hz, Stereo aplay: set_params:882: Sample format non available $ aplay -D plughw:1 -f cdr /tmp/mnt/wo1.dat Playing raw data '/tmp/mnt/wo1.dat' : Signed 16 bit Big Endian, Rate 44100 Hz, Stereo Works apparently. Not that I have a clue where I could find out the difference between plughw and just hw ... So now I just need to find out how to set index marks when recording to the minidisc player, so as not to get one big track, and not having to manually press the "track mark" command on the minidisc player after each track. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum From wingo at pobox.com Thu Mar 2 04:58:15 2006 From: wingo at pobox.com (Andy Wingo) Date: Thu Mar 2 04:58:56 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <1141250678.5860.257.camel@mindpipe> References: <20060301175922.CA5848943AD@music.columbia.edu> <85y7ztg8ag.fsf@lola.goethe.zz> <1141246207.5860.227.camel@mindpipe> <200603012248.06568.ce@christeck.de> <1141250678.5860.257.camel@mindpipe> Message-ID: <1141293495.24219.74.camel@localhost.localdomain> Hi, On Wed, 2006-03-01 at 17:04 -0500, Lee Revell wrote: > On Wed, 2006-03-01 at 22:48 +0100, Christoph Eckert wrote: > > * alsaconf has done a really great job in the past, but meanwhile I see > > the need for a replacement which can handle more than one card, support > > USB (and in the future firewire) devices, can read an existing > > configuration, set a certain device as the default device and so on. > > Based on such a new script, we then could build even GUI configuration > > frontends (Qt, Gtk, KDE, you name it) > > Much of this is already done - Gnome provides both a GUI and CLI > interface to set the default soundcard, System->Preferences->Sound. (That still mentions ESD, but we all have our closet-skeletons eh.) I wanted to write in to mention this bug report, http://bugzilla.gnome.org/show_bug.cgi?id=329106: It's currently not possible to specify one specific ALSA device in a pipeline such that the same pipeline is guaranteed to work across machine reboots. The problem is that ALSA card numbers are generated on each system startup. The result depends on the random order of which kernel module gets loaded first. When hotplugging USB audio devices, the card number changes may even happen without machine reboots. I propose to use HAL's UDI (Unique Device Id) as persistent ALSA sound device identifier. A patch to make HAL's UDI independent of ALSA's card number has already been committed to HAL CVS HEAD. So, using HAL is a way to reliably choose a particular harware device; arguably ALSA should handle this case itself though. Regards, -- Andy Wingo http://wingolog.org/ From fons.adriaensen at alcatelaleniaspace.com Thu Mar 2 07:43:25 2006 From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen) Date: Thu Mar 2 07:43:40 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <85psl5g6p6.fsf@lola.goethe.zz> References: <20060301175922.CA5848943AD@music.columbia.edu> <200603011945.13993.pedro.lopez.cabanillas@gmail.com> <1141239834.5860.167.camel@mindpipe> <200603011957.15166.cannam@all-day-breakfast.com> <1141244136.5860.205.camel@mindpipe> <85y7ztg8ag.fsf@lola.goethe.zz> <1141246387.5860.231.camel@mindpipe> <85psl5g6p6.fsf@lola.goethe.zz> Message-ID: <20060302124325.GA5538@bth05w.ABSp.alcatel.be> On Wed, Mar 01, 2006 at 11:07:17PM +0100, David Kastrup wrote: > I am not asking for a solution. I am asking for a clue. The man page > to aplay does not mention what a PCM actually is. It just tells you > to list them with -L. This is my main gripe with ALSA documentation: it often uses terms and concepts that are defined nowhere. The english terms used for some concepts can be hard to decode as well. This is a real problem with e.g. the doxygen pages for the pcm and seq APIs. -- FA From James at superbug.co.uk Thu Mar 2 07:49:52 2006 From: James at superbug.co.uk (James Courtier-Dutton) Date: Thu Mar 2 07:50:20 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <1141251500.2432.176.camel@localhost.localdomain> References: <20060301175922.CA5848943AD@music.columbia.edu> <200603011945.13993.pedro.lopez.cabanillas@gmail.com> <1141239834.5860.167.camel@mindpipe> <200603011957.15166.cannam@all-day-breakfast.com> <1141244136.5860.205.camel@mindpipe> <85y7ztg8ag.fsf@lola.goethe.zz> <1141246207.5860.227.camel@mindpipe> <85zmk9ep8u.fsf@lola.goethe.zz> <1141251500.2432.176.camel@localhost.localdomain> Message-ID: <4406E9F0.5000300@superbug.co.uk> Paul Davis wrote: >> aplay -D spdif:1 -f cdr /tmp/mnt/wo1.dat >> ALSA lib confmisc.c:990:(snd_func_refer) Unable to find definition 'cards.USB-Audio.pcm.iec958.0:CARD=1,AES0=4,AES1=130,AES2=0,AES3=2' >> ALSA lib conf.c:3479:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory >> ALSA lib conf.c:3948:(snd_config_expand) Evaluate error: No such file or directory >> ALSA lib pcm.c:2090:(snd_pcm_open_noupdate) Unknown PCM spdif:1 >> aplay: main:533: audio open error: No such file or directory >> > > now that's what i call a sick joke. > > if only i had more time, i'd be writing CoreAudio for linux right this > very second. > > --p > > I don't think spdif works properly on any USB devices currently. This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. From James at superbug.co.uk Thu Mar 2 07:57:11 2006 From: James at superbug.co.uk (James Courtier-Dutton) Date: Thu Mar 2 07:57:31 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <1141267211.8789.16.camel@localhost.localdomain> References: <20060301175922.CA5848943AD@music.columbia.edu> <200603011945.13993.pedro.lopez.cabanillas@gmail.com> <1141239834.5860.167.camel@mindpipe> <200603011957.15166.cannam@all-day-breakfast.com> <1141244136.5860.205.camel@mindpipe> <85y7ztg8ag.fsf@lola.goethe.zz> <1141246207.5860.227.camel@mindpipe> <85zmk9ep8u.fsf@lola.goethe.zz> <1141251500.2432.176.camel@localhost.localdomain> <1141252109.5860.269.camel@mindpipe> <1141267211.8789.16.camel@localhost.localdomain> Message-ID: <4406EBA7.5030206@superbug.co.uk> Paul Davis wrote: > On Wed, 2006-03-01 at 17:28 -0500, Lee Revell wrote: > >> On Wed, 2006-03-01 at 17:18 -0500, Paul Davis wrote: >> >>> now that's what i call a sick joke. >>> >>> if only i had more time, i'd be writing CoreAudio for linux right this >>> very second. >>> >> Which would magically make 5 zillion different sound devices on the >> market that you don't have the specs to or even a hardware sample Just >> Work? >> > > no, it would provide names like > > MOTU 828 mkII channel 1+2 > RME HDSP (#1) > Builtin Audio > > to the user. > > it would also fix a myriad of other problems in ALSA, such as its > reliance on interrupts that occur at regular sample-based intervals, > Can you suggest alternatives? > its presentation of a multiplicity of programming models, and its > There is no one-size-fits-all with sound programming models. > lack of reasonable way to present itself to ordinary users. > > --p > > What is wrong with the current presentation? You currently get the name of the card. This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. From James at superbug.co.uk Thu Mar 2 07:59:12 2006 From: James at superbug.co.uk (James Courtier-Dutton) Date: Thu Mar 2 08:00:31 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <20060302124325.GA5538@bth05w.ABSp.alcatel.be> References: <20060301175922.CA5848943AD@music.columbia.edu> <200603011945.13993.pedro.lopez.cabanillas@gmail.com> <1141239834.5860.167.camel@mindpipe> <200603011957.15166.cannam@all-day-breakfast.com> <1141244136.5860.205.camel@mindpipe> <85y7ztg8ag.fsf@lola.goethe.zz> <1141246387.5860.231.camel@mindpipe> <85psl5g6p6.fsf@lola.goethe.zz> <20060302124325.GA5538@bth05w.ABSp.alcatel.be> Message-ID: <4406EC20.3080100@superbug.co.uk> Alfons Adriaensen wrote: > On Wed, Mar 01, 2006 at 11:07:17PM +0100, David Kastrup wrote: > > >> I am not asking for a solution. I am asking for a clue. The man page >> to aplay does not mention what a PCM actually is. It just tells you >> to list them with -L. >> > > This is my main gripe with ALSA documentation: it often uses terms > and concepts that are defined nowhere. The english terms used for > some concepts can be hard to decode as well. This is a real problem > with e.g. the doxygen pages for the pcm and seq APIs. > If you don't like the current documentation, you are welcome to improve it. Just update the wiki. This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. From fons.adriaensen at alcatelaleniaspace.com Thu Mar 2 08:43:29 2006 From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen) Date: Thu Mar 2 08:43:36 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <4406EC20.3080100@superbug.co.uk> References: <20060301175922.CA5848943AD@music.columbia.edu> <200603011945.13993.pedro.lopez.cabanillas@gmail.com> <1141239834.5860.167.camel@mindpipe> <200603011957.15166.cannam@all-day-breakfast.com> <1141244136.5860.205.camel@mindpipe> <85y7ztg8ag.fsf@lola.goethe.zz> <1141246387.5860.231.camel@mindpipe> <85psl5g6p6.fsf@lola.goethe.zz> <20060302124325.GA5538@bth05w.ABSp.alcatel.be> <4406EC20.3080100@superbug.co.uk> Message-ID: <20060302134329.GB5538@bth05w.ABSp.alcatel.be> On Thu, Mar 02, 2006 at 12:59:12PM +0000, James Courtier-Dutton wrote: > If you don't like the current documentation, you are welcome to improve it. > Just update the wiki. I'd be happy to, if only I could just be a bit more confident about my own knowledge. Currently I'm really in no position to contribute anything that I'd consider to be reliable information. When you have to find out things by guessing and trial and error, and finally arrive at something that works, your understanding of the underlying concepts could be completely wrong. I hate to say this, but that's how the MIDI interface in Aeolus was written. The ALSA audio part (libclalsadrv) was based 100% on a deconstruction of JACK's ALSA backend. Just one simple example (from the top of my head, so it may contain inaccuracies). In the ALSA seq world, ports can be readable, writeable, and those two attributes also have variants referred to by the term 'subscription'. I found out you need these, as otherwise your ports don't seem to exist at all. So what does this term really mean ? As far as my understanding goes, its real meaning is more something like 'public' or 'visible'. But I'm just guessing... Also, an app can create any number of ALSA seq 'devices' and each 'device' can have multiple 'ports'. What is the rationale behind this two-level scheme ? When would I prefer to use N single port devices rather that one device with N ports ? This sort of thing is never explained, AFAICS. I'm pretty sure all these things (and many other that remain a mystery) are well designed and the result of considerable amount of thinking and consideration. But I don't find it in the documentation. This is often the case with doxygen documented systems - the top level design documents just don't exist. -- FA From paul at linuxaudiosystems.com Thu Mar 2 09:17:34 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Thu Mar 2 09:14:22 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <4406EBA7.5030206@superbug.co.uk> References: <20060301175922.CA5848943AD@music.columbia.edu> <200603011945.13993.pedro.lopez.cabanillas@gmail.com> <1141239834.5860.167.camel@mindpipe> <200603011957.15166.cannam@all-day-breakfast.com> <1141244136.5860.205.camel@mindpipe> <85y7ztg8ag.fsf@lola.goethe.zz> <1141246207.5860.227.camel@mindpipe> <85zmk9ep8u.fsf@lola.goethe.zz> <1141251500.2432.176.camel@localhost.localdomain> <1141252109.5860.269.camel@mindpipe> <1141267211.8789.16.camel@localhost.localdomain> <4406EBA7.5030206@superbug.co.uk> Message-ID: <1141309054.8789.33.camel@localhost.localdomain> > > no, it would provide names like > > > > MOTU 828 mkII channel 1+2 > > RME HDSP (#1) > > Builtin Audio > > > > to the user. > > > > it would also fix a myriad of other problems in ALSA, such as its > > reliance on interrupts that occur at regular sample-based intervals, > > > Can you suggest alternatives? i don't need to - they are fully documented by Apple in its description of the HAL for audio devices. Rather than rely on the interrupts as absolute indicators of time, you use them to feed a DLL. Then you use the DLL in conjunction with a monotonic clock source (e.g. a cycle timer or a reliable equivalent on certain AMD systems), and you can estimate position in the h/w buffers to way better than single sample accuracy at all times. more importantly, you can do this no matter what the basis for the interrupt frequency is, so you get a single HAL model that works equally well for PCI, USB and ieee1394 devices. > > its presentation of a multiplicity of programming models, and its > > > There is no one-size-fits-all with sound programming models. Apple don't agree with you, and neither do Steinberg or Microsoft (the modern, reformed post-MME Microsoft, anyway). They each offer a single programming model at the HAL level, and remarkably, its the same programming model in every case. I don't see forums for those platforms complaining that its a problem. Only unix programmers who go about insisting that "everything should be a file, all i/o should be open/read/write/close/ioctl" seem to have a problem with it, yet curiously have no problem with the fact that you don't do video in that way at all. > > lack of reasonable way to present itself to ordinary users. > > > > --p > > > > > What is wrong with the current presentation? > You currently get the name of the card. i meant more generally. ALSA is so full of configuration options that will be used by almost no-one that its incredibly confusing for almost everyone. i wrote years ago on alsa-devel about the paper from the guy at SGI who was involved in their video API design and ended up being a little disappointed. his reason? they went to so effort to handle all the corner cases that the core use case ("dump pixels into this part of the framebuffer") was remarkably complex to do. ALSA strikes me as much the same way, at every level, from the kernel API, to libasound, to user space utilities. one could argue, as Lee has done, that people (programmers, users) should be using higher level APIs and leave the complexity behind, but somebody or something has to deal with it at some point in order to get sound in or out of the machine. --p From jussi.laako at pp.inet.fi Thu Mar 2 13:27:35 2006 From: jussi.laako at pp.inet.fi (Jussi Laako) Date: Thu Mar 2 13:28:09 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <1141309054.8789.33.camel@localhost.localdomain> References: <20060301175922.CA5848943AD@music.columbia.edu> <200603011945.13993.pedro.lopez.cabanillas@gmail.com> <1141239834.5860.167.camel@mindpipe> <200603011957.15166.cannam@all-day-breakfast.com> <1141244136.5860.205.camel@mindpipe> <85y7ztg8ag.fsf@lola.goethe.zz> <1141246207.5860.227.camel@mindpipe> <85zmk9ep8u.fsf@lola.goethe.zz> <1141251500.2432.176.camel@localhost.localdomain> <1141252109.5860.269.camel@mindpipe> <1141267211.8789.16.camel@localhost.localdomain> <4406EBA7.5030206@superbug.co.uk> <1141309054.8789.33.camel@localhost.localdomain> Message-ID: <1141324055.12890.3.camel@vaarlahti.uworld> On Thu, 2006-03-02 at 09:17 -0500, Paul Davis wrote: > the framebuffer") was remarkably complex to do. ALSA strikes me as much > the same way, at every level, from the kernel API, to libasound, to user > space utilities. > one could argue, as Lee has done, that people (programmers, users) > should be using higher level APIs and leave the complexity behind, but > somebody or something has to deal with it at some point in order to get > sound in or out of the machine. I somehow find this a bit funny. OSS has been dealing with these things at driver level and hiding the complexity pretty well. And it also works for pro cards like my Delta1010. First it was argued that there wasn't enough control and ALSA was better. Now ALSA has taken this to the other extreme and now we are arguing if it's too complex. Truth is probably somewhere between, as usual... -- Jussi Laako From dak at gnu.org Thu Mar 2 14:02:23 2006 From: dak at gnu.org (David Kastrup) Date: Thu Mar 2 14:02:29 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <1141324055.12890.3.camel@vaarlahti.uworld> (Jussi Laako's message of "Thu, 02 Mar 2006 20:27:35 +0200") References: <20060301175922.CA5848943AD@music.columbia.edu> <200603011945.13993.pedro.lopez.cabanillas@gmail.com> <1141239834.5860.167.camel@mindpipe> <200603011957.15166.cannam@all-day-breakfast.com> <1141244136.5860.205.camel@mindpipe> <85y7ztg8ag.fsf@lola.goethe.zz> <1141246207.5860.227.camel@mindpipe> <85zmk9ep8u.fsf@lola.goethe.zz> <1141251500.2432.176.camel@localhost.localdomain> <1141252109.5860.269.camel@mindpipe> <1141267211.8789.16.camel@localhost.localdomain> <4406EBA7.5030206@superbug.co.uk> <1141309054.8789.33.camel@localhost.localdomain> <1141324055.12890.3.camel@vaarlahti.uworld> Message-ID: <853bi0vfeo.fsf@lola.goethe.zz> Jussi Laako writes: > I somehow find this a bit funny. OSS has been dealing with these > things at driver level and hiding the complexity pretty well. And it > also works for pro cards like my Delta1010. First it was argued that > there wasn't enough control and ALSA was better. Now ALSA has taken > this to the other extreme and now we are arguing if it's too > complex. No, that's not what we are arguing, at least how I understood it. The topic was not complexity but accessibility. If it is impossible to find explanations, stuff is hard to do. A well-documented crummy interface can be easier to work with than an under-documented well-designed one. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum From richard.spindler at gmail.com Thu Mar 2 18:26:49 2006 From: richard.spindler at gmail.com (Richard Spindler) Date: Thu Mar 2 18:26:57 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <853bi0vfeo.fsf@lola.goethe.zz> References: <20060301175922.CA5848943AD@music.columbia.edu> <1141246207.5860.227.camel@mindpipe> <85zmk9ep8u.fsf@lola.goethe.zz> <1141251500.2432.176.camel@localhost.localdomain> <1141252109.5860.269.camel@mindpipe> <1141267211.8789.16.camel@localhost.localdomain> <4406EBA7.5030206@superbug.co.uk> <1141309054.8789.33.camel@localhost.localdomain> <1141324055.12890.3.camel@vaarlahti.uworld> <853bi0vfeo.fsf@lola.goethe.zz> Message-ID: <4af8d6ff0603021526v177b8994g@mail.gmail.com> 2006/3/2, David Kastrup : > No, that's not what we are arguing, at least how I understood it. The > topic was not complexity but accessibility. If it is impossible to > find explanations, stuff is hard to do. A well-documented crummy > interface can be easier to work with than an under-documented > well-designed one. I am not that sure about this one. To understand a well designed simple API a glimpse at the headers ought to be enough documentation. -Richard From dak at gnu.org Thu Mar 2 18:30:52 2006 From: dak at gnu.org (David Kastrup) Date: Thu Mar 2 18:32:10 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <4af8d6ff0603021526v177b8994g@mail.gmail.com> (Richard Spindler's message of "Fri, 3 Mar 2006 00:26:49 +0100") References: <20060301175922.CA5848943AD@music.columbia.edu> <1141246207.5860.227.camel@mindpipe> <85zmk9ep8u.fsf@lola.goethe.zz> <1141251500.2432.176.camel@localhost.localdomain> <1141252109.5860.269.camel@mindpipe> <1141267211.8789.16.camel@localhost.localdomain> <4406EBA7.5030206@superbug.co.uk> <1141309054.8789.33.camel@localhost.localdomain> <1141324055.12890.3.camel@vaarlahti.uworld> <853bi0vfeo.fsf@lola.goethe.zz> <4af8d6ff0603021526v177b8994g@mail.gmail.com> Message-ID: <857j7ctoer.fsf@lola.goethe.zz> "Richard Spindler" writes: > 2006/3/2, David Kastrup : >> No, that's not what we are arguing, at least how I understood it. The >> topic was not complexity but accessibility. If it is impossible to >> find explanations, stuff is hard to do. A well-documented crummy >> interface can be easier to work with than an under-documented >> well-designed one. > > I am not that sure about this one. To understand a well designed > simple API a glimpse at the headers ought to be enough > documentation. Few people would glimpse at header files in order to figure out the command line arguments to "aplay". -- David Kastrup, Kriemhildstr. 15, 44793 Bochum From rlrevell at joe-job.com Thu Mar 2 20:38:45 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Thu Mar 2 20:38:54 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <1141267211.8789.16.camel@localhost.localdomain> References: <20060301175922.CA5848943AD@music.columbia.edu> <200603011945.13993.pedro.lopez.cabanillas@gmail.com> <1141239834.5860.167.camel@mindpipe> <200603011957.15166.cannam@all-day-breakfast.com> <1141244136.5860.205.camel@mindpipe> <85y7ztg8ag.fsf@lola.goethe.zz> <1141246207.5860.227.camel@mindpipe> <85zmk9ep8u.fsf@lola.goethe.zz> <1141251500.2432.176.camel@localhost.localdomain> <1141252109.5860.269.camel@mindpipe> <1141267211.8789.16.camel@localhost.localdomain> Message-ID: <1141349926.3042.59.camel@mindpipe> On Wed, 2006-03-01 at 21:40 -0500, Paul Davis wrote: > its presentation of a multiplicity of programming models How would you solve this? Make people who insist on a read()/write() interface go through the OSS emulation layer? Would you remove everything but the mmap() interface? The callback interface? Lee From david at olofson.net Fri Mar 3 02:16:46 2006 From: david at olofson.net (David Olofson) Date: Fri Mar 3 02:23:58 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <1141349926.3042.59.camel@mindpipe> References: <20060301175922.CA5848943AD@music.columbia.edu> <1141267211.8789.16.camel@localhost.localdomain> <1141349926.3042.59.camel@mindpipe> Message-ID: <200603030816.46526.david@olofson.net> On Friday 03 March 2006 02:38, Lee Revell wrote: > On Wed, 2006-03-01 at 21:40 -0500, Paul Davis wrote: > > its presentation of a multiplicity of programming models > > How would you solve this? Make people who insist on a > read()/write() > interface go through the OSS emulation layer? Would you remove > everything but the mmap() interface? The callback interface? Well, there is a reason why all "serious" audio APIs use the callback model. It's the only model that really works for low latency audio. If you want to do serious real time audio, you'll have to get your head around this model anyway. (You need to keep the CPU load steady, and generating N samples every cycle rather than larger blocks "every now and then" is the first step.) If you're not doing real time stuff, you can wrap any API with whatever type of API you like, as the buffering that is sometimes required, won't matter. Indeed, there are some "latency reduction" tricks you can play with an mmap() interface, but those are inefficient, messy hacks that you are (or rather, were) forced to use to get usable latency in games on some platforms. Not really usable for musical applications, and the method doesn't fit well into engines with master effects and the like. Callbacks on a proper OS are simpler, more reliable and more efficient. A read()/write() interface is basically just a (more or less) buffered wrapper over a real interface. I frankly don't understand why one would want to use something like it for anything remotely resembling real time audio I/O. All it does is confuse matters WRT how much buffering you actually have, especially when you're doing full duplex audio. It may be handy in non real time applications (sometimes it's easier to let the algorithm control the block sizes), but as those aren't sensitive to additional buffering, you can just wrap the real API with whatever you like. No reason to break or complicate the real API to support that. //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 richard.spindler at gmail.com Fri Mar 3 04:05:10 2006 From: richard.spindler at gmail.com (Richard Spindler) Date: Fri Mar 3 04:05:16 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <857j7ctoer.fsf@lola.goethe.zz> References: <20060301175922.CA5848943AD@music.columbia.edu> <1141251500.2432.176.camel@localhost.localdomain> <1141252109.5860.269.camel@mindpipe> <1141267211.8789.16.camel@localhost.localdomain> <4406EBA7.5030206@superbug.co.uk> <1141309054.8789.33.camel@localhost.localdomain> <1141324055.12890.3.camel@vaarlahti.uworld> <853bi0vfeo.fsf@lola.goethe.zz> <4af8d6ff0603021526v177b8994g@mail.gmail.com> <857j7ctoer.fsf@lola.goethe.zz> Message-ID: <4af8d6ff0603030105t65c9d69eo@mail.gmail.com> 2006/3/3, David Kastrup : > > I am not that sure about this one. To understand a well designed > > simple API a glimpse at the headers ought to be enough > > documentation. > > Few people would glimpse at header files in order to figure out the > command line arguments to "aplay". Well, I referred to programming interfaces, and not to "user" interfaces. -Richard From capocasa at gmx.net Fri Mar 3 08:28:23 2006 From: capocasa at gmx.net (Carlo Capocasa) Date: Fri Mar 3 08:29:14 2006 Subject: [linux-audio-dev] zthreads realtime Message-ID: Hi there! Does anyone have any experience with zthreads for linux realtime audio software? Carlo From garton at columbia.edu Fri Mar 3 11:12:04 2006 From: garton at columbia.edu (Bradford Garton) Date: Fri Mar 3 11:12:09 2006 Subject: [linux-audio-dev] stuff I've done Message-ID: Hey everyone -- Sorry about the multiple postings, but I figured what the heck... I've just put on-line a whole lot of work I've done; papers, pieces, software, etc. Here's the link for the 2-3 people (beyond my immediate family) who might be interested: http://music.columbia.edu/~brad/ There's a fair amount of unix/linux work scattered throughout, including the big "My Music Book" thing I did a few years ago. Hope you enjoy this! brad From capocasa at gmx.net Fri Mar 3 12:04:36 2006 From: capocasa at gmx.net (Carlo Capocasa) Date: Fri Mar 3 12:06:00 2006 Subject: [linux-audio-dev] Re: stuff I've done In-Reply-To: References: Message-ID: Thanks tons for sharing... You've got a wonderful taste for art, Bradford. Carlo From nettings at folkwang-hochschule.de Fri Mar 3 12:43:15 2006 From: nettings at folkwang-hochschule.de (Joern Nettingsmeier) Date: Fri Mar 3 12:43:54 2006 Subject: [linux-audio-dev] [admin] reminder: no html postings on linux-audio-* Message-ID: <44088033.6070007@folkwang-hochschule.de> hi everyone! just a quick heads-up: html postings or other "enriched" atrocities are banned on linux-audio-*. unfortunately, the mailman response "message has a suspicious header" is less than helpful. if you see your postings bounce with this error, in 99 of 100 cases you are trying to send either html or binary attachments. this warning applies especially to our friends at gmail.com / googlemail.com. their web interface seems to send out dodgy mails by default. best, j?rn -- j?rn nettingsmeier home://germany/45128 essen/lortzingstr. 11/ http://spunk.dnsalias.org phone://+49/201/491621 if you are a free (as in "free speech") software developer and you happen to be travelling near my home, drop me a line and come round for a free (as in "free beer") beer. :-D From fbar at footils.org Fri Mar 3 13:13:02 2006 From: fbar at footils.org (Frank Barknecht) Date: Fri Mar 3 13:19:26 2006 Subject: [linux-audio-dev] stuff I've done In-Reply-To: References: Message-ID: <20060303181302.GS27812@fliwatut.scifi> Hallo, Bradford Garton hat gesagt: // Bradford Garton wrote: > I've just put on-line a whole lot of work I've done; papers, pieces, > software, etc. Here's the link for the 2-3 people (beyond my immediate > family) who might be interested: > > http://music.columbia.edu/~brad/ > > There's a fair amount of unix/linux work scattered throughout, including > the big "My Music Book" thing I did a few years ago. > > Hope you enjoy this! Omygod, I do!! I am Dying ;) Thanks a lot. Ciao -- Frank Barknecht _ ______footils.org_ __goto10.org__ From ce at christeck.de Fri Mar 3 14:09:29 2006 From: ce at christeck.de (Christoph Eckert) Date: Fri Mar 3 14:09:28 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <1141293495.24219.74.camel@localhost.localdomain> References: <20060301175922.CA5848943AD@music.columbia.edu> <1141250678.5860.257.camel@mindpipe> <1141293495.24219.74.camel@localhost.localdomain> Message-ID: <200603032009.29509.ce@christeck.de> > ? ? ? ? It's currently not possible to specify one specific ALSA > device in a pipeline such that the same pipeline is guaranteed to > work across machine reboots. The problem is that ALSA card numbers > are generated on each system startup. The result depends on the > random order of which kernel module gets loaded first. When > hotplugging USB audio devices, the card number changes may even > happen without machine reboots. what about indexing the cards in modules.conf? Works great for me even when hotplugging USB devices (and I use 5 of them ;-) Best regards ce From rlrevell at joe-job.com Fri Mar 3 14:19:13 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Fri Mar 3 14:19:38 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <200603032009.29509.ce@christeck.de> References: <20060301175922.CA5848943AD@music.columbia.edu> <1141250678.5860.257.camel@mindpipe> <1141293495.24219.74.camel@localhost.localdomain> <200603032009.29509.ce@christeck.de> Message-ID: <1141413554.3042.125.camel@mindpipe> On Fri, 2006-03-03 at 20:09 +0100, Christoph Eckert wrote: > > It's currently not possible to specify one specific ALSA > > device in a pipeline such that the same pipeline is guaranteed to > > work across machine reboots. The problem is that ALSA card numbers > > are generated on each system startup. The result depends on the > > random order of which kernel module gets loaded first. When > > hotplugging USB audio devices, the card number changes may even > > happen without machine reboots. > > what about indexing the cards in modules.conf? Works great for me even > when hotplugging USB devices (and I use 5 of them ;-) And normal users should never have to touch that file. In Gnome, just do System->Preferences->Sound and select the "Default sound card". Lee From ce at christeck.de Fri Mar 3 15:05:56 2006 From: ce at christeck.de (Christoph Eckert) Date: Fri Mar 3 15:06:00 2006 Subject: [linux-audio-dev] Juce now has ALSA support! In-Reply-To: <1141413554.3042.125.camel@mindpipe> References: <20060301175922.CA5848943AD@music.columbia.edu> <200603032009.29509.ce@christeck.de> <1141413554.3042.125.camel@mindpipe> Message-ID: <200603032105.57019.ce@christeck.de> > > what about indexing the cards in modules.conf? Works great for me > > even when hotplugging USB devices (and I use 5 of them ;-) > > And normal users should never have to touch that file. true. > In Gnome, > just do System->Preferences->Sound and select the "Default sound > card". What does it do technically spoken? Creates a user asoundrc with a default device? Best regards ce From j4strngs at bitless.net Fri Mar 3 16:10:28 2006 From: j4strngs at bitless.net (John Check) Date: Fri Mar 3 16:10:37 2006 Subject: [linux-audio-dev] stuff I've done In-Reply-To: References: Message-ID: <200603031610.28780.j4strngs@bitless.net> On Friday 03 March 2006 11:12 am, Bradford Garton wrote: > Hey everyone -- > > Sorry about the multiple postings, but I figured what the heck... > > I've just put on-line a whole lot of work I've done; papers, pieces, > software, etc. Here's the link for the 2-3 people (beyond my immediate > family) who might be interested: > > http://music.columbia.edu/~brad/ > > There's a fair amount of unix/linux work scattered throughout, including > the big "My Music Book" thing I did a few years ago. > > Hope you enjoy this! > > brad Guns That's some good stuff right there :) Have fun watching your server logs. Mmm reloads From terakuma at imbris.net Fri Mar 3 18:13:59 2006 From: terakuma at imbris.net (Maluvia) Date: Fri Mar 3 18:14:19 2006 Subject: [linux-audio-dev] Re: stuff I've done In-Reply-To: <20060303211040.25BA3911EF5@music.columbia.edu> References: <20060303211040.25BA3911EF5@music.columbia.edu> Message-ID: <200603031513590530.0213DCE1@mail.imbris.net> Wow - that's quite a backlog of work. The software looks fascinating - and the bush-o-matic is priceless! Loved the personal stuff - you have a beautiful family. Thanks for sharing, Brad. :) - Maluvia >Hey everyone -- > >Sorry about the multiple postings, but I figured what the heck... > >I've just put on-line a whole lot of work I've done; papers, pieces, >software, etc. Here's the link for the 2-3 people (beyond my immediate >family) who might be interested: >There's a fair amount of unix/linux work scattered throughout, including >the big "My Music Book" thing I did a few years ago. > >Hope you enjoy this! From dancer at netfort.gr.jp Sat Mar 4 08:36:28 2006 From: dancer at netfort.gr.jp (Junichi Uekawa) Date: Sat Mar 4 08:36:32 2006 Subject: [linux-audio-dev] Shelljam: Help Wanted! In-Reply-To: References: Message-ID: <87y7zqs55v.dancerj%dancer@netfort.gr.jp> Hi, > I'm Carlo and I started out Shelljam to provide a way of using any > standard computer hardware as an input device to make music with. Uses > like altering sounds with joysticks or simply playing chords on > keyboards are examples really great uses that come to mind, but there is > no inherent limitation. I might be missing something but is there something that shelljam does that vkeybd cannot do? regards, junichi -- dancer@{debian.org,netfort.gr.jp} Debian Project From andres at geminiflux.com Sat Mar 4 13:17:00 2006 From: andres at geminiflux.com (Andres Cabrera) Date: Sat Mar 4 13:17:52 2006 Subject: [linux-audio-dev] [ANN] Snd-ls V0.9.5.4 and Das_Watchdog V0.2.1 In-Reply-To: References: Message-ID: <1141496233.3953.33.camel@dynamic-ip-6979141196.cable.net.co> Hi Kjetil, Thanks very much, your package is very useful. I just wanted to let you know that compilation and installation worked fine, but when running snd-ls the lrdf.h header was required to enable ladspa plugins. No problem, but you may want to check for it on your configure script. Thanks again, Andr?s On Mon, 2006-02-27 at 14:05 -0800, Kjetil S. Matheussen wrote: > Download from http://ccrma.stanford.edu/~kjetil/src/ > > > Snd-ls v0.9.5.4 > ================ > > Contains > -------- > Snd v7.15 from 17.8.2005 > > About > ----- > Snd-ls is a distribution of the sound editor Snd. Its target is > people that don't know scheme very well, and don't want > to spend too much time configuring Snd. It can also serve > as a quick introduction to Snd and how it can be set up. > > Changes 0.9.5.3 -> 0.9.5.4 > -------------------------- > -Changed default resampling quality to SRC_SINC_BEST_QUALITY > -Added workaround for shift-handling across various keyboard settings. > (shortcuts for zoom in and undo works with american keyboards now.) > -Added check for Guile 1.8. Snd-ls crashes with guile 1.8. > (all versions I have tried of 1.7 seems to work though...) > -Use JackPortIsPhysical instead of "alsa_pcm" when finding jack ports. > -Updated the rt stuff to latest versions. > > > > *************************************** > *************************************** > > > > Das_Watchdog V0.2.1 > =================== > > About > ----- > Das_Watchdog is a general watchdog for the linux operating system that > should be runned in the background at all times to ensure a realtime > process won't hang the machine. > > Changes 0.2.0->0.2.1 > -------------------- > *Cleaned up source a bit. > *Properly find number of timer processes. > *Added shortcuts for optargs. > > > > > 0 From rlrevell at joe-job.com Sat Mar 4 17:06:49 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Sat Mar 4 17:06:54 2006 Subject: [linux-audio-dev] Re: Karlsruhe In-Reply-To: References: <1141011491.24141.267.camel@mindpipe> Message-ID: <1141510009.14714.14.camel@mindpipe> On Mon, 2006-02-27 at 17:30 +1100, Loki Davison wrote: > www.bahn.de is probably the best getting around tip anyone can give > you. Where can I find a decent map of Germany? The whole country is blank on Google Maps... Lee From ce at christeck.de Sat Mar 4 17:12:50 2006 From: ce at christeck.de (Christoph Eckert) Date: Sat Mar 4 17:12:52 2006 Subject: [linux-audio-dev] Re: Karlsruhe In-Reply-To: <1141510009.14714.14.camel@mindpipe> References: <1141011491.24141.267.camel@mindpipe> <1141510009.14714.14.camel@mindpipe> Message-ID: <200603042312.51226.ce@christeck.de> > Where can I find a decent map of Germany? ?The whole country is blank > on Google Maps... unfortunately it's still blank, yes. Depoending what you're looking for, you can try http://www.demis.nl/wms/mapclip.htm Best regards ce From fons.adriaensen at skynet.be Sat Mar 4 17:24:27 2006 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Sat Mar 4 17:17:47 2006 Subject: [linux-audio-dev] Re: Karlsruhe In-Reply-To: <1141510009.14714.14.camel@mindpipe> References: <1141011491.24141.267.camel@mindpipe> <1141510009.14714.14.camel@mindpipe> Message-ID: <20060304222427.GA10172@linux-1> On Sat, Mar 04, 2006 at 05:06:49PM -0500, Lee Revell wrote: > Where can I find a decent map of Germany? The whole country is blank on > Google Maps... Try http://www.de.map24.com/ -- FA From forums at machinehasnoagenda.com Sat Mar 4 23:09:27 2006 From: forums at machinehasnoagenda.com (Mr Machine) Date: Sat Mar 4 23:09:38 2006 Subject: [linux-audio-dev] Errors trying to build dssi-vst 0.4 ... any help? In-Reply-To: <200603011317.30260.cannam@all-day-breakfast.com> References: <200603011317.30260.cannam@all-day-breakfast.com> Message-ID: <1141531767.2901.3.camel@machine> hi, i've been waiting for some help on building dssi-vst 0.4 (recently released), but thought i'd ask around some more ... On Wed, 2006-03-01 at 13:17 +0000, Chris Cannam wrote: > dssi-vst: a DSSI plugin wrapper for Win32 VST plugins > ===================================================== > > dssi-vst 0.4 is now available. > > The main change since the 0.3.1 release is that dssi-vst now builds with newer > versions of the Wine tools. Wine 0.9.5 or newer is now required. > > This release also builds with version 2.4 of the VST SDK, although it should > still work with the older 2.3 as well. > > Download it from: > http://sourceforge.net/project/showfiles.php?group_id=104230&package_id=127571 > > You will also need the VST SDK, from: > http://www.steinberg.de/Steinberg/Developers8b99.html > > More information about DSSI: > http://dssi.sourceforge.net/ > oh, i've been waiting for this ... thanks for updating to be compatible with latest Wine!!! unfortunately, i get errors when trying to build: [mrmachine@machine dssi-vst-0.4]# make g++ -I./vstsdk2.4/pluginterfaces/vst2.x -Wall remotepluginclient.cpp -c g++ -I./vstsdk2.4/pluginterfaces/vst2.x -Wall remotepluginserver.cpp -c g++ -I./vstsdk2.4/pluginterfaces/vst2.x -Wall -c -o rdwrops.o rdwrops.cpp g++ -I./vstsdk2.4/pluginterfaces/vst2.x -Wall -c -o paths.o paths.cpp ar r libremoteplugin.a remotepluginclient.o remotepluginserver.o rdwrops.o paths.o ar: creating libremoteplugin.a wineg++ -I./vstsdk2.4/pluginterfaces/vst2.x -Wall dssi-vst-server.cpp -o dssi-vst-server -L. -lremoteplugin dssi-vst-server.cpp: In member function ?virtual void RemoteVSTServer::hideGUI()?: dssi-vst-server.cpp:566: warning: unused variable ?fd? dssi-vst-server-5Pa9Gf.o(.text+0x147e): In function `RemoteVSTServer::process(float**, float**)': dssi-vst-server.cpp: undefined reference to `pthread_mutex_trylock' collect2: ld returned 1 exit status winegcc: g++ failed. make: *** [dssi-vst-server.exe.so] Error 2 i'm using a CCRMA-enabled Fedora Core 4. shayne From rlrevell at joe-job.com Sat Mar 4 23:14:36 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Sat Mar 4 23:14:43 2006 Subject: [linux-audio-dev] Errors trying to build dssi-vst 0.4 ... any help? In-Reply-To: <1141531767.2901.3.camel@machine> References: <200603011317.30260.cannam@all-day-breakfast.com> <1141531767.2901.3.camel@machine> Message-ID: <1141532077.14714.45.camel@mindpipe> On Sun, 2006-03-05 at 15:09 +1100, Mr Machine wrote: > dssi-vst-server-5Pa9Gf.o(.text+0x147e): In function > `RemoteVSTServer::process(float**, float**)': > dssi-vst-server.cpp: undefined reference to `pthread_mutex_trylock' > collect2: ld returned 1 exit status Do you have glibc-devel or libc6-devel or libpthreads-devel or whatever installed? This is a basic POSIX threading function that should be available in any sane development environment... Lee From forums at machinehasnoagenda.com Sat Mar 4 23:51:04 2006 From: forums at machinehasnoagenda.com (Mr Machine) Date: Sat Mar 4 23:51:13 2006 Subject: [linux-audio-dev] Errors trying to build dssi-vst 0.4 ... any help? In-Reply-To: <1141532077.14714.45.camel@mindpipe> References: <200603011317.30260.cannam@all-day-breakfast.com> <1141531767.2901.3.camel@machine> <1141532077.14714.45.camel@mindpipe> Message-ID: <1141534265.3280.4.camel@machine> On Sat, 2006-03-04 at 23:14 -0500, Lee Revell wrote: > On Sun, 2006-03-05 at 15:09 +1100, Mr Machine wrote: > > dssi-vst-server-5Pa9Gf.o(.text+0x147e): In function > > `RemoteVSTServer::process(float**, float**)': > > dssi-vst-server.cpp: undefined reference to `pthread_mutex_trylock' > > collect2: ld returned 1 exit status > > Do you have glibc-devel or libc6-devel or libpthreads-devel or whatever > installed? This is a basic POSIX threading function that should be > available in any sane development environment... i have the glibc-devel package: glibc-devel-2.3.5-10.3 would this mean that it is not finding it? i'm pretty sure my PKG_CONFIG_PATH is set correctly, though. i don't have any of those other packages installed, but i'm guessing they're the same thing as glibc-devel, but only for different distributions (i'm using FC4)? shayne From rlrevell at joe-job.com Sat Mar 4 23:58:37 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Sat Mar 4 23:58:52 2006 Subject: [linux-audio-dev] Errors trying to build dssi-vst 0.4 ... any help? In-Reply-To: <1141534265.3280.4.camel@machine> References: <200603011317.30260.cannam@all-day-breakfast.com> <1141531767.2901.3.camel@machine> <1141532077.14714.45.camel@mindpipe> <1141534265.3280.4.camel@machine> Message-ID: <1141534718.14714.47.camel@mindpipe> On Sun, 2006-03-05 at 15:51 +1100, Mr Machine wrote: > On Sat, 2006-03-04 at 23:14 -0500, Lee Revell wrote: > > On Sun, 2006-03-05 at 15:09 +1100, Mr Machine wrote: > > > dssi-vst-server-5Pa9Gf.o(.text+0x147e): In function > > > `RemoteVSTServer::process(float**, float**)': > > > dssi-vst-server.cpp: undefined reference to `pthread_mutex_trylock' > > > collect2: ld returned 1 exit status > > > > Do you have glibc-devel or libc6-devel or libpthreads-devel or whatever > > installed? This is a basic POSIX threading function that should be > > available in any sane development environment... > > i have the glibc-devel package: > > glibc-devel-2.3.5-10.3 > > would this mean that it is not finding it? i'm pretty sure my > PKG_CONFIG_PATH is set correctly, though. i don't have any of those > other packages installed, but i'm guessing they're the same thing as > glibc-devel, but only for different distributions (i'm using FC4)? It must be a Makefile bug then. Sorry I can't help more... Lee From chris.cannam at ferventsoftware.com Sun Mar 5 03:30:57 2006 From: chris.cannam at ferventsoftware.com (Chris Cannam) Date: Sun Mar 5 03:33:48 2006 Subject: [linux-audio-dev] Errors trying to build dssi-vst 0.4 ... any help? Message-ID: <2092932281-1141547620-cardhu_blackberry.rim.net-13145-@engine37.bwc.produk.on.blackberry> > dssi-vst-server.cpp: undefined reference to `pthread_mutex_trylock' Does the file (I don't have it to hand and am not at a proper computer) have #include at the top? If not, what if you add it? It may just be that another header includes this on other systems, but not on yours. Chris From forums at machinehasnoagenda.com Sun Mar 5 04:45:16 2006 From: forums at machinehasnoagenda.com (Mr Machine) Date: Sun Mar 5 04:45:26 2006 Subject: [linux-audio-dev] Errors trying to build dssi-vst 0.4 ... any help? In-Reply-To: <2092932281-1141547620-cardhu_blackberry.rim.net-13145-@engine37.bwc.produk.on.blackberry> References: <2092932281-1141547620-cardhu_blackberry.rim.net-13145-@engine37.bwc.produk.on.blackberry> Message-ID: <1141551916.1057.1.camel@machine> On Sun, 2006-03-05 at 08:30 +0000, Chris Cannam wrote: > > dssi-vst-server.cpp: undefined reference to `pthread_mutex_trylock' > > Does the file (I don't have it to hand and am not at a > proper computer) have > > #include > > at the top? If not, what if you add it? i'm not sure which file you mean? i tried adding it to the top of dssi-vst-server.cpp, but that didn't work ... is that the one you meant? shayne From chris.cannam at ferventsoftware.com Sun Mar 5 05:39:33 2006 From: chris.cannam at ferventsoftware.com (Chris Cannam) Date: Sun Mar 5 05:42:30 2006 Subject: [linux-audio-dev] Errors trying to build dssi-vst 0.4 ... anyhelp? Message-ID: <1748825778-1141555336-cardhu_blackberry.rim.net-12397-@engine10.bwc.produk.on.blackberry> > i'm not sure which file you mean? i tried adding it > to the top of dssi-vst-server.cpp, but that didn't > work ... is that the one you meant? Yes, but I realise I was misreading the error (it was from the linker, not the compiler). How about an extra "-lpthread" in LDFLAGS or whatever in the Makefile? Chris From julien at c-lab.de Sun Mar 5 09:23:26 2006 From: julien at c-lab.de (Julien Claassen) Date: Sun Mar 5 09:23:49 2006 Subject: [linux-audio-dev] a bit off topic: GUI-lib-programming (how does it usually work?) Message-ID: Hi! I know, this may be a bit off topic. But I've a dificulty: I'm currently programming a textbase "GUI"-lib. I want the programming API to be similar to on of a real GUI-lib (gtk, you name them). Now I'm wondering, there are menus. Menus have menuitems and if you click on one, something should happen. How is this "something should happen" part usually done? - I thought of the java-apporach, deriving your own menu-class. But it doesn't feel right. I have my dificulties with trying GUI-libs myself, for I'm blind. I could write some code, but wouldn't know, if it works, like I planned. Any thoughts, help on this, anyone? I would be greatful! Kindest regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net - the Linux TextBased Studio guide From loki.davison at gmail.com Sun Mar 5 10:00:10 2006 From: loki.davison at gmail.com (Loki Davison) Date: Sun Mar 5 10:00:14 2006 Subject: [linux-audio-dev] Re: a bit off topic: GUI-lib-programming (how does it usually work?) In-Reply-To: References: Message-ID: On 3/6/06, Julien Claassen wrote: > Hi! > I know, this may be a bit off topic. But I've a dificulty: > I'm currently programming a textbase "GUI"-lib. I want the programming API > to be similar to on of a real GUI-lib (gtk, you name them). > Now I'm wondering, there are menus. Menus have menuitems and if you click > on > one, something should happen. How is this "something should happen" part > usually done? It's done by registering a call back. In current gtk versions this is done by having actions and they have a label and are associated with a particular function. Using the python bindings http://www.pygtk.org/pygtk2tutorial/sec-UIManager.html explains the general idea for menus. There is an example there. All buttons etc in gtk work the same i.e with call backs being registered. Loki From larsl at users.sourceforge.net Sun Mar 5 10:31:16 2006 From: larsl at users.sourceforge.net (Lars Luthman) Date: Sun Mar 5 10:30:23 2006 Subject: [linux-audio-dev] Re: a bit off topic: GUI-lib-programming (how does it usually work?) In-Reply-To: References: Message-ID: <1141572676.9014.3.camel@c213-100-50-8.swipnet.se> On Mon, 2006-03-06 at 02:00 +1100, Loki Davison wrote: > On 3/6/06, Julien Claassen wrote: > > Hi! > > I know, this may be a bit off topic. But I've a dificulty: > > I'm currently programming a textbase "GUI"-lib. I want the programming API > > to be similar to on of a real GUI-lib (gtk, you name them). > > Now I'm wondering, there are menus. Menus have menuitems and if you click > > on > > one, something should happen. How is this "something should happen" part > > usually done? > > It's done by registering a call back. In current gtk versions this is > done by having actions and they have a label and are associated with a > particular function. Using the python bindings > http://www.pygtk.org/pygtk2tutorial/sec-UIManager.html explains the > general idea for menus. There is an example there. All buttons etc in > gtk work the same i.e with call backs being registered. Also, if you are using C++ it is nice to be able to use any callable object as a callback instead of only function pointers, so you can register member functions and your own functors. That can be done using some template tricks. libsigc++ is great implementation of this (it is used by gtkmm), and I think there is something similar in Boost as well. -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- 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/20060305/a0ec4c22/attachment.bin From core at jacklab.net Sun Mar 5 10:59:04 2006 From: core at jacklab.net (Michael Bohle) Date: Sun Mar 5 10:58:56 2006 Subject: [linux-audio-dev] dssi-vst 0.4 Message-ID: <1141574344.4941.41.camel@jacklab.home> Hi Devs, hi Chris I've just compiled dssi-vst 0n openSUSE10.0 successfull. I'm using wine 0.9.8, liblo 0.22 (build failed with liblo 0.23 because of a linking prob) and vstsdk 2.4. dssi-vst works nearly well with the latest rosegarden4 for suse (and the JAD2 RT kernel). I also get energyXT.dll to work standalone and inside rosegarden. dssi-vst works now more stable and faster. Thanks Chris for this helpfull software and your distribution friendly licence. JackLab will offer a binary rpm of dssi-vst 0.4 the next days. More Info www.jacklab.net Michael From cuse at users.sourceforge.net Sun Mar 5 10:56:02 2006 From: cuse at users.sourceforge.net (Christian Schoenebeck) Date: Sun Mar 5 11:00:51 2006 Subject: [linux-audio-dev] a bit off topic: GUI-lib-programming (how does it usually work?) In-Reply-To: References: Message-ID: <200603051656.03065.cuse@users.sourceforge.net> Am Sonntag, 5. M?rz 2006 15:23 schrieb Julien Claassen: > Hi! > I know, this may be a bit off topic. But I've a dificulty: > I'm currently programming a textbase "GUI"-lib. I want the programming > API to be similar to on of a real GUI-lib (gtk, you name them). > Now I'm wondering, there are menus. Menus have menuitems and if you click > on one, something should happen. How is this "something should happen" part > usually done? - I thought of the java-apporach, deriving your own > menu-class. But it doesn't feel right. I have my dificulties with trying This depends on the programming language of course. If you pick C for example then you would usually do as Loki already pointed out by using callback functions. In Java and C++ you would rather define an abstract class "MenuItem" which just defines the API, thus the method names and their arguments and return type and then you would derive that abstract class in your actual implementation classes to implement those methods. I'm just wondering how a "text based GUI lib" should look like exactly? I mean there are libraries like (n)curses, but those are actually already quite graphical. So what did you have in mind? > GUI-libs myself, for I'm blind. I could write some code, but wouldn't know, > if it works, like I planned. Btw have you planned a lecture or something for this year's LAC? Personally I would be very interested to hear how blind people usually work with computers, what kind of interfaces and software they use etc. This might also help other blind people and give developers an impression how to make software more friendly for blind people. CU Christian From julien at c-lab.de Sun Mar 5 11:15:04 2006 From: julien at c-lab.de (Julien Claassen) Date: Sun Mar 5 11:15:23 2006 Subject: [linux-audio-dev] a bit off topic: GUI-lib-programming (how does it usually work?) In-Reply-To: <200603051656.03065.cuse@users.sourceforge.net> References: <200603051656.03065.cuse@users.sourceforge.net> Message-ID: Hi! First of all: Thanks for you prompt responses. Second: the lib is written in c++. Is it ok for my toggle(on/off)-buttons to just have a function that returns either 1/0 (true/false)? Third: Chris: This lib will be ncurses-based. But I made some special adjustments for cursor-movement, generalised how things look like. I also predefined the keys to move/active/etc. It should be useable for blind people and perhaps people with other disabilites. First thing in mind was of course audio-software. If you're interested in this, or if anyone else is and feels, it's not a topic for lad, just post back by private mail. Kindest egards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net - the Linux TextBased Studio guide From artemio at kdemail.net Sun Mar 5 13:00:16 2006 From: artemio at kdemail.net (Artemiy Pavlov) Date: Sun Mar 5 13:04:26 2006 Subject: [linux-audio-dev] [ANN] Rhythm Galaxy vol. 1 drum/percussion sample library Message-ID: <200603052000.16319.artemio@kdemail.net> Dear Linux audio software users and developers, many of you may know me - a sound designer behind many free sounds I keep on making for Hydrogen rhythm machine and other samplers. Now I am pleased to announce Rhythm Galaxy vol. 1 - an all-new sound library which boasts a huge load of drums, percussion and effects - from analog and digital emulations to brand new, amazing sounds. It is a low-cost but very high-quality library which delivers just the right sounds for various styles. Rhythm Galaxy vol. 1 includes over 250 world-class, superb sounds which satisfy the needs of professional composers and music-making lovers who have been searching for fresh, unique and inspiring material. All sounds are totally original material, they have been created completely from scratch, using Roland Fantom-S, V-Synth and VC-1 synthesizers, Krok 2401 analog vocoder and also ALSA Modular synth. Rhythm Galaxy is available in two formats: - .WAV files grouped in folders ("Kick", "Snare", etc.) - suitable for any hardware/software sampler - Hydrogen drum kit with all 256 sounds (will work only in Hydrogen 0.9.4 sound library manager). Sound demo: http://soniccharger.com/media/demos/Rhythm_Galaxy_1_demo.mp3 Specs and complete sample list: http://soniccharger.com/media/manuals/Rhythm_Galaxy_manual.pdf More info: http://store.rolandclan.info/?action=catalogueViewItem&category=4&id=RGALAXY1&skip=0 You can also read more about me and my works at http://sineshine.com. Sincerely, Artemiy. From petter.sundlof at findus.dhs.org Sun Mar 5 13:08:01 2006 From: petter.sundlof at findus.dhs.org (=?UTF-8?B?UGV0dGVyIFN1bmRsw7Zm?=) Date: Sun Mar 5 13:08:14 2006 Subject: [linux-audio-dev] [ANN] Rhythm Galaxy vol. 1 drum/percussion sample library In-Reply-To: <200603052000.16319.artemio@kdemail.net> References: <200603052000.16319.artemio@kdemail.net> Message-ID: <440B2901.4020904@findus.dhs.org> Have you considered releasing this under a free license? Artemiy Pavlov wrote: > Dear Linux audio software users and developers, > > many of you may know me - a sound designer behind many free sounds I keep on > making for Hydrogen rhythm machine and other samplers. > > Now I am pleased to announce Rhythm Galaxy vol. 1 - an all-new sound library > which boasts a huge load of drums, percussion and effects - from analog and > digital emulations to brand new, amazing sounds. It is a low-cost but very > high-quality library which delivers just the right sounds for various styles. > > Rhythm Galaxy vol. 1 includes over 250 world-class, superb sounds which > satisfy the needs of professional composers and music-making lovers who have > been searching for fresh, unique and inspiring material. All sounds are > totally original material, they have been created completely from scratch, > using Roland Fantom-S, V-Synth and VC-1 synthesizers, Krok 2401 analog vocoder > and also ALSA Modular synth. > > Rhythm Galaxy is available in two formats: > > - .WAV files grouped in folders ("Kick", "Snare", etc.) - suitable for any > hardware/software sampler > > - Hydrogen drum kit with all 256 sounds (will work only in Hydrogen 0.9.4 > sound library manager). > > Sound demo: > http://soniccharger.com/media/demos/Rhythm_Galaxy_1_demo.mp3 > > Specs and complete sample list: > http://soniccharger.com/media/manuals/Rhythm_Galaxy_manual.pdf > > More info: > http://store.rolandclan.info/?action=catalogueViewItem&category=4&id=RGALAXY1&skip=0 > > You can also read more about me and my works at http://sineshine.com. > > > Sincerely, > > Artemiy. From artemio at kdemail.net Sun Mar 5 13:55:58 2006 From: artemio at kdemail.net (Artemiy Pavlov) Date: Sun Mar 5 13:56:16 2006 Subject: [linux-audio-dev] [ANN] Rhythm Galaxy vol. 1 drum/percussion sample library In-Reply-To: <440B2901.4020904@findus.dhs.org> References: <200603052000.16319.artemio@kdemail.net> <440B2901.4020904@findus.dhs.org> Message-ID: <200603052055.58429.artemio@kdemail.net> > Have you considered releasing this under a free license? l'll surely confider this when food and wear will be available for a free license too. ;-) A little bit strange question anyway, why do you think every piece of great software work should be free? This is not even a topic for discussion IMHO. Anyway, I have so much more free materials than commercial ones, these include samples, patches, FAQs, books, howtos. I am running two musicians forums with thousands of members, with no kind of ads anywhere. I take part in three open source projects. So now please flame me for trying to promote Linux as a pro music production platform with my nice 30-dollar sample library. Sincerely, Artemiy. From larsl at users.sourceforge.net Sun Mar 5 14:02:47 2006 From: larsl at users.sourceforge.net (Lars Luthman) Date: Sun Mar 5 14:01:57 2006 Subject: [linux-audio-dev] [ANN] Rhythm Galaxy vol. 1 drum/percussion sample library In-Reply-To: <200603052055.58429.artemio@kdemail.net> References: <200603052000.16319.artemio@kdemail.net> <440B2901.4020904@findus.dhs.org> <200603052055.58429.artemio@kdemail.net> Message-ID: <1141585367.9014.9.camel@c213-100-50-8.swipnet.se> On Sun, 2006-03-05 at 20:55 +0200, Artemiy Pavlov wrote: > > Have you considered releasing this under a free license? > l'll surely confider this when food and wear will be available for a free > license too. > > ;-) > > A little bit strange question anyway, why do you think every piece of great > software work should be free? This is not even a topic for discussion IMHO. > > Anyway, I have so much more free materials than commercial ones, these include > samples, patches, FAQs, books, howtos. I am running two musicians forums with > thousands of members, with no kind of ads anywhere. I take part in three open > source projects. So now please flame me for trying to promote Linux as a pro > music production platform with my nice 30-dollar sample library. I'd hardly call that question a flame, especially on a list where free licenses for software and content are the norm. -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- 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/20060305/29759799/attachment.bin From petter.sundlof at findus.dhs.org Sun Mar 5 14:04:31 2006 From: petter.sundlof at findus.dhs.org (=?UTF-8?B?UGV0dGVyIFN1bmRsw7Zm?=) Date: Sun Mar 5 14:05:04 2006 Subject: [linux-audio-dev] [ANN] Rhythm Galaxy vol. 1 drum/percussion sample library In-Reply-To: <200603052055.58429.artemio@kdemail.net> References: <200603052000.16319.artemio@kdemail.net> <440B2901.4020904@findus.dhs.org> <200603052055.58429.artemio@kdemail.net> Message-ID: <440B363F.7040208@findus.dhs.org> Artemiy Pavlov wrote: >>Have you considered releasing this under a free license? > > l'll surely confider this when food and wear will be available for a free > license too. > > ;-) > > A little bit strange question anyway, why do you think every piece of great > software work should be free? This is not even a topic for discussion IMHO. I'm not even sure your materials are great, and besides, they're not software. It's not a strange question. You decided to post an unsolicited advertisement on this mailing list, and you'd better expect some discussion. I personally release everything I create under a free license... the samples of my drum kit, translations (of course) and my music. Anyhow, the decision for license is really your business, but posting an advert on this mailing list doesn't seem very much different than spam (and in my opinion this is so regardless if you've contributed to free projects and free software). All the best, Petter Sundl?f > Anyway, I have so much more free materials than commercial ones, these include > samples, patches, FAQs, books, howtos. I am running two musicians forums with > thousands of members, with no kind of ads anywhere. I take part in three open > source projects. So now please flame me for trying to promote Linux as a pro > music production platform with my nice 30-dollar sample library. > > > Sincerely, > > Artemiy. From steve at k-hornz.de Sun Mar 5 14:05:29 2006 From: steve at k-hornz.de (stefan kersten) Date: Sun Mar 5 14:05:42 2006 Subject: [linux-audio-dev] [ANN] Rhythm Galaxy vol. 1 drum/percussion sample library In-Reply-To: <200603052055.58429.artemio@kdemail.net> References: <200603052000.16319.artemio@kdemail.net> <440B2901.4020904@findus.dhs.org> <200603052055.58429.artemio@kdemail.net> Message-ID: <20060305190529.GA16210@localdomain> On Sun, Mar 05, 2006 at 08:55:58PM +0200, Artemiy Pavlov wrote: > So now please flame me for trying to promote Linux as a pro > music production platform with my nice 30-dollar sample library. so maybe you should have tagged your message [ADV] instead of [ANN]. this is a developer list and i'm not interested in advertisements for sample libraries, however cheap they may be. From rlrevell at joe-job.com Sun Mar 5 14:14:06 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Sun Mar 5 14:14:15 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] [ANN] Rhythm Galaxy vol. 1 drum/percussion sample library In-Reply-To: <200603052055.58429.artemio@kdemail.net> References: <200603052000.16319.artemio@kdemail.net> <440B2901.4020904@findus.dhs.org> <200603052055.58429.artemio@kdemail.net> Message-ID: <1141586047.14714.91.camel@mindpipe> On Sun, 2006-03-05 at 20:55 +0200, Artemiy Pavlov wrote: > A little bit strange question anyway, why do you think every piece of > great > software work should be free? This is not even a topic for discussion > IMHO. > I'd like to thank everyone in advance for NOT starting a huge flamewar over this, as it was all covered in the "Free Software vs. Open Source" thread. Lee From forums at machinehasnoagenda.com Sun Mar 5 14:34:57 2006 From: forums at machinehasnoagenda.com (Mr Machine) Date: Sun Mar 5 14:35:08 2006 Subject: [linux-audio-dev] Errors trying to build dssi-vst 0.4 ... anyhelp? In-Reply-To: <1748825778-1141555336-cardhu_blackberry.rim.net-12397-@engine10.bwc.produk.on.blackberry> References: <1748825778-1141555336-cardhu_blackberry.rim.net-12397-@engine10.bwc.produk.on.blackberry> Message-ID: <1141587297.5349.2.camel@machine> On Sun, 2006-03-05 at 10:39 +0000, Chris Cannam wrote: > > i'm not sure which file you mean? i tried adding it > > to the top of dssi-vst-server.cpp, but that didn't > > work ... is that the one you meant? > > Yes, but I realise I was misreading the error (it was > from the linker, not the compiler). How about an > extra "-lpthread" in LDFLAGS or whatever in the > Makefile? that was it (there wasn't anything in the LDFLAGS section)! thanx for the help, i've been waiting for a while now to use vst's in Om again ;) shayne From artemio at kdemail.net Sun Mar 5 14:57:36 2006 From: artemio at kdemail.net (Artemiy Pavlov) Date: Sun Mar 5 14:57:54 2006 Subject: [linux-audio-dev] [ANN] Rhythm Galaxy vol. 1 drum/percussion =?utf-8?q?sample=09library?= In-Reply-To: <440B363F.7040208@findus.dhs.org> References: <200603052000.16319.artemio@kdemail.net> <200603052055.58429.artemio@kdemail.net> <440B363F.7040208@findus.dhs.org> Message-ID: <200603052157.36752.artemio@kdemail.net> Guys, thanks for your understanding and little misunderstanding. To Peter: 1. It *was" an announcement, I do not ever "advertise". Or you want to say that if it's free product then it's an annoucemenet, and if it's not, this is an advertisement? I didn't yet know about such specifics in OSS terminology ;-) 2. I didn't say the sounds are great, I said "amazing" and "superb" ;-) 3. I don't think anyone ever released a commercial library for Linux software, so at least I thought you developers should know I did. Please take my apologies to anyone who my post hurt. But anyway I am a little surprised by how unwelcome any Linux-for-audio promotiing intentions like mine appeared to be to some of you. I must say that, still, there were much more positive reaction to this commercial Linux sound library from users who have been awating for some changes for a while. Anyway, for those whose ears fade away when they hear a word "commercial", please see: http://rolandclan.info/en/samples/index/ ;-) Yours, Artemiy. From rncbc at rncbc.org Mon Mar 6 04:34:52 2006 From: rncbc at rncbc.org (Rui Nuno Capela) Date: Mon Mar 6 04:35:25 2006 Subject: [linux-audio-dev] [ANN] QjackCtl 0.2.20 released! Message-ID: <22775.195.245.190.93.1141637692.squirrel@www.rncbc.org> Greetings, So here comes the time for another public release of the (cute) JACK Audio Connection Kit - Qt Interface: QjackCtl 0.2.20 is out! Just as one can read from the change log: - Server path setting now accepts custom command line parameters (after a kind suggestion from Jussi Laako). - The internal XRUN callback notification statistics and reporting has been changed to be a bit less intrusive. - Patchbay socket dialog gets some more eye-candy as icons have been added to the client and plug selection (combobox) widgets. - Connections and patchbay lines coloring has changed just slightly :) - New patchbay socket forwarding feature. Any patchbay socket can now be set to have all its connections replicated (i.e. forwarded) to another one, which will behave actively as a clone of the former. Forward connections are shown by vertical directed colored lines, and can be selected either on socket dialog or from context menu (currently experimental, only applicable to input/writable sockets). - Optional specification of alternate JACK and/or ALSA installation paths on configure time (after a patch from Lucas Brasilino, thanks). Available from the usual places: http://qjackctl.sourceforge.net http://sourceforge.net/projects/qjackctl Enjoy. -- rncbc aka Rui Nuno Capela rncbc@rncbc.org From rncbc at rncbc.org Mon Mar 6 04:36:40 2006 From: rncbc at rncbc.org (Rui Nuno Capela) Date: Mon Mar 6 04:37:14 2006 Subject: [linux-audio-dev] [ANN] Qsynth 0.2.5 released! Message-ID: <23874.195.245.190.93.1141637800.squirrel@www.rncbc.org> Greetings, So here comes the time for another public release of the (cute) FluidSynth Qt Interface: Qsynth 0.2.5 is out! Just as one can read from the change log: - New dial-knob behavior now follows mouse pointer angular position, almost similar to old QDial, but this time avoiding that nasty and rather abrupt change on first mouse click. - By simple use of widget subclassing, the value/position of any dial knob can now be reset to its default or original position at any time, by simply pressing the mouse mid-button. These default value positions are just committed to current dial values when switching engines and/or closing the application. - Optional specification of alternate fluidsynth installation path has been added to configure command arguments (--with-fluidsynth). - After some source code tweaks, a win32 build is now possible (instructions will be provided on demand :) - Bank offset finally gets its due effect, while on the channels and channel preset selection dialogs. Regretfully, the soundfont bank offset feature has been lurking ever since its inception, but now its live and hopefully effective. - A new fancy widget has arrived, qsynthKnob, with some modifications to replace the actual *ugly* QDial widgets in the main window. This widget is based on a design by Thorsten Wilms, formerly implemented by Chris Cannam in Rosegarden, and finally adapted and brought to Qsynth by Pedro Lopez-Cabanillas. Thankyou all. Available from the usual places: http://qsynth.sourceforge.net http://sourceforge.net/projects/qsynth Enjoy. -- rncbc aka Rui Nuno Capela rncbc@rncbc.org From mista.tapas at gmx.net Mon Mar 6 05:32:39 2006 From: mista.tapas at gmx.net (Florian Schmidt) Date: Mon Mar 6 05:32:51 2006 Subject: [linux-audio-dev] a bit off topic: GUI-lib-programming (how does it usually work?) In-Reply-To: References: <200603051656.03065.cuse@users.sourceforge.net> Message-ID: <20060306113239.5268337e@mango.fruits.de> On Sun, 5 Mar 2006 17:15:04 +0100 (CET) Julien Claassen wrote: > Hi! > First of all: Thanks for you prompt responses. > Second: the lib is written in c++. Is it ok for my toggle(on/off)-buttons to > just have a function that returns either 1/0 (true/false)? > Third: Chris: This lib will be ncurses-based. But I made some special > adjustments for cursor-movement, generalised how things look like. I also > predefined the keys to move/active/etc. It should be useable for blind people > and perhaps people with other disabilites. First thing in mind was of course > audio-software. If you're interested in this, or if anyone else is and feels, > it's not a topic for lad, just post back by private mail. > Kindest egards > Julien I always wondered whether it was possible to do something like a generic/abstract UI thing. You bind yourself to ncurses at the moment, but wouldn't it be cool, if the same code could sit ontop of either ncurses or X/Gtk/Qt, or even be communicated via audio interface and user talking. I doubt though that all user interface aspects can be generalized in this way, but it would be cool already to get a subset as huge as possible. All X gui stuff is basically representable on an ncurses screen as long as there's no real graphical stuff involved (i.e. the typical preferences dialog serves as a good example. Just a bunchof checkboxes, comboboxes and ok and cancel buttons). I even can imagine how this could be presented to the user via a voice interface, though this is more difficult to get right. The most obvious example were this scheme would fail would be i.e. something like the GIMP. Operating on a per RGB pixel basis is very difficult to translate to ncurses or voice. Something like ardour would be almost equally tough as its interface is highly graphical (at least the editor and mixer windows. All the preferences stuff could be again dealt with). Anyone know if such a thing exists yet? Or any thoughts on the matter? Flo -- Palimm Palimm! http://tapas.affenbande.org From Cedric.Roux at eurecom.fr Mon Mar 6 05:38:15 2006 From: Cedric.Roux at eurecom.fr (Cedric Roux) Date: Mon Mar 6 05:38:24 2006 Subject: [linux-audio-dev] a bit off topic: GUI-lib-programming (how does it usually work?) In-Reply-To: <20060306113239.5268337e@mango.fruits.de> Message-ID: On Mon, 6 Mar 2006, Florian Schmidt wrote: > I always wondered whether it was possible to do something like a > generic/abstract UI thing. You bind yourself to ncurses at the moment, > but wouldn't it be cool, if the same code could sit ontop of either > ncurses or X/Gtk/Qt, or even be communicated via audio interface and user > talking. [...] > Anyone know if such a thing exists yet? Or any thoughts on the matter? > > Flo What about uiml? http://www.uiml.org/ xul could also be an answer, but maybe not. Take a look at it. http://www.mozilla.org/projects/xul/ Take care, C?dric. From capocasa at gmx.net Mon Mar 6 08:20:37 2006 From: capocasa at gmx.net (Carlo Capocasa) Date: Mon Mar 6 08:32:22 2006 Subject: [linux-audio-dev] Re: Shelljam: Help Wanted! In-Reply-To: <87y7zqs55v.dancerj%dancer@netfort.gr.jp> References: <87y7zqs55v.dancerj%dancer@netfort.gr.jp> Message-ID: Hi Junichi, thanks for your interest. > I might be missing something but is there something that shelljam does > that vkeybd cannot do? Yes. * Shelljam is designed from the ground up to be a full-fledged musical instrument that can be used for professional live performance. -Safe, locks keyboard -Uses a compiled language -Performance is measured as latency and jitter * Shelljam is portable, flexible and extensible -The I/O library supports, additionally to the keyboard under X, console keyboards, mice, joysticks, touchscreens, Sharp Zaurus and iPaq input, and all PC operating systems. -The MIDI library supports all PC operating systems -Instruments can be created as run-time libraries * Shelljam has bold plans for the future: -Create a tool that can be used by a whole movement of kids, designed from the ground up to use the computers they have in their homes as full-fledged, highly tuned musical instruments. -Shelljam will support not only keyboards but mice, joysticks, and linux handheld devices to make music in genuinely new ways -The author intends to make a living by being a singer/computer peripheral player Shelljam has a slightly higher learning curve and currently the UI looks like you just crashed your computer so if you just want to test your synth by all means use vkeybd. Carlo From mlang at delysid.org Mon Mar 6 09:27:22 2006 From: mlang at delysid.org (Mario Lang) Date: Mon Mar 6 09:26:56 2006 Subject: [linux-audio-dev] [ANN] Rhythm Galaxy vol. 1 drum/percussion sample library In-Reply-To: <20060305190529.GA16210@localdomain> (stefan kersten's message of "Sun, 5 Mar 2006 20:05:29 +0100") References: <200603052000.16319.artemio@kdemail.net> <440B2901.4020904@findus.dhs.org> <200603052055.58429.artemio@kdemail.net> <20060305190529.GA16210@localdomain> Message-ID: <87bqwj8x85.fsf@x2.delysid.org> stefan kersten writes: > On Sun, Mar 05, 2006 at 08:55:58PM +0200, Artemiy Pavlov wrote: >> So now please flame me for trying to promote Linux as a pro >> music production platform with my nice 30-dollar sample library. > > so maybe you should have tagged your message [ADV] instead > of [ANN]. this is a developer list and i'm not interested in > advertisements for sample libraries, however cheap they may > be. Seconded. -- CYa, Mario From jjbenham at chicagoguitar.com Mon Mar 6 09:39:07 2006 From: jjbenham at chicagoguitar.com (Jeremiah Benham) Date: Mon Mar 6 09:54:58 2006 Subject: [linux-audio-dev] Creating an api for an exsisting project Message-ID: <20060306143907.GS2380@chicagoguitar.com> I am working on project that does not have an api. I was wondering where to find information on building an api. We have a plugin system but the user needs the entire source if they want to build a plugin. The project I am talking about is Denemo (A gtk frontend to lilypond). Jeremiah From julien at c-lab.de Mon Mar 6 10:34:05 2006 From: julien at c-lab.de (Julien Claassen) Date: Mon Mar 6 10:34:23 2006 Subject: [linux-audio-dev] a bit off topic: GUI-lib-programming (how does it usually work?) In-Reply-To: References: Message-ID: Hi! Florian: What can such a lib do?I already have toggle-buttons, progressbars, labels and I'm working on text-entry-fields. Next thing is menus and mutiple-choice-buttons (radio-buttons, lists) and sliders. That is all stuff I can imagine and handle. I'm still thinking about linking objects. You know like in ams, link oscillator to filter. So osc-output goes into filter-input. I have some ideas on the topic though. So ardour wouldn't be such a big problem. Nasty because there's so much, it simply needs to be organised. BUT... BUT, there are things i have to take in account: All objects should be kind of line-based (a braille-display only shows a single line at a time. Objects should look like in other good text-apps, so you know, what they are, intuitively. Same goes for key-action. Apps I considered: lynx (buttons, text-entry, lists and checkboxes), emacs (look of the menubar, not functionality). About generalisation of UI: I'm based on ncurses at the moment. But I'd like to take at least slang into acount. About graphics, I don't think. There are enough GUI-libs, done much better and more elaborate than my work. Besides: I'm not a very good programmer. Ok, but far from expert. Kindest regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net - the Linux TextBased Studio guide From julien at c-lab.de Mon Mar 6 10:40:43 2006 From: julien at c-lab.de (Julien Claassen) Date: Mon Mar 6 10:40:52 2006 Subject: [linux-audio-dev] a bit off topic: GUI-lib-programming (how does it usually work?) In-Reply-To: References: Message-ID: Hi again! Perhaps, while I still have some attention: I've got one really problematic object: curves. Imagine JaMin or wave-analysers: They draw waves on the screen. But I think: mostly it's only peaks or looping-points, that are of interest. How are those curves/waves painted in graphics? Could you perhaps feed all numbers into this lib and have it calculate for you, if required. I think like. Engine works/outputs numbers/lib gets them/user requests: calculate peaks and can get a list of them. Is this too far off track? I appreciate any good thoughts. Yet please remember: I'm no programming crack and not too good at mathematics? So be gentle on me. Explain easy. :-) Kindest regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net - the Linux TextBased Studio guide From jamesmichaelmcdermott at gmail.com Mon Mar 6 12:10:43 2006 From: jamesmichaelmcdermott at gmail.com (James McDermott) Date: Mon Mar 6 12:10:49 2006 Subject: [linux-audio-dev] a bit off topic: GUI-lib-programming (how does it usually work?) In-Reply-To: References: Message-ID: > I'm still thinking about linking objects. You know like in ams, > link oscillator to filter. So osc-output goes into filter-input. I have some > ideas on the topic though. A while ago I was thinking about a nice way to display this type of information without graphics. I didn't come up with anything better than a Makefile-style syntax. Consider Om or AMS as an example: suppose we have a sawtooth oscillator node and a sampler node feeding into a filter node, and the filter node feeds into the master sink node. We can just write that as: sink: filter filter: sawtooth sampler Those two lines read, as they would in a Makefile, as "sink depends on filter" and "filter depends on sawtooth and on sampler". If this is totally useless to the project at hand, someone please put me out of my misery... James From julien at c-lab.de Mon Mar 6 12:43:51 2006 From: julien at c-lab.de (Julien Claassen) Date: Mon Mar 6 12:44:07 2006 Subject: [linux-audio-dev] a bit off topic: GUI-lib-programming (how does it usually work?) In-Reply-To: References: Message-ID: Hi James! This is a nice idea indeed, but for a programming language or a commandline interface. I like both of them, but I want to create an interactive UI with buttons and the like. Mainmotivation behind it: create something users and programmers alike find intuitive. Especially the programmers should be attracted to it, so they would consider building text-UIsa simpler task and just do it. :-) Thanks anyway, perhaps somebody else may take it up for other purposes. Kindest regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net - the Linux TextBased Studio guide From ix at replic.net Mon Mar 6 13:15:11 2006 From: ix at replic.net (cdr) Date: Mon Mar 6 13:15:17 2006 Subject: [linux-audio-dev] a bit off topic: GUI-lib-programming (how does it usually work?) In-Reply-To: References: Message-ID: <20060306181511.GA2932@replic.net> > > I'm still thinking about linking objects > A while ago I was thinking about a nice way to display this type of > information without graphics. ASCII graphics are still graphics, in they would be hard to read line by line in a single or double-row LED display for example. which is what many digital musical instruments were limited to for about 2 decades. if you make the jump to using ASCII as graphics theres definitely been some work done on dealing with n-dimensional node graphs http://xanadu.com/zigzag/ of course SCLang proves you dont need graphics to have a concise and readable graph description, along with some algorithmic sugar.. > Consider Om or AMS as an example: suppose we have a sawtooth > oscillator node and a sampler node feeding into a filter node, and the > filter node feeds into the master sink node. We can just write that > as: > > sink: filter > filter: sawtooth sampler From drclaw at dogsolitude.org Mon Mar 6 18:21:43 2006 From: drclaw at dogsolitude.org (drclaw@dogsolitude.org) Date: Mon Mar 6 18:14:08 2006 Subject: [linux-audio-dev] Reliability of SPDIF sync w/ onboard audio? Message-ID: <20060306232143.GA31817@dogsolitude.org> Ok, given a pair of commodity Linux PC's with cheapo onboard audio codecs capable of SPDIF input and output, assuming I sent identical input signals into both machines and didn't perform any processing in the middle, could I reasonably expect the output signals to be synchronized, or should I expect unpleasant phasing / delay effects when listening to both channels simultaneously as a result of the inherently flakey consumer-grade codecs? The above is a simplification that should address my major concern... The goal here is to use a pair of redundant, inexpensive machines for live midi-controlled (headless) playback where the physical security of the location is lax enough that using my laptop + hammerfall would be too risky, not to mention 35 channels worth of overkill. Ideally these two machines would accept some sort of SPDIF format square-wave from some low power clock logic on their inputs and play identical, pre-cached wav files on their outputs when they recieve simultaneous "go" signals from the MIDI playback desk. Any experiences or opinions are welcome... Thanks, - Mike Piantedosi From radarsat1 at gmail.com Mon Mar 6 18:31:29 2006 From: radarsat1 at gmail.com (Steve) Date: Mon Mar 6 18:31:34 2006 Subject: [linux-audio-dev] a bit off topic: GUI-lib-programming (how does it usually work?) In-Reply-To: <9b3e2dc20603061527j611ffe54yccab642bc0a54289@mail.gmail.com> References: <20060306113239.5268337e@mango.fruits.de> <9b3e2dc20603061527j611ffe54yccab642bc0a54289@mail.gmail.com> Message-ID: <9b3e2dc20603061531u4117e247t7e130eb3ad88a6b1@mail.gmail.com> Also check out http://www.gobolinux.org/abstk/ which supports ncurses and Qt back-ends. Unfortunately no GTK though, and I don't know about what development state it is in. steve > On 3/6/06, Cedric Roux wrote: > > On Mon, 6 Mar 2006, Florian Schmidt wrote: > > > > > I always wondered whether it was possible to do something like a > > > generic/abstract UI thing. You bind yourself to ncurses at the moment, > > > but wouldn't it be cool, if the same code could sit ontop of either > > > ncurses or X/Gtk/Qt, or even be communicated via audio interface and user > > > talking. > > > > [...] > > > > > Anyone know if such a thing exists yet? Or any thoughts on the matter? > > > > > > Flo > > > > What about uiml? > > http://www.uiml.org/ > > > > xul could also be an answer, but maybe not. Take a look at it. > > http://www.mozilla.org/projects/xul/ > > > > Take care, > > C?dric. > > > > > > From capocasa at gmx.net Tue Mar 7 02:42:41 2006 From: capocasa at gmx.net (Carlo Capocasa) Date: Tue Mar 7 02:43:05 2006 Subject: [linux-audio-dev] Re: [ANN] Rhythm Galaxy vol. 1 drum/percussion sample library In-Reply-To: <200603052000.16319.artemio@kdemail.net> References: <200603052000.16319.artemio@kdemail.net> Message-ID: Hi Artemiy I like the way you keep your ground when people decide to show some teeth. And thanks for your hydrogen sounds, shameless as I am I decided to show off with a few local hip hop kids with it and it did work, lol I do tend to agree that the future is in giving away work for free but I would be in no position to tell you what to do even if I could make as fine sounds as you. So can I assume that this http://tipping.selfpromotion.com approach has not worked for you? You see even though the list of 'samples I have created that I like' has just topped two last month, I have this inner urge to get the latter approach to work. Maybe the donation buttons need a little dressing up, like a sales letter for the donation button? Maybe people need to be told their spouses will magically become more responsive if they donate? (shudder) I'd be interested to hear your thoughts on this. Carlo PS: Oh, and which of your hydrogen samples to you like best? ;) From capocasa at gmx.net Tue Mar 7 03:08:36 2006 From: capocasa at gmx.net (Carlo Capocasa) Date: Tue Mar 7 03:09:13 2006 Subject: [linux-audio-dev] Re: Creating an api for an exsisting project In-Reply-To: <20060306143907.GS2380@chicagoguitar.com> References: <20060306143907.GS2380@chicagoguitar.com> Message-ID: Hi, Jem :) Well actually creating an API is not really about programming as much as documenting. So it's really just about letting people know which functions they can use and what they do... Or more elegantly, which functions they must PROVIDE in their plugin architecture, and then you use the functions (the callback approach). Since you're using C++ there's a very elegant approach to this called polymorphism. What you do is create an abstract base class, where you implement the complete API as public members, and then let your plugin developers know they can create their plugins as a sub-class of this class (provide the header file). Here's how it looks: *Untested code!* /* plugin.h */ #ifndef _PLUGIN_H #define _PLUGIN_H class Plugin { public: Plugin() {} ~Plugin() {} // Abstract class has no body file so constructors // must be implemented here virtual int getNotes()=0; virtual void setNotes(int note)=0; // Here your API consists of // these two virtual functions }; #endif /* notemesmerizer.h */ #ifndef _NOTEMESMERIZER_H #define _NOTEMESMERIZER_H #include "plugin.h" class NoteMesmerizer: Plugin { public: NoteMesmerizer(); ~NoteMesmerizer(); int getNotes(); // Not implementing both functions in the void setNotes(int note); // base class would cause a compile error } #endif /* notemesmerizer.cxx */ #include "notemesmerizer.h" NoteMesmerizer::NoteMesmerizer(): Plugin() { // Do something; construct } NoteMesmerizer::~NoteMesmerizer() { // Do something; destruct } int NoteMesmerizer::getNotes() { // Do interesting stuff here return e=mc2 } void NoteMesmerizer::setNotes(int note) { // Do interesting stuff here } /* main.cxx */ #include "plugin.h" int main() { // DLOPEN stuff here // Polymorphism: Declare base class, implement // derived class Plugin* plugins[]; int notes[]; for (int i=0;igetNotes(); } } Ask away if you wanna know more... Took me long enough to find this stuff out so you should know too :) Hope this is helpful! Carlo From t_w_ at freenet.de Tue Mar 7 08:08:13 2006 From: t_w_ at freenet.de (Thorsten Wilms) Date: Tue Mar 7 08:08:19 2006 Subject: [linux-audio-dev] Old Specimen mockups Message-ID: <20060307130813.GB6787@charly.SWORD> Hi! Specimen might be dead or in keep-functioning-maintainance only, and work based on these mockups had been canceled before due to them being too time consuming to implement and doubts on extendability, anyway :( BUT, instead of them just bit-rotting on my hd, I rather present them here, since they could still be an inspiration to someone :) 1. Keys and Main: http://xs71.xs.to/pics/06102/specimen_18_keys_main_i.png 2. Mixer and Pitch: http://xs71.xs.to/pics/06102/specimen_18_mixer_pitch_i.png Like in the actual Specimen, all sliders are fan-sliders. (http://leute.uni-wuppertal.de/~ka0394/en/fan-sliders/index.html) On the left there are 16 MIDI channels down. The numbers also act as MIDI activity indicator (3 is receiving something). They're followed by volume slider, mono, solo and name. The selected channel (1) is connected to the Keys/Mixer area. This works a bit like tabs, but allows that section to come up from the sunken field, resulting in cleaner look. It's all meant to be GTK theming friendly. On the keys area, Patches are assigned to keyboard ranges. They can be put in columns to allow layering. The base note is marked (D here, could have made that more obvious). The selected Patch is shown in inverted colour. The Mixer area is a bit redundant as it is shown here. Initialy it was meant to not just allow access to panning over what the channels section on the left offers, but also Cut/Cut by (a more versatile, but not exactly self explaining system than exclusion groups, used for cutting off a open hi-hat on a closed one and similar things). Every selection of Parameters could be shown in that table, though. The right section shows the selected Patch. It was a goal to keep the Specimen window rather small to make using it with other apps more handable, so a number of tabs were needed. The not shown Volume, Panning, Cutoff and Resonance tabs would be much like the Pitch one. Contents of that tab should be pretty selfexplainatory, or it's no good anyway :) The 3 sections layout and the Keys area where all my own idea, but Pete Bessman's influence and decisons are all over the place. Cheers, Thorsten Wilms --- http://xs.to - Free Image Hosting From mista.tapas at gmx.net Tue Mar 7 11:08:23 2006 From: mista.tapas at gmx.net (Florian Schmidt) Date: Tue Mar 7 11:08:33 2006 Subject: [linux-audio-dev] a bit off topic: GUI-lib-programming (how does it usually work?) In-Reply-To: References: Message-ID: <20060307170823.39d65a22@mango.fruits.de> On Mon, 6 Mar 2006 16:34:05 +0100 (CET) Julien Claassen wrote: > Hi! > Florian: What can such a lib do?I already have toggle-buttons, progressbars, > labels and I'm working on text-entry-fields. Next thing is menus and > mutiple-choice-buttons (radio-buttons, lists) and sliders. That is all stuff > I can imagine Hi Julien, i kinda hijacked your thread. I was wondering about whether such a lib generally existed,because it would make programming apps for all kinds of user groups easier, as one could create different interfaces from the same interface description. I didn't want to imply that you should wirte such a lib. I was just generally interested in the subject and wondered how far many day-to-day typical UI usecases could be abstracted. Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org From derek at x-i.net Tue Mar 7 23:56:21 2006 From: derek at x-i.net (derek holzer) Date: Tue Mar 7 23:56:35 2006 Subject: [linux-audio-dev] Gerard van Dongen/Gilcher 1967-2006 Message-ID: <440E63F5.8080203@x-i.net> Gerard van Dongen/Gilcher passed away on Friday the 4th of March, after a brave battle with colon cancer. Gerard worked as a composer, musician and computer programmer in Rotterdam as well as played live with many improvisational and electronic musicians in the Netherlands including Bart Maris, Tom Wouters, Joe Williamson, Henk Bakker, Peter van Bergen and Ann LaBerge. He performed solo-concerts with electronics and/or piano compositions and played for numerous dance and theatre productions, produced radio-plays for the internet, and was a technical designer and software programmer for multimedia theater. Gerard was also an active member of the Pure Data and Linux Audio Developers communities, and contributed code for the user interface of the Ardour project. Gerard kept a very positive outlook throughout his illness, and he will certainly be missed. Marie Louise Gilcher has organized a memorial service for Thursday, 9 March at the "Crooswijk" Cemetery in Rotterdam. -- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 118: "Make what's perfect more human" From torbenh at gmx.de Wed Mar 8 13:58:25 2006 From: torbenh at gmx.de (torbenh@gmx.de) Date: Wed Mar 8 14:03:46 2006 Subject: [linux-audio-dev] jack.udp and synchronisation In-Reply-To: <20060227140405.GB8106@stud.ntnu.no> References: <20060224151949.GA4570@stud.ntnu.no> <20060224192212.GA4715@localdomain> <20060227140405.GB8106@stud.ntnu.no> Message-ID: <20060308185825.GA8096@mobilat> On Mon, Feb 27, 2006 at 03:04:05PM +0100, Asbj?rn S?b? wrote: > On Fri, Feb 24, 2006 at 08:22:12PM +0100, stefan kersten wrote: > > On Fri, Feb 24, 2006 at 04:19:49PM +0100, Asbj?rn S?b? wrote: > > > (On a side note, it seems that Rohan Drape's web pages that are linked > > > to from the jack pages, http://www.alphalink.com.au/~rd/sw/jack.html, > > > have disappeared.) > > > > rohan moved to http://slavepianos.org/rd/ > > Thanks! > > Do you by the way have any experience with jack.udp, and can tell how it > is synchronised? jack.udp does not synchronize at all. thats why it misses packets if you dont wordclock sync both soundcards. > > > Asbj?rn > -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From clemens at ladisch.de Thu Mar 9 03:43:55 2006 From: clemens at ladisch.de (Clemens Ladisch) Date: Thu Mar 9 03:44:34 2006 Subject: [linux-audio-dev] Reliability of SPDIF sync w/ onboard audio? In-Reply-To: <20060306232143.GA31817@dogsolitude.org> References: <20060306232143.GA31817@dogsolitude.org> Message-ID: <20060309084355.GC1314@turing.informatik.uni-halle.de> drclaw@dogsolitude.org wrote: > Ok, given a pair of commodity Linux PC's with cheapo onboard audio > codecs capable of SPDIF input and output, assuming I sent identical > input signals into both machines and didn't perform any processing in > the middle, could I reasonably expect the output signals to be > synchronized, or should I expect unpleasant phasing / delay effects > when listening to both channels simultaneously as a result of the > inherently flakey consumer-grade codecs? Onboard codecs do not support synchronizing to an external signal. The output frequency will always be determined by their own sample clock. Regards, Clemens From elisa.zwei at googlemail.com Thu Mar 9 10:28:22 2006 From: elisa.zwei at googlemail.com (Tobias Scharnberg) Date: Thu Mar 9 10:28:27 2006 Subject: [linux-audio-dev] Writing PCM to left and right channel sperately? Message-ID: <1448f040603090728i586e6506o@mail.gmail.com> Hello List, I'm new to audio programming and have problems finding the right solutions for the development I work on right now: I need to use the left and the right audio channel seperately. The device is an ARM based board with a AC97 soundchip. It seems to work with OSS so far and I did choose libsdnfile to open Soundfiles and get the PCM. As far as I learned the audio data is coded in one stream, one sample left, one sample right. Is there a way to separately fill the soundcard buffers with ALSA? The only solution I can think of right now is to recode the audio data to left only or right only and to use a library like esound to mix them together. Is this the right way to do such a thing? Any suggestions, pointers, hints are highly welcome. Greetings, Tobias From paul at linuxaudiosystems.com Thu Mar 9 10:56:49 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Thu Mar 9 10:53:29 2006 Subject: [linux-audio-dev] Writing PCM to left and right channel sperately? In-Reply-To: <1448f040603090728i586e6506o@mail.gmail.com> References: <1448f040603090728i586e6506o@mail.gmail.com> Message-ID: <1141919809.7625.82.camel@localhost.localdomain> On Thu, 2006-03-09 at 16:28 +0100, Tobias Scharnberg wrote: > Hello List, > > I'm new to audio programming and have problems finding the right > solutions for the development I work on right now: > > I need to use the left and the right audio channel seperately. The > device is an ARM based board with a AC97 soundchip. It seems to work > with OSS so far and I did choose libsdnfile to open Soundfiles and get > the PCM. As far as I learned the audio data is coded in one stream, > one sample left, one sample right. Is there a way to separately fill > the soundcard buffers with ALSA? many. > The only solution I can think of right now is to recode the audio > data to left only or right only and to use a library like esound to > mix them together. Is this the right way to do such a thing? esound is not a library for mixing. what type of application are you writing? From elisa.zwei at googlemail.com Thu Mar 9 11:01:59 2006 From: elisa.zwei at googlemail.com (Tobias Scharnberg) Date: Thu Mar 9 11:02:14 2006 Subject: [linux-audio-dev] Writing PCM to left and right channel sperately? In-Reply-To: <1141919809.7625.82.camel@localhost.localdomain> References: <1448f040603090728i586e6506o@mail.gmail.com> <1141919809.7625.82.camel@localhost.localdomain> Message-ID: <1448f040603090801w1785c4bds@mail.gmail.com> Hello Paul 2006/3/9, Paul Davis : > > As far as I learned the audio data is coded in one stream, > > one sample left, one sample right. Is there a way to separately fill > > the soundcard buffers with ALSA? > > many. What do you mean - there are many ways when using ALSA or are there also ways when using OSS. I know - this is RTFM worthy - but I have no time for that, so a pointer would be very helpful! > esound is not a library for mixing. OK, its a sound server. > what type of application are you writing? The application has to play back automated announcements on a amplifier/speaker system but it has to be able to play 2 different announcements at the same time - one on the left and one on the right channel. Tobias From paul at linuxaudiosystems.com Thu Mar 9 11:28:31 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Thu Mar 9 11:25:09 2006 Subject: [linux-audio-dev] Writing PCM to left and right channel sperately? In-Reply-To: <1448f040603090801w1785c4bds@mail.gmail.com> References: <1448f040603090728i586e6506o@mail.gmail.com> <1141919809.7625.82.camel@localhost.localdomain> <1448f040603090801w1785c4bds@mail.gmail.com> Message-ID: <1141921712.7625.85.camel@localhost.localdomain> On Thu, 2006-03-09 at 17:01 +0100, Tobias Scharnberg wrote: > What do you mean - there are many ways when using ALSA or are there > also ways when using OSS. I know - this is RTFM worthy - but I have no > time for that, so a pointer would be very helpful! if you use OSS the kernel will print a message complaining about your application. OSS is an officially deprecated API, and you should not use it. > > what type of application are you writing? > > The application has to play back automated announcements on a > amplifier/speaker system but it has to be able to play 2 different > announcements at the same time - one on the left and one on the right > channel. you just take one of the example ALSA PCM apps. they typically configure the h/w for stereo, interleaved output, often 16 bit samples. then you just need an array of 16 bit samples, and you write the left/right samples into alternating entries in the array. write the array. done. --p From ben at glw.com Thu Mar 9 14:01:10 2006 From: ben at glw.com (Ben Loftis) Date: Thu Mar 9 12:47:23 2006 Subject: [linux-audio-dev] Writing PCM to left and right channel seperately? In-Reply-To: <20060309162514.517F0A1A2B8@music.columbia.edu> References: <20060309162514.517F0A1A2B8@music.columbia.edu> Message-ID: <200603091301.10586.ben@glw.com> Tobias, I wrote a program that does just this some years ago for IED (www.iedaudio.com). What you are doing is not trivial. When an announcement starts on the left channel (for example) you will want to fill the right channel with zeroes. However you must fill the buffers in small blocks so that if an announcement starts on the right channel, you can start stuffing the right channel without a long delay. You might want to investigate Paul's program JACK for this. It splits the audio into separate buffers for each I/O. If you really have to have it ASAP, why not just buy an IED system? :) -Ben From sean at dague.net Thu Mar 9 22:10:10 2006 From: sean at dague.net (Sean Dague) Date: Thu Mar 9 22:27:01 2006 Subject: [linux-audio-dev] options in capturing audio off a PlusDeck? Message-ID: <20060310031010.GG6737@underhill.no-ip.org> I got myself one of the PlusDeck units last summer after having received some documentation from the product team about their serial control protocol, so I figured that I'd have some chance at actually making a recording program for Linux for it. The impetus for all of this is a stack of 300 or so audio tapes that my fiancee has, which contain mostly south Indian music recordings, including training lessons, from her late teacher T Viswanathan. Some of those probably don't exist anywhere else at this point, so putting them to digital would be a good thing (tm). Anyway, I have 2 goals. First, the practical, get all this music to digital dumps (flac in ogg containers for metadata seems to be the best bet). I'm trying to figure out the best ways to do this on a Mandriva Linux 2.6.12 kernel (on an AMD64 3000+ processor running 32bit, with Via onboard sound.) The PlusDeck just ends up being an input line jack into the sound card. I've run some tests with ecasound both straight off the alsa device, and through ecasound to jackd (both as root to get real time). It is hard to tell if I'm doing better with jackd or not, but I'm making some long recordings and letting my musical fiancee tell me if she can hear the difference. :) Given that I've got the serial protocol sorted out, it seems like the practical approach is just a command line ripper that will start up all the right audio bits, start the tape, and stop when the tape gets to the end. Full automation is what I'm looking to create. Is ecasound a good option here? How much better will ecasound + jackd be over ecasound at realtime? Would building some kind of plusdeck control plugin for another recording program make more sense? If so, which one? Second, I'd like to turn whatever I learn during the practical phase into a reasonable open source Linux tool for using the PlusDeck. I'd be a bit unnerved if that required that I set up all jack & ecasound bits, as well as kicked them off as setuid root, but better options are failing me at the moment. Any advice, ideas, suggestions, questions... even flames would be welcomed. I've spent a bit of time learning more than I ever thought I'd end up knowing about Linux audio already, and know I have a whole lot more I need to learn still. Thanks in advance, -Sean -- __________________________________________________________________ Sean Dague Mid-Hudson Valley sean at dague dot net Linux Users Group http://dague.net http://mhvlug.org There is no silver bullet. Plus, werewolves make better neighbors than zombies, and they tend to keep the vampire population down. __________________________________________________________________ -------------- 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/20060309/380ba38d/attachment.bin From clemens at ladisch.de Fri Mar 10 03:32:19 2006 From: clemens at ladisch.de (Clemens Ladisch) Date: Fri Mar 10 05:06:06 2006 Subject: [linux-audio-dev] Writing PCM to left and right channel sperately? In-Reply-To: <1448f040603090728i586e6506o@mail.gmail.com> References: <1448f040603090728i586e6506o@mail.gmail.com> Message-ID: <20060310083219.GD10971@turing.informatik.uni-halle.de> Tobias Scharnberg wrote: > I need to use the left and the right audio channel seperately. If you're using the ALSA library, you can use the following definitions in /etc/asound.conf or ~/.asoundrc to get two independent virtual devices: pcm.left { type plug slave.pcm { type dshare ipc_key 12345 slave.pcm "hw:0,0" slave.channels 2 bindings { 0 0 } } } pcm.right { type plug slave.pcm { type dshare ipc_key 12345 slave.pcm "hw:0,0" slave.channels 2 bindings { 0 1 } } } HTH Clemens From artemio at kdemail.net Fri Mar 10 08:39:40 2006 From: artemio at kdemail.net (Artemiy Pavlov) Date: Fri Mar 10 08:40:01 2006 Subject: [linux-audio-dev] Roland CG-8: another Linux product Message-ID: <200603101539.40990.artemio@kdemail.net> Hey all, just noticed that Roland's CG-8 Visual Synthesizer (http://www.edirol.net/products/en/CG-8/) is yet another product based on Linux. You can get their sources at: http://www.roland.com/support/gpl/ - there in the first download you'll see ALSA and GTK sources. Now when will they release a Linux-based workstation that doesn't cost like OASYS? ;-) Artemiy. From torbenh at gmx.de Sat Mar 11 13:01:43 2006 From: torbenh at gmx.de (torbenh@gmx.de) Date: Sat Mar 11 13:06:51 2006 Subject: [linux-audio-dev] [ANN] netjack-0.8 Message-ID: <20060311180143.GA3508@mobilat> netjack-0.8 is released. netjack links jackds together via a network. build your linux-audio cluster. work on a remote ardour, or even 2 ardours at once. netjack is also great for jamming with a friend. - one period roundtrip latency. - transport sync supporting slow-sync clients. see: http://netjack.sourceforge.net -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From torbenh at gmx.de Sun Mar 12 08:06:21 2006 From: torbenh at gmx.de (torbenh@gmx.de) Date: Sun Mar 12 08:11:30 2006 Subject: [linux-audio-dev] [ANN] netjack-0.9rc1 In-Reply-To: <20060311180143.GA3508@mobilat> References: <20060311180143.GA3508@mobilat> Message-ID: <20060312130621.GA8751@mobilat> On Sat, Mar 11, 2006 at 07:01:43PM +0100, torbenh@gmx.de wrote: netjack-0.9rc1 is here... endianess issues fixed. tests are underway... but if it works for 2 x86 (double swap) it should work for PPC <-> x86 > > netjack-0.8 is released. > > netjack links jackds together via a network. > build your linux-audio cluster. work on a remote ardour, > or even 2 ardours at once. > > netjack is also great for jamming with a friend. > > - one period roundtrip latency. > - transport sync supporting slow-sync clients. > > see: http://netjack.sourceforge.net > > -- > torben Hohn > http://galan.sourceforge.net -- The graphical Audio language > -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From rlrevell at joe-job.com Sun Mar 12 15:50:26 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Sun Mar 12 15:50:46 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] [ANN] netjack-0.9rc1 In-Reply-To: <20060312130621.GA8751@mobilat> References: <20060311180143.GA3508@mobilat> <20060312130621.GA8751@mobilat> Message-ID: <1142196626.25358.144.camel@mindpipe> On Sun, 2006-03-12 at 14:06 +0100, torbenh@gmx.de wrote: > netjack-0.9rc1 is here... > endianess issues fixed. tests are underway... > but if it works for 2 x86 (double swap) it should work for PPC <-> > x86 Why do you use big-endian on the wire, requiring a double swap for x86 <-> x86? Wouldn't LE make more sense, especially as PPC Macs become unavailable? Lee From rlrevell at joe-job.com Sun Mar 12 17:20:38 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Sun Mar 12 17:20:44 2006 Subject: [linux-audio-dev] Letter to kernel developers? Message-ID: <1142202039.25358.183.camel@mindpipe> Can someone please help me find a link to the open letter to kernel developers regarding horrible latency with kernel 2.6 that Paul Davis, Benno Sennoner and others posted to LKML in early 2004 (NOT the one from 2000) - the one that led Ingo to develop the voluntary preemption patches. I cannot find it with any amount of googling, and my local LKML archive only starts in July 2004. There was such a letter right? Am I crazy or just making this up? Lee From a at gaydenko.com Sun Mar 12 21:11:59 2006 From: a at gaydenko.com (Andrew Gaydenko) Date: Sun Mar 12 21:12:04 2006 Subject: [linux-audio-dev] Amplitude modulation with LADSPA Message-ID: <200603130511.59700@goldspace.net> The aim is: - to generate high frequency sine (say, 1-10KHz - carrier), - to modulate it's amplitude with low frquency signal (say, in 1-10Hz range), - to pass this modulated signal through some device, - to demodulate it, and, as a result, - to get that 1-10Hz signal. Is there sutable LADSPA plugins to construct this chain? Thanks in advance! Andrew From larsl at users.sourceforge.net Sun Mar 12 21:21:54 2006 From: larsl at users.sourceforge.net (Lars Luthman) Date: Sun Mar 12 21:22:06 2006 Subject: [linux-audio-dev] Amplitude modulation with LADSPA In-Reply-To: <200603130511.59700@goldspace.net> References: <200603130511.59700@goldspace.net> Message-ID: <1142216514.8874.10.camel@c213-100-50-8.swipnet.se> On Mon, 2006-03-13 at 05:11 +0300, Andrew Gaydenko wrote: > The aim is: > > - to generate high frequency sine (say, 1-10KHz - carrier), The "Sine oscillator" in the LADSPA toolkit (1046/sine_fcaa) > - to modulate it's amplitude with low frquency signal (say, in 1-10Hz range) The "Sine oscillator" in the LADSPA toolkit (1047/sine_fcac) > - to pass this modulated signal through some device, > - to demodulate it, and, as a result, > - to get that 1-10Hz signal. Not sure about this. Maybe use the "Frequency tracker" in swh-plugins (1418/freqTracker) and subtract the known frequency of your high frequency sine from the result? -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- 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/20060313/19354985/attachment.bin From a at gaydenko.com Sun Mar 12 21:50:05 2006 From: a at gaydenko.com (Andrew Gaydenko) Date: Sun Mar 12 21:50:08 2006 Subject: [linux-audio-dev] Amplitude (de)modulation with JACK (was "with LADSPA") In-Reply-To: <1142216514.8874.10.camel@c213-100-50-8.swipnet.se> References: <200603130511.59700@goldspace.net> <1142216514.8874.10.camel@c213-100-50-8.swipnet.se> Message-ID: <200603130550.05574@goldspace.net> Lars, thanks, I'll try. !! Well, it seems like "to be inside LADSPA" is unneeded restriction. Any JACK-enabled apps will be helpful. My mistake, sorry... The thread subject was changed. Andrew ======= On Monday 13 March 2006 05:21, Lars Luthman wrote: ======= On Mon, 2006-03-13 at 05:11 +0300, Andrew Gaydenko wrote: > The aim is: > > - to generate high frequency sine (say, 1-10KHz - carrier), The "Sine oscillator" in the LADSPA toolkit (1046/sine_fcaa) > - to modulate it's amplitude with low frquency signal (say, in 1-10Hz range) The "Sine oscillator" in the LADSPA toolkit (1047/sine_fcac) > - to pass this modulated signal through some device, > - to demodulate it, and, as a result, > - to get that 1-10Hz signal. Not sure about this. Maybe use the "Frequency tracker" in swh-plugins (1418/freqTracker) and subtract the known frequency of your high frequency sine from the result? -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E From loki.davison at gmail.com Sun Mar 12 23:43:22 2006 From: loki.davison at gmail.com (Loki Davison) Date: Sun Mar 12 23:43:33 2006 Subject: [linux-audio-dev] Re: Amplitude (de)modulation with JACK (was "with LADSPA") In-Reply-To: <200603130550.05574@goldspace.net> References: <200603130511.59700@goldspace.net> <1142216514.8874.10.camel@c213-100-50-8.swipnet.se> <200603130550.05574@goldspace.net> Message-ID: On 3/13/06, Andrew Gaydenko wrote: > Lars, thanks, I'll try. > > !! Well, it seems like "to be inside LADSPA" is unneeded restriction. > Any JACK-enabled apps will be helpful. My mistake, sorry... The thread > subject was changed. > > Andrew > Just putting together ladspas with om should be the right tool for the job. Loki From rzewnickie at rfa.org Sun Mar 12 23:46:34 2006 From: rzewnickie at rfa.org (Eric Dantan Rzewnicki) Date: Sun Mar 12 23:46:41 2006 Subject: [linux-audio-dev] Old Specimen mockups In-Reply-To: <20060307130813.GB6787@charly.SWORD> References: <20060307130813.GB6787@charly.SWORD> Message-ID: <20060313044634.GB32263@rfa.org> Great. Thanks Thorsten. Duly noted, bookmarked and saved. On Tue, Mar 07, 2006 at 02:08:13PM +0100, Thorsten Wilms wrote: > Hi! > > Specimen might be dead or in keep-functioning-maintainance only, > and work based on these mockups had been canceled before due to > them being too time consuming to implement and doubts on > extendability, anyway :( > > BUT, instead of them just bit-rotting on my hd, I rather present > them here, since they could still be an inspiration to someone :) > > > 1. Keys and Main: > http://xs71.xs.to/pics/06102/specimen_18_keys_main_i.png > > 2. Mixer and Pitch: > http://xs71.xs.to/pics/06102/specimen_18_mixer_pitch_i.png > > > Like in the actual Specimen, all sliders are fan-sliders. > (http://leute.uni-wuppertal.de/~ka0394/en/fan-sliders/index.html) > > On the left there are 16 MIDI channels down. The numbers also > act as MIDI activity indicator (3 is receiving something). > They're followed by volume slider, mono, solo and name. > > The selected channel (1) is connected to the Keys/Mixer area. > This works a bit like tabs, but allows that section to come > up from the sunken field, resulting in cleaner look. > It's all meant to be GTK theming friendly. > > On the keys area, Patches are assigned to keyboard ranges. > They can be put in columns to allow layering. The base note is > marked (D here, could have made that more obvious). > The selected Patch is shown in inverted colour. > > The Mixer area is a bit redundant as it is shown here. > Initialy it was meant to not just allow access to panning over > what the channels section on the left offers, but also Cut/Cut by > (a more versatile, but not exactly self explaining system than > exclusion groups, used for cutting off a open hi-hat on a closed > one and similar things). Every selection of Parameters could be > shown in that table, though. > > The right section shows the selected Patch. It was a goal to > keep the Specimen window rather small to make using it with other > apps more handable, so a number of tabs were needed. > > The not shown Volume, Panning, Cutoff and Resonance tabs > would be much like the Pitch one. Contents of that tab should be > pretty selfexplainatory, or it's no good anyway :) > > > The 3 sections layout and the Keys area where all my own idea, but > Pete Bessman's influence and decisons are all over the place. > > > Cheers, > Thorsten Wilms > > --- > http://xs.to - Free Image Hosting -- Eric Dantan Rzewnicki Apprentice Linux Audio Developer and Mostly Harmless Sysadmin (text below this line mandated by management) Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact network@rfa.org. From rlrevell at joe-job.com Sun Mar 12 23:54:16 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Sun Mar 12 23:54:24 2006 Subject: [linux-audio-dev] Amplitude (de)modulation with JACK (was "with LADSPA") In-Reply-To: <200603130550.05574@goldspace.net> References: <200603130511.59700@goldspace.net> <1142216514.8874.10.camel@c213-100-50-8.swipnet.se> <200603130550.05574@goldspace.net> Message-ID: <1142225657.25358.281.camel@mindpipe> On Mon, 2006-03-13 at 05:50 +0300, Andrew Gaydenko wrote: > Lars, thanks, I'll try. > > !! Well, it seems like "to be inside LADSPA" is unneeded restriction. > Any JACK-enabled apps will be helpful. My mistake, sorry... The thread > subject was changed. Are you trying to implement a soft modem or other network device as a JACK client? That would be one of the coolest hacks ever... Lee From set at pobox.com Mon Mar 13 00:23:38 2006 From: set at pobox.com (Paul) Date: Mon Mar 13 00:23:43 2006 Subject: [linux-audio-dev] Re: Letter to kernel developers? In-Reply-To: <1142202039.25358.183.camel@mindpipe> References: <1142202039.25358.183.camel@mindpipe> Message-ID: <20060313052338.GH7375@squish.home.loc> Lee Revell , on Sun Mar 12, 2006 [05:20:38 PM] said: > Can someone please help me find a link to the open letter to kernel > developers regarding horrible latency with kernel 2.6 that Paul Davis, > Benno Sennoner and others posted to LKML in early 2004 (NOT the one from > 2000) - the one that led Ingo to develop the voluntary preemption > patches. > > I cannot find it with any amount of googling, and my local LKML archive > only starts in July 2004. > > There was such a letter right? Am I crazy or just making this up? > > Lee > > Hi; Are these the threads you are refering to? 2.6.X, NPTL, SCHED_FIFO and JACK : http://lkml.org/lkml/2004/6/30/104 (In my archive; which consists only of posts I have read on lkml, this is the first for Paul Davis in 2004, after that it mostly seems to be responses to Ingos patchs.) [announce] [patch] Voluntary Kernel Preemption Patch : http://www.ussg.iu.edu/hypermail/linux/kernel/0407.1/0377.html Paul set@pobox.com From a at gaydenko.com Mon Mar 13 00:33:44 2006 From: a at gaydenko.com (Andrew Gaydenko) Date: Mon Mar 13 00:33:49 2006 Subject: [linux-audio-dev] Re: Amplitude (de)modulation with JACK (was "with LADSPA") In-Reply-To: References: <200603130511.59700@goldspace.net> <200603130550.05574@goldspace.net> Message-ID: <200603130833.44608@goldspace.net> I have tried om, but (it's strange) qjackctl 'Connections' window doesn't show om server, while 'Messages' window says about new connection. ======= On Monday 13 March 2006 07:43, Loki Davison wrote: ======= Just putting together ladspas with om should be the right tool for the job. Loki From rlrevell at joe-job.com Mon Mar 13 00:34:15 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Mon Mar 13 00:34:35 2006 Subject: [linux-audio-dev] Re: Letter to kernel developers? In-Reply-To: <20060313052338.GH7375@squish.home.loc> References: <1142202039.25358.183.camel@mindpipe> <20060313052338.GH7375@squish.home.loc> Message-ID: <1142228055.25358.288.camel@mindpipe> On Mon, 2006-03-13 at 00:23 -0500, Paul wrote: > Are these the threads you are refering to? > > 2.6.X, NPTL, SCHED_FIFO and JACK : > http://lkml.org/lkml/2004/6/30/104 I was looking for the thread(s) referenced in the above message: "Because of the recognition by kernel developers that 2.6 does not perform as well as 2.4+lowlat (the Andrew Morton patches) when it comes to scheduling latency, most audio developers and users have remained with 2.4. Recently however, several brave souls have attempted to test 2.6. The results have been mixed." Lee From a at gaydenko.com Mon Mar 13 00:36:51 2006 From: a at gaydenko.com (Andrew Gaydenko) Date: Mon Mar 13 00:36:54 2006 Subject: [linux-audio-dev] Amplitude (de)modulation with JACK (was "with LADSPA") In-Reply-To: <1142225657.25358.281.camel@mindpipe> References: <200603130511.59700@goldspace.net> <200603130550.05574@goldspace.net> <1142225657.25358.281.camel@mindpipe> Message-ID: <200603130836.51419@goldspace.net> No :-) I try to do something to detect memory distortions: http://peufeu.free.fr/audio/memory/ But this is OT for this list probably. ======= On Monday 13 March 2006 07:54, Lee Revell wrote: ======= ... Are you trying to implement a soft modem or other network device as a JACK client? That would be one of the coolest hacks ever... Lee From conrad at metadecks.org Mon Mar 13 00:55:45 2006 From: conrad at metadecks.org (Conrad Parker) Date: Mon Mar 13 00:56:36 2006 Subject: [linux-audio-dev] liboggz 0.9.5 Release Message-ID: <20060313055545.GD702@vergenet.net> Oggz 0.9.5 Release ------------------ Oggz comprises liboggz and the command-line tools oggzinfo, oggzdump, oggzdiff, oggzmerge, oggzrip, oggz-scan and oggz-validate. liboggz is a C library providing a simple programming interface for reading and writing Ogg files and streams. Ogg is an interleaving data container developed by Monty at Xiph.Org, originally to support the Ogg Vorbis audio format. This release is available as a source tarball at: http://www.annodex.net/software/liboggz/download/liboggz-0.9.5.tar.gz New in this release: * Fixed and updated Windows (Visual Studio) support - added missing exported symbols, projects for oggz tools. (Alex Krumm-Heller, Silvia Pfeiffer) * Support for OggPCM (Draft 2, Main header) OggPCM is an experimental specification for storing uncompressed PCM audio in Ogg bitstreams. - liboggz: Recognition of OggPCM timestamps, and support for seeking in files that contain OggPCM logical bitstreams. - oggzinfo: Display OggPCM header details - oggzdump, oggzrip: New [--content-type pcm, -c pcm] option to filter on OggPCM - oggz-validate: Validate framing of OggPCM logical bitstreams This version is installed on http://validator.annodex.org/ for online validation of OggPCM files. For more information about OggPCM, see: http://wiki.xiph.org/index.php/OggPCM * ./configure support for large (>2GB) files This version adds build configuration support for large files, allowing liboggz to operate on files >2GB. This version does not introduce any API changes; interfaces such as oggz_tell() continue to use off_t externally. However, sequential reading and validation of large files is now possible. * bug fixes and cleanups: - oggz-validate, oggzmerge, oggzdump, oggz-scan, oggzinfo: handle unknown content types (Ian Malone) - remove deprecated oggzed example - various code and documentation build cleanups About Oggz ---------- Oggz comprises liboggz and the command-line tools oggzinfo, oggzdump, oggzdiff, oggzmerge, oggzrip, oggz-scan and oggz-validate. liboggz supports the flexibility afforded by the Ogg file format while presenting the following API niceties: * Full API documentation * Comprehensive test suite of read, write and seeking behavior. The entire test suite can be run under valgrind if available. * Developed and tested on GNU/Linux, Darwin/MacOSX, Win32 and Symbian OS. May work on other Unix-like systems via GNU autoconf. For Win32: nmake Makefiles, Visual Studio .NET 2003 solution files and Visual C++ 6.0 workspace files are provided in the source distribution. * Strict adherence to the formatting requirements of Ogg bitstreams, to ensure that only valid bitstreams are generated; writes can fail if you try to write illegally structured packets. * A simple, callback based open/read/close or open/write/close interface to raw Ogg files. * Writing automatically interleaves with packet queuing, and provides callback based notification when this queue is empty * A customisable seeking abstraction for seeking on multitrack Ogg data. Seeking works easily and reliably on multitrack and multi-codec streams, and can transparently parse Theora, Speex, Vorbis, FLAC, CMML and Ogg Skeleton headers without requiring linking to those libraries. This allows efficient use on servers and other devices that need to parse and seek within Ogg files, but do not need to do a full media decode. Full documentation of the liboggz API, customization and installation, and mux and demux examples can be read online at: http://www.annodex.net/software/liboggz/html/ Tools ----- The Oggz source tarball also contains the following command-line tools, which are useful for debugging and testing Ogg bitstreams: * oggzinfo: Display information about one or more Ogg files and their bitstreams. * oggzdump: Hexdump packets of an Ogg file, or revert an Ogg file from such a hexdump. * oggzdiff: Hexdump the packets of two Ogg files and output differences. * oggzmerge: Merge Ogg files together, interleaving pages in order of presentation time. * oggzrip: Extract one or more logical bitstreams from an Ogg file. * oggz-scan: Scan an Ogg file and output characteristic landmarks. * oggz-validate: Validate the Ogg framing of one or more files. License ------- Oggz is Free Software, available under a BSD style license. More information is available online at the Oggz homepage: http://www.annodex.net/software/liboggz/ enjoy :) -- Conrad Parker Senior Software Engineer, Continuous Media Web, CSIRO Australia http://www.annodex.net/ http://www.ict.csiro.au/cmweb/ From paul at linuxaudiosystems.com Mon Mar 13 09:01:46 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Mon Mar 13 08:58:22 2006 Subject: [linux-audio-dev] Re: Letter to kernel developers? In-Reply-To: <1142228055.25358.288.camel@mindpipe> References: <1142202039.25358.183.camel@mindpipe> <20060313052338.GH7375@squish.home.loc> <1142228055.25358.288.camel@mindpipe> Message-ID: <1142258506.28481.133.camel@localhost.localdomain> On Mon, 2006-03-13 at 00:34 -0500, Lee Revell wrote: > On Mon, 2006-03-13 at 00:23 -0500, Paul wrote: > > Are these the threads you are refering to? > > > > 2.6.X, NPTL, SCHED_FIFO and JACK : > > http://lkml.org/lkml/2004/6/30/104 > > I was looking for the thread(s) referenced in the above message: > > "Because of the recognition by kernel developers that 2.6 does not > perform as well as 2.4+lowlat (the Andrew Morton patches) when it > comes to scheduling latency, most audio developers and users have > remained with 2.4. Recently however, several brave souls have > attempted to test 2.6. The results have been mixed." it doesn't exist. this was based on private communication with morton, ingo and a couple of other people. From elisa.zwei at googlemail.com Mon Mar 13 09:57:42 2006 From: elisa.zwei at googlemail.com (Tobias Scharnberg) Date: Mon Mar 13 09:57:48 2006 Subject: [linux-audio-dev] OSS, Sound playback too fast Message-ID: <1448f040603130657n7e19a0cci@mail.gmail.com> Hello list, before someone tells me to use ALSA - the AC97 codec on my Arm-Board does not work wit ALSA according to the distributor... so it seems I have to stick with OSS. I opened a 16 bit 44100 wav-file with libsndfile and wrote the PCM to a buffer. Then I configure the card with 16 bit NE, 44100 and with 5 fragments of the size of 2048 bytes. According to the readback values, all data was set by OSS. In my main loop I use SNDCTL_DSP_GETOSPACE to poll the buffer. Whenever it shows free fragments, I write more data to the card. What I experience is that playback is too fast. I can make it slower by reducing the buffer-size or by setting a very high usleep value so that all fragments practically stay free. There is a precompiled madplayer on the device and it plays perfectly... can someone give me a hint what went wrong? Thanks! Tobias From Cedric.Roux at eurecom.fr Mon Mar 13 10:05:40 2006 From: Cedric.Roux at eurecom.fr (Cedric Roux) Date: Mon Mar 13 10:05:47 2006 Subject: [linux-audio-dev] OSS, Sound playback too fast In-Reply-To: <1448f040603130657n7e19a0cci@mail.gmail.com> Message-ID: On Mon, 13 Mar 2006, Tobias Scharnberg wrote: > In my main loop I use SNDCTL_DSP_GETOSPACE to poll the buffer. > Whenever it shows free fragments, I write more data to the card. What > I experience is that playback is too fast. I can make it slower by > reducing the buffer-size or by setting a very high usleep value so > that all > fragments practically stay free. Did you think about using select to check for free space in your device instead of this GETOSPACE method? The polling is not a good way to do it, I think. Maybe you also have the card in non-blocking mode (or the opposite). If you change that, myabe also... Try to avoid the polling method, IMHO. Take care, Cedric. From pshirkey at boosthardware.com Mon Mar 13 23:02:18 2006 From: pshirkey at boosthardware.com (Patrick Shirkey) Date: Mon Mar 13 14:02:30 2006 Subject: [linux-audio-dev] flashing a rom Message-ID: <4416404A.9000304@boosthardware.com> Hi, I'm not sure about the title of this post but maybe someone here can point me in the right direction. First a little background: A friend and I are investing some time and money into a new project over the next few months. The aim is to custom build a hardware device for DJ's using linux software. The device will be similar to a hercules PC DJ or a pioneer mixing desk except it will have onboard usb slots for flash cards. It will be an all in one DJing console which we hope will make life easier for the increasing number of DJ''s who use mp3 or digital files directly from their computers. At the moment we have an old controller which we want to run some tests with. We also would like to modify it to have usb support. However it has a proprietry OS. My question is does anyone here have experience with flashing a rom and advice that might otherwise take me a few bad experiences to learn? Thanks in advance. -- Patrick Shirkey - Boost Hardware Ltd. Http://www.boosthardware.com Http://www.djcj.org/LAU/guide/ - The Linux Audio Users guide ======================================== Apparently upon the beginning of the barrage, the donkey broke discipline and panicked, toppling the cart. At that point, the rockets disconnected from the timer, leaving them strewn around the street. Tethered to the now toppled cart, the donkey was unable to escape before the arrival of U.S. troops. United Press International Rockets on donkeys hit major Baghdad sites By P. MITCHELL PROTHERO Published 11/21/2003 11:13 AM From torbenh at gmx.de Mon Mar 13 16:21:39 2006 From: torbenh at gmx.de (torbenh@gmx.de) Date: Mon Mar 13 16:27:01 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] [ANN] netjack-0.9rc1 In-Reply-To: <1142196626.25358.144.camel@mindpipe> References: <20060311180143.GA3508@mobilat> <20060312130621.GA8751@mobilat> <1142196626.25358.144.camel@mindpipe> Message-ID: <20060313212139.GC8267@mobilat> On Sun, Mar 12, 2006 at 03:50:26PM -0500, Lee Revell wrote: > On Sun, 2006-03-12 at 14:06 +0100, torbenh@gmx.de wrote: > > netjack-0.9rc1 is here... > > endianess issues fixed. tests are underway... > > but if it works for 2 x86 (double swap) it should work for PPC <-> > > x86 > > Why do you use big-endian on the wire, requiring a double swap for x86 > <-> x86? Wouldn't LE make more sense, especially as PPC Macs become > unavailable? well i am not in a position to redefine ntohl and htonl. sorry. -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From rlrevell at joe-job.com Mon Mar 13 16:45:34 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Mon Mar 13 16:45:43 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] [ANN] netjack-0.9rc1 In-Reply-To: <20060313212139.GC8267@mobilat> References: <20060311180143.GA3508@mobilat> <20060312130621.GA8751@mobilat> <1142196626.25358.144.camel@mindpipe> <20060313212139.GC8267@mobilat> Message-ID: <1142286335.13256.54.camel@mindpipe> On Mon, 2006-03-13 at 22:21 +0100, torbenh@gmx.de wrote: > On Sun, Mar 12, 2006 at 03:50:26PM -0500, Lee Revell wrote: > > On Sun, 2006-03-12 at 14:06 +0100, torbenh@gmx.de wrote: > > > netjack-0.9rc1 is here... > > > endianess issues fixed. tests are underway... > > > but if it works for 2 x86 (double swap) it should work for PPC <-> > > > x86 > > > > Why do you use big-endian on the wire, requiring a double swap for x86 > > <-> x86? Wouldn't LE make more sense, especially as PPC Macs become > > unavailable? > > well i am not in a position to redefine ntohl and htonl. > sorry. > Sorry, my question was stupid - obviously I've been away from networking for a while ;-) From paul at linuxaudiosystems.com Mon Mar 13 17:03:07 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Mon Mar 13 16:59:40 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] [ANN] netjack-0.9rc1 In-Reply-To: <1142286335.13256.54.camel@mindpipe> References: <20060311180143.GA3508@mobilat> <20060312130621.GA8751@mobilat> <1142196626.25358.144.camel@mindpipe> <20060313212139.GC8267@mobilat> <1142286335.13256.54.camel@mindpipe> Message-ID: <1142287387.28481.178.camel@localhost.localdomain> On Mon, 2006-03-13 at 16:45 -0500, Lee Revell wrote: > On Mon, 2006-03-13 at 22:21 +0100, torbenh@gmx.de wrote: > > On Sun, Mar 12, 2006 at 03:50:26PM -0500, Lee Revell wrote: > > > On Sun, 2006-03-12 at 14:06 +0100, torbenh@gmx.de wrote: > > > > netjack-0.9rc1 is here... > > > > endianess issues fixed. tests are underway... > > > > but if it works for 2 x86 (double swap) it should work for PPC <-> > > > > x86 > > > > > > Why do you use big-endian on the wire, requiring a double swap for x86 > > > <-> x86? Wouldn't LE make more sense, especially as PPC Macs become > > > unavailable? > > > > well i am not in a position to redefine ntohl and htonl. > > sorry. > > > > Sorry, my question was stupid - obviously I've been away from networking > for a while ;-) its not a stupid question. and it really isn't hard to write functions which could be called htobe and betoh, for example. From fons.adriaensen at skynet.be Mon Mar 13 17:10:48 2006 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Mon Mar 13 17:03:59 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] [ANN] netjack-0.9rc1 In-Reply-To: <20060313212139.GC8267@mobilat> References: <20060311180143.GA3508@mobilat> <20060312130621.GA8751@mobilat> <1142196626.25358.144.camel@mindpipe> <20060313212139.GC8267@mobilat> Message-ID: <20060313221048.GC5478@linux-1> On Mon, Mar 13, 2006 at 10:21:39PM +0100, torbenh@gmx.de wrote: > On Sun, Mar 12, 2006 at 03:50:26PM -0500, Lee Revell wrote: > > > Why do you use big-endian on the wire, requiring a double swap for x86 > > <-> x86? Wouldn't LE make more sense, especially as PPC Macs become > > unavailable? > > well i am not in a position to redefine ntohl and htonl. Is it true on the common platforms that using ntohl and htonl on floats will always result in compatible data on the wire or in a file ? In other words, are floats byte-swapped consistently w.r.t. the Intel format on all big-endian systems ? -- FA From paul at linuxaudiosystems.com Mon Mar 13 17:25:04 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Mon Mar 13 17:22:16 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] [ANN] netjack-0.9rc1 In-Reply-To: <20060313221048.GC5478@linux-1> References: <20060311180143.GA3508@mobilat> <20060312130621.GA8751@mobilat> <1142196626.25358.144.camel@mindpipe> <20060313212139.GC8267@mobilat> <20060313221048.GC5478@linux-1> Message-ID: <1142288705.28481.180.camel@localhost.localdomain> On Mon, 2006-03-13 at 23:10 +0100, fons adriaensen wrote: > On Mon, Mar 13, 2006 at 10:21:39PM +0100, torbenh@gmx.de wrote: > > > On Sun, Mar 12, 2006 at 03:50:26PM -0500, Lee Revell wrote: > > > > > Why do you use big-endian on the wire, requiring a double swap for x86 > > > <-> x86? Wouldn't LE make more sense, especially as PPC Macs become > > > unavailable? > > > > well i am not in a position to redefine ntohl and htonl. > > Is it true on the common platforms that using ntohl and htonl on > floats will always result in compatible data on the wire or in a > file ? In other words, are floats byte-swapped consistently w.r.t. > the Intel format on all big-endian systems ? network byte order was defined to be big-endian in the early 1980s. those two functions create big-endian 32 bit representations regardless of the host platform. --p From fons.adriaensen at skynet.be Mon Mar 13 17:40:04 2006 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Mon Mar 13 17:33:19 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] [ANN] netjack-0.9rc1 In-Reply-To: <1142288705.28481.180.camel@localhost.localdomain> References: <20060311180143.GA3508@mobilat> <20060312130621.GA8751@mobilat> <1142196626.25358.144.camel@mindpipe> <20060313212139.GC8267@mobilat> <20060313221048.GC5478@linux-1> <1142288705.28481.180.camel@localhost.localdomain> Message-ID: <20060313224004.GD5478@linux-1> On Mon, Mar 13, 2006 at 05:25:04PM -0500, Paul Davis wrote: > On Mon, 2006-03-13 at 23:10 +0100, fons adriaensen wrote: > > Is it true on the common platforms that using ntohl and htonl on > > floats will always result in compatible data on the wire or in a > > file ? In other words, are floats byte-swapped consistently w.r.t. > > the Intel format on all big-endian systems ? > > network byte order was defined to be big-endian in the early 1980s. > those two functions create big-endian 32 bit representations regardless > of the host platform. That much I know, so let me rephrase the question: is network byte order also defined for single precision IEEE floats ? If not, is there a de facto standard ? -- FA Follie! Follie delirio vano e' questo! From rlrevell at joe-job.com Mon Mar 13 17:38:31 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Mon Mar 13 17:38:38 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] [ANN] netjack-0.9rc1 In-Reply-To: <20060313224004.GD5478@linux-1> References: <20060311180143.GA3508@mobilat> <20060312130621.GA8751@mobilat> <1142196626.25358.144.camel@mindpipe> <20060313212139.GC8267@mobilat> <20060313221048.GC5478@linux-1> <1142288705.28481.180.camel@localhost.localdomain> <20060313224004.GD5478@linux-1> Message-ID: <1142289512.13256.63.camel@mindpipe> Can LAU be removed from further replies? On Mon, 2006-03-13 at 23:40 +0100, fons adriaensen wrote: > On Mon, Mar 13, 2006 at 05:25:04PM -0500, Paul Davis wrote: > > On Mon, 2006-03-13 at 23:10 +0100, fons adriaensen wrote: > > > Is it true on the common platforms that using ntohl and htonl on > > > floats will always result in compatible data on the wire or in a > > > file ? In other words, are floats byte-swapped consistently w.r.t. > > > the Intel format on all big-endian systems ? > > > > network byte order was defined to be big-endian in the early 1980s. > > those two functions create big-endian 32 bit representations regardless > > of the host platform. > > That much I know, so let me rephrase the question: is network byte order > also defined for single precision IEEE floats ? If not, is there a de > facto standard ? > From steve at k-hornz.de Mon Mar 13 17:59:15 2006 From: steve at k-hornz.de (stefan kersten) Date: Mon Mar 13 17:58:04 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] [ANN] netjack-0.9rc1 In-Reply-To: <20060313224004.GD5478@linux-1> References: <20060311180143.GA3508@mobilat> <20060312130621.GA8751@mobilat> <1142196626.25358.144.camel@mindpipe> <20060313212139.GC8267@mobilat> <20060313221048.GC5478@linux-1> <1142288705.28481.180.camel@localhost.localdomain> <20060313224004.GD5478@linux-1> Message-ID: <20060313225915.GH3630@localdomain> On Mon, Mar 13, 2006 at 11:40:04PM +0100, fons adriaensen wrote: > On Mon, Mar 13, 2006 at 05:25:04PM -0500, Paul Davis wrote: > > On Mon, 2006-03-13 at 23:10 +0100, fons adriaensen wrote: > > > Is it true on the common platforms that using ntohl and htonl on > > > floats will always result in compatible data on the wire or in a > > > file ? In other words, are floats byte-swapped consistently w.r.t. > > > the Intel format on all big-endian systems ? > > > > network byte order was defined to be big-endian in the early 1980s. > > those two functions create big-endian 32 bit representations regardless > > of the host platform. > > That much I know, so let me rephrase the question: is network byte order > also defined for single precision IEEE floats ? If not, is there a de > facto standard ? as paul stated, network byte order is defined to be big-endian, so yes, you have to convert 32 bit floats (and doubles, for that matter) on intel, because they are stored lsb first. of course it would be perfectly valid for netjack to use little endian `on the wire'; but this would be like putting my powerbook in little endian mode when playing a wav file. sort of. From fons.adriaensen at skynet.be Mon Mar 13 18:21:40 2006 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Mon Mar 13 18:14:45 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] [ANN] netjack-0.9rc1 In-Reply-To: <20060313225915.GH3630@localdomain> References: <20060311180143.GA3508@mobilat> <20060312130621.GA8751@mobilat> <1142196626.25358.144.camel@mindpipe> <20060313212139.GC8267@mobilat> <20060313221048.GC5478@linux-1> <1142288705.28481.180.camel@localhost.localdomain> <20060313224004.GD5478@linux-1> <20060313225915.GH3630@localdomain> Message-ID: <20060313232140.GE5478@linux-1> On Mon, Mar 13, 2006 at 11:59:15PM +0100, stefan kersten wrote: > as paul stated, network byte order is defined to be > big-endian, so yes, you have to convert 32 bit floats (and > doubles, for that matter) on intel, because they are stored > lsb first. of course it would be perfectly valid for netjack > to use little endian `on the wire'; but this would be like > putting my powerbook in little endian mode when playing a > wav file. sort of. OK, but for floats the situation could be more complex. On Intel, the exponent/sign byte is the last one. Is it always the first one on BE platforms ? If it isn't then using ntohl() or htonl() wich are designed to work on 32-bit ints will not help. For doubles, things are even more fuzzy. Can you just use ntohl() and htonl() on both halves, or do these two have to be swapped as well ? Will either rule produce consistent results on all platforms ? -- FA Follie ! Follie delirio vano e' questo ! From paul at linuxaudiosystems.com Mon Mar 13 18:37:41 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Mon Mar 13 18:34:15 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] [ANN] netjack-0.9rc1 In-Reply-To: <20060313232140.GE5478@linux-1> References: <20060311180143.GA3508@mobilat> <20060312130621.GA8751@mobilat> <1142196626.25358.144.camel@mindpipe> <20060313212139.GC8267@mobilat> <20060313221048.GC5478@linux-1> <1142288705.28481.180.camel@localhost.localdomain> <20060313224004.GD5478@linux-1> <20060313225915.GH3630@localdomain> <20060313232140.GE5478@linux-1> Message-ID: <1142293061.28481.191.camel@localhost.localdomain> On Tue, 2006-03-14 at 00:21 +0100, fons adriaensen wrote: > On Mon, Mar 13, 2006 at 11:59:15PM +0100, stefan kersten wrote: > > > as paul stated, network byte order is defined to be > > big-endian, so yes, you have to convert 32 bit floats (and > > doubles, for that matter) on intel, because they are stored > > lsb first. of course it would be perfectly valid for netjack > > to use little endian `on the wire'; but this would be like > > putting my powerbook in little endian mode when playing a > > wav file. sort of. > > OK, but for floats the situation could be more complex. On Intel, > the exponent/sign byte is the last one. Is it always the first > one on BE platforms ? If it isn't then using ntohl() or htonl() > wich are designed to work on 32-bit ints will not help. > > For doubles, things are even more fuzzy. Can you just use ntohl() > and htonl() on both halves, or do these two have to be swapped as > well ? Will either rule produce consistent results on all > platforms ? i don't believe that "network order" is defined for floats, but one could reasonably assume it was the same big-endian ordering. however, since the IEEE spec crosses 8 bit boundaries (IIRC), simply using *to* isn't going to work. i think this applies also to doubles. ntohf and htonf would be required, i think. From steve at k-hornz.de Mon Mar 13 19:15:31 2006 From: steve at k-hornz.de (stefan kersten) Date: Mon Mar 13 19:14:22 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] [ANN] netjack-0.9rc1 In-Reply-To: <20060313232140.GE5478@linux-1> References: <20060311180143.GA3508@mobilat> <20060312130621.GA8751@mobilat> <1142196626.25358.144.camel@mindpipe> <20060313212139.GC8267@mobilat> <20060313221048.GC5478@linux-1> <1142288705.28481.180.camel@localhost.localdomain> <20060313224004.GD5478@linux-1> <20060313225915.GH3630@localdomain> <20060313232140.GE5478@linux-1> Message-ID: <20060314001531.GK3630@localdomain> On Tue, Mar 14, 2006 at 12:21:40AM +0100, fons adriaensen wrote: > OK, but for floats the situation could be more complex. On > Intel, the exponent/sign byte is the last one. Is it > always the first one on BE platforms ? If it isn't then > using ntohl() or htonl() wich are designed to work on > 32-bit ints will not help. IEEE 754 defines the layout of a single float: 1 | 8 | 23 | s | e | f | |msbit lsbit|msbit lsbit| from which i'd say the byte order can be derived. the sign/exponent is in the msb, so it's stored first on BE and last on LE machines. > For doubles, things are even more fuzzy. Can you just use > ntohl() and htonl() on both halves, or do these two have > to be swapped as well ? Will either rule produce > consistent results on all platforms ? doubles are defined similarly; to convert between LE and BE you have to reverse the bytes or equivalently swap the reversed 32-bit words. From mle+la at mega-nerd.com Tue Mar 14 02:00:35 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Tue Mar 14 02:00:44 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] [ANN] netjack-0.9rc1 In-Reply-To: <20060313232140.GE5478@linux-1> References: <20060311180143.GA3508@mobilat> <20060312130621.GA8751@mobilat> <1142196626.25358.144.camel@mindpipe> <20060313212139.GC8267@mobilat> <20060313221048.GC5478@linux-1> <1142288705.28481.180.camel@localhost.localdomain> <20060313224004.GD5478@linux-1> <20060313225915.GH3630@localdomain> <20060313232140.GE5478@linux-1> Message-ID: <20060314180035.03f4722f.mle+la@mega-nerd.com> fons adriaensen wrote: > OK, but for floats the situation could be more complex. In libsndfile I use a 32 bit end swapper on floats and a 64 bit endswapper on doubles. > Will either rule produce consistent results on all > platforms ? The above does produce consistent results across platforms (tested on x86, ia64, ppc and mips). Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ Oh my god! They killed init! You bastards! From torbenh at gmx.de Tue Mar 14 13:39:36 2006 From: torbenh at gmx.de (torbenh@gmx.de) Date: Tue Mar 14 13:44:26 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] [ANN] netjack-0.9rc1 In-Reply-To: <20060313232140.GE5478@linux-1> References: <20060311180143.GA3508@mobilat> <20060312130621.GA8751@mobilat> <1142196626.25358.144.camel@mindpipe> <20060313212139.GC8267@mobilat> <20060313221048.GC5478@linux-1> <1142288705.28481.180.camel@localhost.localdomain> <20060313224004.GD5478@linux-1> <20060313225915.GH3630@localdomain> <20060313232140.GE5478@linux-1> Message-ID: <20060314183936.GA8077@mobilat> On Tue, Mar 14, 2006 at 12:21:40AM +0100, fons adriaensen wrote: > On Mon, Mar 13, 2006 at 11:59:15PM +0100, stefan kersten wrote: > > > as paul stated, network byte order is defined to be > > big-endian, so yes, you have to convert 32 bit floats (and > > doubles, for that matter) on intel, because they are stored > > lsb first. of course it would be perfectly valid for netjack > > to use little endian `on the wire'; but this would be like > > putting my powerbook in little endian mode when playing a > > wav file. sort of. > > OK, but for floats the situation could be more complex. On Intel, > the exponent/sign byte is the last one. Is it always the first > one on BE platforms ? If it isn't then using ntohl() or htonl() > wich are designed to work on 32-bit ints will not help. the current netjack code for converting the floats is tested. it works. at least for PPC <-> intel i only added the packet header after that test, and robert did not yet test it again. > > For doubles, things are even more fuzzy. Can you just use ntohl() > and htonl() on both halves, or do these two have to be swapped as > well ? Will either rule produce consistent results on all > platforms ? i am happy, that i dont need to transfer doubles :) -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From torbenh at gmx.de Tue Mar 14 13:56:47 2006 From: torbenh at gmx.de (torbenh@gmx.de) Date: Tue Mar 14 14:01:40 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] [ANN] netjack-0.9rc1 In-Reply-To: <20060313225915.GH3630@localdomain> References: <20060311180143.GA3508@mobilat> <20060312130621.GA8751@mobilat> <1142196626.25358.144.camel@mindpipe> <20060313212139.GC8267@mobilat> <20060313221048.GC5478@linux-1> <1142288705.28481.180.camel@localhost.localdomain> <20060313224004.GD5478@linux-1> <20060313225915.GH3630@localdomain> Message-ID: <20060314185647.GB8077@mobilat> On Mon, Mar 13, 2006 at 11:59:15PM +0100, stefan kersten wrote: > On Mon, Mar 13, 2006 at 11:40:04PM +0100, fons adriaensen wrote: > > On Mon, Mar 13, 2006 at 05:25:04PM -0500, Paul Davis wrote: > > > On Mon, 2006-03-13 at 23:10 +0100, fons adriaensen wrote: > > > > Is it true on the common platforms that using ntohl and htonl on > > > > floats will always result in compatible data on the wire or in a > > > > file ? In other words, are floats byte-swapped consistently w.r.t. > > > > the Intel format on all big-endian systems ? > > > > > > network byte order was defined to be big-endian in the early 1980s. > > > those two functions create big-endian 32 bit representations regardless > > > of the host platform. > > > > That much I know, so let me rephrase the question: is network byte order > > also defined for single precision IEEE floats ? If not, is there a de > > facto standard ? > > as paul stated, network byte order is defined to be > big-endian, so yes, you have to convert 32 bit floats (and > doubles, for that matter) on intel, because they are stored > lsb first. of course it would be perfectly valid for netjack > to use little endian `on the wire'; but this would be like > putting my powerbook in little endian mode when playing a > wav file. sort of. so you say that i should not htonl the floats i copy from my net buffer to the jack-port ? i doubt, this is a great performance impact. when i change the packet format next time, i could change that to byte swap on a PPC. but considering that PPCs are generally slower than x86 nowadays, this would create more cpu load on a jack-network. i am puzzled. did anybody actually test it ? well at least there is some netjack thread now :/ -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From rlrevell at joe-job.com Tue Mar 14 14:13:59 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Tue Mar 14 14:14:16 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] [ANN] netjack-0.9rc1 In-Reply-To: <20060314185647.GB8077@mobilat> References: <20060311180143.GA3508@mobilat> <20060312130621.GA8751@mobilat> <1142196626.25358.144.camel@mindpipe> <20060313212139.GC8267@mobilat> <20060313221048.GC5478@linux-1> <1142288705.28481.180.camel@localhost.localdomain> <20060313224004.GD5478@linux-1> <20060313225915.GH3630@localdomain> <20060314185647.GB8077@mobilat> Message-ID: <1142363640.13256.149.camel@mindpipe> On Tue, 2006-03-14 at 19:56 +0100, torbenh@gmx.de wrote: > so you say that i should not htonl the floats i copy from my net > buffer > to the jack-port ? > i doubt, this is a great performance impact. > These were just suggestions... of course the performance impact is small. But when a code path will be called on every sample then even a 0.01% speedup is worthwhile. > when i change the packet format next time, i could change that to byte > swap on a PPC. but considering that PPCs are generally slower than x86 > nowadays, this would create more cpu load on a jack-network. > > i am puzzled. did anybody actually test it ? > well at least there is some netjack thread now :/ > Well, you did post your announcement to a development list - if you only wanted testers you should have only sent to LAU ;-) Lee From torbenh at gmx.de Tue Mar 14 14:25:22 2006 From: torbenh at gmx.de (torbenh@gmx.de) Date: Tue Mar 14 14:30:12 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] [ANN] netjack-0.9rc1 In-Reply-To: <1142363640.13256.149.camel@mindpipe> References: <20060311180143.GA3508@mobilat> <20060312130621.GA8751@mobilat> <1142196626.25358.144.camel@mindpipe> <20060313212139.GC8267@mobilat> <20060313221048.GC5478@linux-1> <1142288705.28481.180.camel@localhost.localdomain> <20060313224004.GD5478@linux-1> <20060313225915.GH3630@localdomain> <20060314185647.GB8077@mobilat> <1142363640.13256.149.camel@mindpipe> Message-ID: <20060314192522.GA8166@mobilat> On Tue, Mar 14, 2006 at 02:13:59PM -0500, Lee Revell wrote: > On Tue, 2006-03-14 at 19:56 +0100, torbenh@gmx.de wrote: > > so you say that i should not htonl the floats i copy from my net > > buffer > > to the jack-port ? > > i doubt, this is a great performance impact. > > > > These were just suggestions... of course the performance impact is > small. But when a code path will be called on every sample then even a > 0.01% speedup is worthwhile. well i dont think, that doing something simple with the data being copied does cost anything. you can prove me wrong though... the memory is the bottleneck. or is this pathetic because of 98% cache hits ? > > > when i change the packet format next time, i could change that to byte > > swap on a PPC. but considering that PPCs are generally slower than x86 > > nowadays, this would create more cpu load on a jack-network. > > > > i am puzzled. did anybody actually test it ? > > well at least there is some netjack thread now :/ > > > > Well, you did post your announcement to a development list - if you only > wanted testers you should have only sent to LAU ;-) :) that explains it.... > > Lee > -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From steve at k-hornz.de Tue Mar 14 14:38:23 2006 From: steve at k-hornz.de (stefan kersten) Date: Tue Mar 14 14:37:08 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] [ANN] netjack-0.9rc1 In-Reply-To: <20060314185647.GB8077@mobilat> References: <20060311180143.GA3508@mobilat> <20060312130621.GA8751@mobilat> <1142196626.25358.144.camel@mindpipe> <20060313212139.GC8267@mobilat> <20060313221048.GC5478@linux-1> <1142288705.28481.180.camel@localhost.localdomain> <20060313224004.GD5478@linux-1> <20060313225915.GH3630@localdomain> <20060314185647.GB8077@mobilat> Message-ID: <20060314193823.GI27335@localdomain> On Tue, Mar 14, 2006 at 07:56:47PM +0100, torbenh@gmx.de wrote: > > course it would be perfectly valid for netjack > > to use little endian `on the wire'; but this would be like > > putting my powerbook in little endian mode when playing a > > wav file. sort of. > > so you say that i should not htonl the floats i copy from > my net buffer to the jack-port ? no, it was a joke. > i doubt, this is a great performance impact. i doubt that too. > when i change the packet format next time, i could change that to byte > swap on a PPC. but considering that PPCs are generally slower than x86 > nowadays, this would create more cpu load on a jack-network. i don't think that's measurable either because the byte swap is probably not the main source of overhead. besides, i'm on ppc, so plz plz don't change it :) thanks for netjack! From arnold.krille at gmail.com Tue Mar 14 15:02:45 2006 From: arnold.krille at gmail.com (Arnold Krille) Date: Tue Mar 14 15:02:52 2006 Subject: [linux-audio-dev] Re: Call for help for LinuxTag2006 In-Reply-To: <2def88b80601120241u7af0baeev@mail.gmail.com> References: <2def88b80601120241u7af0baeev@mail.gmail.com> Message-ID: <2def88b80603141202g25c32a12m@mail.gmail.com> Dear Sir or Madam, I am Arnold Krille, the leader of this years upcoming LA-booth at LinuxTag06 in Wiesbaden, Germany. Please accept my apologies for getting this mail if you are already part of our team. Otherwise I would like to lay before you a proposal which will clearly be of much interest for you: For some years the LinuxTag e.V., a non-profit organisation promoting our beloved free os, organises a yearly meeting of free projects and software-business at a conference in Germany. It is the largest of this kind in Europe, thats at least what they say. The Linux Audio Community always had an exhibition booth at this conference for the last years and everyone of our members recognized it as a great fun and learning event. To continue this story of fortune I humbly seek your help to be a part in this years team of the LA-booth. We will give you the opportunity to show the world what apps for making music with Linux are out there and explain your choice of os to the visitors. The LinuxTag will take place from 3. to 6. May in Wiesbaden. Please note that this is just the week after the Linux Audio Conference in Karlsruhe and gives you the opportunity to attend to both meetings and have a couple of days of holiday in between. Please contact me for further details. Yours, Arnold -- visit http://dillenburg.dyndns.org/~arnold/ --- Wenn man mit Raubkopien Bands wie Brosis oder Britney Spears wirklich verhindern k?nnte, w?rde ich mir noch heute einen Stapel Brenner und einen Sack Rohlinge kaufen. From elisa.zwei at googlemail.com Wed Mar 15 04:12:09 2006 From: elisa.zwei at googlemail.com (Tobias Scharnberg) Date: Wed Mar 15 04:12:15 2006 Subject: [linux-audio-dev] OSS, Sound playback too fast In-Reply-To: References: <1448f040603130657n7e19a0cci@mail.gmail.com> Message-ID: <1448f040603150112ne03dee6r@mail.gmail.com> Hey Cedric, thanks for your reply. My problem is solved so far. I made a very dumb fault in buffer conversion - its working now. Thanks for the heads up with polling. I will think about that. Tobias 2006/3/13, Cedric Roux : > Did you think about using select to check for free space in your > device instead of this GETOSPACE method? > > The polling is not a good way to do it, I think. > > Maybe you also have the card in non-blocking mode (or the opposite). > If you change that, myabe also... > > Try to avoid the polling method, IMHO. > > Take care, > Cedric. From elisa.zwei at googlemail.com Wed Mar 15 04:17:49 2006 From: elisa.zwei at googlemail.com (Tobias Scharnberg) Date: Wed Mar 15 04:17:54 2006 Subject: [linux-audio-dev] OSS, Line in directly to Line out? Message-ID: <1448f040603150117id327c52m@mail.gmail.com> Hello List, this might really be a dumb question, but anyway: When I have an Audio-Source on Line-In or MIC, what do I have to do to directly output it to LineOut? Is it possible to directly put it through by using /dev/mixer ? Or do I have to record the Line-In audiostream in a buffer and then read from the buffer for output? At least duplex capability is given in my device! And: I really can't use ALSA for that device, which is a shame. Any hints or suggestions are highly welcome. Tobias From mista.tapas at gmx.net Wed Mar 15 05:23:48 2006 From: mista.tapas at gmx.net (Florian Schmidt) Date: Wed Mar 15 05:23:51 2006 Subject: [linux-audio-dev] OSS, Line in directly to Line out? In-Reply-To: <1448f040603150117id327c52m@mail.gmail.com> References: <1448f040603150117id327c52m@mail.gmail.com> Message-ID: <20060315112348.3884b91d@mango.fruits> On Wed, 15 Mar 2006 10:17:49 +0100 "Tobias Scharnberg" wrote: > Hello List, > this might really be a dumb question, but anyway: When I have an > Audio-Source on Line-In or MIC, what do I have to do to directly > output it to LineOut? > > Is it possible to directly put it through by using /dev/mixer ? Or do > I have to record the Line-In audiostream in a buffer and then read > from the buffer for output? At least duplex capability is given in my > device! > > And: I really can't use ALSA for that device, which is a shame. It depends on whether the soundcard supports this. Usually on comsumer grade hw you do have the option to route the analog line input directly to the analog line output. I just don't have an idea on how to do this with OSS. In ALSA you just go the playback page of the mixer and pull up the line-in fader there (which is distinct from the line-in fader in the recording page of the mixer, which determines the level of input when actually recording from that line in). Flo -- Palimm Palimm! http://tapas.affenbande.org From cmatt77 at gmail.com Wed Mar 15 09:48:02 2006 From: cmatt77 at gmail.com (muzak24h) Date: Wed Mar 15 09:48:06 2006 Subject: [linux-audio-dev] CLI wanted - Need PCM to generic SBout on Smoothwall-2 stock kernel Message-ID: <3416839.post@talk.nabble.com> 3 reasons I am posting here: - There are millions of DIY Linux firewalls running on light-kernels (Smoothwall alone reports > million active installs) with no generic Sound blaster support. - Most users, even Linux CLI familiar like myself, will not trade security to swap a kernel on a firewall and break the update mechanism that keeps things secure. - These millions of firewalls have CPU cycles to spare and sit around waisting power and many users would like a way to do audio out. I have posted over a year ago on the SW - UK forum and many are interested and waiting. What is needed: - PIC timer-based code (8259 chip?) to ouput wav direct to SB-out with CLI parms to set generic SB volume, filename, and loop option. Perhaps I'm asking for too much? - Maybe, even pointers in the right direction would help. In fact, if this is easy... just post it in "homebrew mods" at smoothwall.org's community forum. - I will take positive responses here, and duely credit them - This is for everyone! -- View this message in context: http://www.nabble.com/CLI-wanted---Need-PCM-to-generic-SBout-on-Smoothwall-2-stock-kernel-t1284975.html#a3416839 Sent from the linux-audio-dev forum at Nabble.com. From rlrevell at joe-job.com Wed Mar 15 12:20:11 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Mar 15 12:20:19 2006 Subject: [linux-audio-dev] CLI wanted - Need PCM to generic SBout on Smoothwall-2 stock kernel In-Reply-To: <3416839.post@talk.nabble.com> References: <3416839.post@talk.nabble.com> Message-ID: <1142443212.1671.14.camel@mindpipe> On Wed, 2006-03-15 at 06:48 -0800, muzak24h wrote: > 3 reasons I am posting here: > - There are millions of DIY Linux firewalls running on light-kernels > (Smoothwall alone reports > million active installs) with no generic Sound > blaster support. > - Most users, even Linux CLI familiar like myself, will not trade security > to swap a kernel on a firewall and break the update mechanism that keeps > things secure. > - These millions of firewalls have CPU cycles to spare and sit around > waisting power and many users would like a way to do audio out. I have > posted over a year ago on the SW - UK forum and many are interested and > waiting. > I don't understand - sound blaster is already supported by ALSA and OSS. If you are running a vendor kernel with no sound support you will have to install a kernel with audio support. There's no way to magically get sound without changing the kernel. > What is needed: > - PIC timer-based code (8259 chip?) to ouput wav direct to SB-out with CLI > parms to set generic SB volume, filename, and loop option. > > Perhaps I'm asking for too much? > - Maybe, even pointers in the right direction would help. In fact, if this > is easy... just post it in "homebrew mods" at smoothwall.org's community > forum. > - I will take positive responses here, and duely credit them - This is for > everyone! > > -- > View this message in context: http://www.nabble.com/CLI-wanted---Need-PCM-to-generic-SBout-on-Smoothwall-2-stock-kernel-t1284975.html#a3416839 > Sent from the linux-audio-dev forum at Nabble.com. > > From cmatt77 at gmail.com Wed Mar 15 13:11:37 2006 From: cmatt77 at gmail.com (muzak24h) Date: Wed Mar 15 13:11:47 2006 Subject: [linux-audio-dev] CLI wanted - Need PCM to generic SBout on Smoothwall-2 stock kernel In-Reply-To: <1142443212.1671.14.camel@mindpipe> References: <3416839.post@talk.nabble.com> <1142443212.1671.14.camel@mindpipe> Message-ID: <3420905.post@talk.nabble.com> Breaking the vendor kernel is not an option, my concern is not to break things (especially updates). However, we have guys on the forum writing code that flashes keyboard LED's to show packets in/out (I'm assuming this writes directly to a port) (it uses sifled) So writing direct to the DSP is not possible? >From geocities dot com /SiliconValley/Park/8933/sound.html , I understand the following: The DSP can be from port 0x210 to 0x260. (there's code to find it) The IRQ number can be found too. (there's code there to find it too) He states the SB can play direct or DMA. Direct is simple but uses a lot of processor time, while DMA mode is limited to transferring data only from lo-ram (first MB). DMA requires a buffer and is limited to 64kb blocks so the wav samples need to be chopped up. Sound Blaster can issue an IRQ each time DMA stops. He sums-up saying that a DMA transfer is: ----------- clip ----------------------- Load the sound data into memory Set the DSP TIME_CONSTANT to the sampling rate Set up the DMA chip for the transfer Write DMA_TYPE_VALUE value to the DSP Write DATA_LENGTH to the DSP (2 bytes, LSB first) where DATA_LENGTH = number of bytes to send - 1 Repeat steps 3, 4, 5 to play all the sample The DSP_TIME_CONSTANT sets the frequency of reproduction, where (BYTE)TIME_CONSTANT = 256 - 1000000 / frequency This method allow a sampling rate of max 22222 Hz (Normal Mode). With SB 2.0 or above, we can have a higher frequency, using High Speed mode. The TIME_COSTANT will be computed in this way: (WORD)TIME_CONSTANT = 65535 - 256000000 / frequency The result is a WORD, but we'll send only the MSB to the DSP. The code of the function to set the sampling rate will be: // Sets the Time Constant // 'frequency'(in): the sampling rate // 'return'(out): result code PRIVATE BOOL driver_set_time_constant(WORD frequency) { if((frequency < driver_capability.min_mono_8) || (frequency > driver_capability.max_mono_8)) return(SB_SAMPLE_RATE); if(frequency > 23 * 1024) { WORD time_constant; time_constant = 65536 - 256000000 / frequency; sb_dsp_write(SB_TIME_COSTANT); sb_dsp_write(time_costant >> 8); driver_use_high_speed = TRUE; } else { BYTE time_constant; time_constant = 256 - 1000000 / frequency; sb_dsp_write(SB_TIME_COSTANT); sb_dsp_write(time_costant); driver_use_high_speed = FALSE; } return(SB_OK); } We can program the DMA chip in this way (assuming that the Sound Blaster use DMA channel 1): Calculate the 20 bit address of the memory buffer you are using where Base Address = Segment * 16 + Offset Send the value 05h to port 0Ah (mask off channel 1) Send the value 00h to port 0Ch (clear the internal DMA flip/flop) Send the value 49h to port 0Bh (for playback) or 45h to port 0Bh (for recording) Write the LSB (bits 0 -> 7) of the 20 bit memory address to port 02h Write the MSB (bits 8 -> 15) of the 20 bit memory address to ort 02h Write the Page (bits 16 -> 19) of the 20 bit memory address to port 83h Send the LSB of DATA_LENGTH to port 03h Send the MSB of DATA_LENGTH to port 03h Send the value 01h to port 0Ah (enable channel 1) ---------- end clip -------------- So can it be done? Is there some factiod I'm not catching? The only thing I can think of is this: IRQ vectors: When the DMA stops, what to do with it in this kind of kernel. Since I can't go to that level in Linux I'm curious... -- View this message in context: http://www.nabble.com/CLI-wanted---Need-PCM-to-generic-SBout-on-Smoothwall-2-stock-kernel-t1284975.html#a3420905 Sent from the linux-audio-dev forum at Nabble.com. From james at dis-dot-dat.net Wed Mar 15 13:30:23 2006 From: james at dis-dot-dat.net (james@dis-dot-dat.net) Date: Wed Mar 15 13:30:18 2006 Subject: [linux-audio-dev] A proposal Message-ID: <20060315183023.GC32457@phlunky.Belkin> Hello all. I've been busy and off the lists for a while and will be for a while, but I just wanted to pass on something that could be very useful/important. Please don't stop reading when you read "Microsoft", "scheme" or "money". I'm not asking for bank details :) There is a scheme for lecturers/researchers working in computer science and its various flavours in developed countries in the EU and USA to travel to developing countries for research or teaching. Microsoft will put up the travel money if the hosting institution will cover living expenses. I think they will supply up to 1,300 pounds. It works a bit like on-line dating - people that want lecturers/researchers sign up, as do lecturers and researchers. Then you see if there's a match and take it from there. So, if you're a lecturer or researcher that feels like taking you skills into developing countries for a week or two, take a look. Also, if you're from an institution in a developing country and would like to have a visiting lecturer/researcher, sign up. You might think this is totally the wrong place (actually, I cross-posted so I should say "places"), but here are my reasons: 0. I know there are a few lecturers/researchers on the list. 1. Very few people have signed up due to poor advertising. This means the money could just not get spent when it could do some real good. It also means that any potential collaborations are very likely to get funded. 2. Microsoft is probably the least favoured company on these lists BUT think of this as a way to get some of their ill-gotten gains spent doing something good. 3. It really does look like a good deal. I can't see any reason to suspect Microsoft are doing anything evil on this one. I'm going to sign myself up - why not join me. Details: http://research.microsoft.com/ero/icd/inspire/ Feel free to ignore this mail, but I'd appreciate not getting flamed ;) James -- "I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you." (By Vance Petree, Virginia Power) From paul at linuxaudiosystems.com Wed Mar 15 13:53:35 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Wed Mar 15 13:50:05 2006 Subject: [linux-audio-dev] CLI wanted - Need PCM to generic SBout on Smoothwall-2 stock kernel In-Reply-To: <3420905.post@talk.nabble.com> References: <3416839.post@talk.nabble.com> <1142443212.1671.14.camel@mindpipe> <3420905.post@talk.nabble.com> Message-ID: <1142448816.11303.15.camel@localhost.localdomain> On Wed, 2006-03-15 at 10:11 -0800, muzak24h wrote: > The DSP can be from port 0x210 to 0x260. (there's code to find it) > The IRQ number can be found too. (there's code there to find it too) controlling a DSP requires writing to registers, not just memory-mapped ports. it also typically requires an IRQ handler. > He states the SB can play direct or DMA. Direct is simple but uses a lot of > processor time, while DMA mode is limited to transferring data only from > lo-ram (first MB). DMA requires a buffer and is limited to 64kb blocks so > the wav samples need to be chopped up. Sound Blaster can issue an IRQ each > time DMA stops. with this particular h/w it might work since most of the registers get mapped. but they only get mapped by a driver that requests that the i/o memory space is allocated. no driver, no mapping. the fact that yes, you can write these from user-space (as root) doesn't help with that. if there is a driver, then you can simply use it. > The result is a WORD, but we'll send only the MSB to the DSP. The code of > the function to set the sampling rate will be: it would be better to keep people who still use terms like WORD should not be allowed near linux kernel code. > IRQ vectors: When the DMA stops, what to do with it in this kind of kernel. > Since I can't go to that level in Linux I'm curious... one the main points of using linux is that, given the skillset, someone can *always* go to that level. --p From rlrevell at joe-job.com Wed Mar 15 14:01:22 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Mar 15 14:01:30 2006 Subject: [linux-audio-dev] CLI wanted - Need PCM to generic SBout on Smoothwall-2 stock kernel In-Reply-To: <3420905.post@talk.nabble.com> References: <3416839.post@talk.nabble.com> <1142443212.1671.14.camel@mindpipe> <3420905.post@talk.nabble.com> Message-ID: <1142449283.1671.27.camel@mindpipe> On Wed, 2006-03-15 at 10:11 -0800, muzak24h wrote: > So can it be done? Is there some factiod I'm not catching? > > The only thing I can think of is this: > IRQ vectors: When the DMA stops, what to do with it in this kind of > kernel. > Since I can't go to that level in Linux I'm curious... The Linux kernel simply does not contain the necessary infrastructure to do DMA and handle interrupts in userspace. Even if your scheme works for DMA you also need periodic interrupts from the sound device to wake up the process when it needs to write or read more data. What's to keep userspace from killing the machine by enabling an interrupt but never ACKing it? And what's to prevent a user from setting up the sound card to DMA some audio samples into a critical kernel data structure? There are people working on the kernel infrastructure needed for 100% userspace drivers but it's not done yet. Your best bet is to convince the vendor to enable audio support in their kernel. Lee From cmatt77 at gmail.com Wed Mar 15 15:05:14 2006 From: cmatt77 at gmail.com (muzak24h) Date: Wed Mar 15 15:05:17 2006 Subject: [linux-audio-dev] CLI wanted - Need PCM to generic SBout on Smoothwall-2 stock kernel In-Reply-To: <1142448816.11303.15.camel@localhost.localdomain> References: <3416839.post@talk.nabble.com> <1142443212.1671.14.camel@mindpipe> <3420905.post@talk.nabble.com> <1142448816.11303.15.camel@localhost.localdomain> Message-ID: <3423082.post@talk.nabble.com> Yeah, I got the WORD (that page was a little *indowish and dated but it did explain the issue of finding I/O and IRQ) I noted also your concern about unanswered IRQ's for DMA turning things into a house of cards - OK... So if the average Smoothwall (MonoWall or IPcop ack!) owner wants to loop a wav file byte-style to an antique SB 2.0 board, would this be serious I/O overhead? Even on a PII-400+? Most of these boxes are being used as over-grown, over-powered DSL routers.. Until now, the only sounds that Smoothwall's can make is are speaker beep tones. See here at the forum. (I've had a SWall for 5-years and it's stabilty has constantly pulled me away from the M$-camp - and I'm getting hooked on Mepis Linux) Any other ideas would be appreciated greatly - Thanks! -- View this message in context: http://www.nabble.com/CLI-wanted---Need-PCM-to-generic-SBout-on-Smoothwall-2-stock-kernel-t1284975.html#a3423082 Sent from the linux-audio-dev forum at Nabble.com. From fbar at footils.org Wed Mar 15 16:26:18 2006 From: fbar at footils.org (Frank Barknecht) Date: Wed Mar 15 16:26:02 2006 Subject: [linux-audio-dev] Fiasco microkernel Message-ID: <20060315212618.GB19148@fliwatut.scifi> Hallo, I just stumbled across this (via heise.de): http://os.inf.tu-dresden.de/fiasco/overview.html What are Fiasco's distinctive features (i.e., buzzwords)? Fiasco is a preemptible real-time kernel supporting hard priorities. It uses non-blocking synchronization for its kernel objects. This guarantees priority inheritance and makes sure that runnable high-priority processes never block waiting for lower-priority processes. When using L4Linux on top of Fiasco, hard-real-time applications can share one machine with time-sharing (Linux) applications. Fiasco is a real, second-generation ?-kernel protecting applications in address spaces. Thanks to its efficient task and context switching mechanism and its performace-oriented design, the performance penalties induced by address-space security are neglible - much smaller than in older, first-generation ?-kernels like Mach. Sounds somehow interesting. Ciao -- Frank Barknecht _ ______footils.org_ __goto10.org__ From rlrevell at joe-job.com Wed Mar 15 16:31:48 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Mar 15 16:31:57 2006 Subject: [linux-audio-dev] Fiasco microkernel In-Reply-To: <20060315212618.GB19148@fliwatut.scifi> References: <20060315212618.GB19148@fliwatut.scifi> Message-ID: <1142458309.1671.55.camel@mindpipe> On Wed, 2006-03-15 at 22:26 +0100, Frank Barknecht wrote: > Sounds somehow interesting. > Not really - I see no advantages over the -rt kernel and a bunch of limitations. Lee From jens.andreasen at chello.se Thu Mar 16 05:59:29 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Thu Mar 16 05:59:37 2006 Subject: [linux-audio-dev] Amplitude (de)modulation with JACK (was "with LADSPA") In-Reply-To: <200603130836.51419@goldspace.net> References: <200603130511.59700@goldspace.net> <200603130550.05574@goldspace.net> <1142225657.25358.281.camel@mindpipe> <200603130836.51419@goldspace.net> Message-ID: <1142506769.9180.4.camel@c80-216-124-251.cm-upc.chello.se> Another possible application (in a slightly different spectrum): http://en.wikipedia.org/wiki/Very_low_frequency On Mon, 2006-03-13 at 08:36 +0300, Andrew Gaydenko wrote: > No :-) I try to do something to detect memory distortions: > > http://peufeu.free.fr/audio/memory/ > > But this is OT for this list probably. > > ======= On Monday 13 March 2006 07:54, Lee Revell wrote: ======= > ... > Are you trying to implement a soft modem or other network device as a > JACK client? That would be one of the coolest hacks ever... > > Lee > > -- From capocasa at gmx.net Thu Mar 16 07:02:44 2006 From: capocasa at gmx.net (Carlo Capocasa) Date: Thu Mar 16 07:03:56 2006 Subject: [linux-audio-dev] Re: Amplitude (de)modulation with JACK (was "with LADSPA") In-Reply-To: <200603130833.44608@goldspace.net> References: <200603130511.59700@goldspace.net> <200603130550.05574@goldspace.net> <200603130833.44608@goldspace.net> Message-ID: You need to create an Om patch with an audio output for it to show up. > I have tried om, but (it's strange) qjackctl 'Connections' window doesn't > show om server, while 'Messages' window says about new connection. From a at gaydenko.com Thu Mar 16 13:26:09 2006 From: a at gaydenko.com (Andrew Gaydenko) Date: Thu Mar 16 13:26:18 2006 Subject: [linux-audio-dev] LADSPA processing: ams, om, ... Anything else? Message-ID: <200603162126.09058@goldspace.net> Are there alternatives for 'ams' and 'om'? My problems are: - 'ams' has not text fields to type-in controls values with needed precision, sliders are not sufficient, - 'om' engine has too many crashes (I see, it is normal, as the app is under development). Anything else? From jesse at essej.net Thu Mar 16 13:49:41 2006 From: jesse at essej.net (Jesse Chappell) Date: Thu Mar 16 13:49:46 2006 Subject: [linux-audio-dev] LADSPA processing: ams, om, ... Anything else? In-Reply-To: <200603162126.09058@goldspace.net> References: <200603162126.09058@goldspace.net> Message-ID: On 3/16/06, Andrew Gaydenko wrote: > Are there alternatives for 'ams' and 'om'? My problems are: > > - 'ams' has not text fields to type-in controls values with needed precision, > sliders are not sufficient, > - 'om' engine has too many crashes (I see, it is normal, as the app is under > development). > > Anything else? Ardour and jack-rack both satisfy your requirements.. jlc From larsl at users.sourceforge.net Thu Mar 16 14:01:49 2006 From: larsl at users.sourceforge.net (Lars Luthman) Date: Thu Mar 16 14:01:55 2006 Subject: [linux-audio-dev] LADSPA processing: ams, om, ... Anything else? In-Reply-To: <200603162126.09058@goldspace.net> References: <200603162126.09058@goldspace.net> Message-ID: <1142535709.12231.16.camel@c213-100-50-8.swipnet.se> On Thu, 2006-03-16 at 21:26 +0300, Andrew Gaydenko wrote: > Are there alternatives for 'ams' and 'om'? My problems are: > > - 'ams' has not text fields to type-in controls values with needed precision, > sliders are not sufficient, > - 'om' engine has too many crashes (I see, it is normal, as the app is under > development). The engine has been rock solid for me for the last month or so (modulo a few bugs that has been fixed quickly). What sort of crashes are you seeing? > Anything else? I think Csound supports LADSPAs. -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- 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/20060316/2ad972aa/attachment.bin From torbenh at gmx.de Thu Mar 16 14:00:55 2006 From: torbenh at gmx.de (torbenh@gmx.de) Date: Thu Mar 16 14:05:40 2006 Subject: [linux-audio-dev] LADSPA processing: ams, om, ... Anything else? In-Reply-To: <200603162126.09058@goldspace.net> References: <200603162126.09058@goldspace.net> Message-ID: <20060316190055.GB8062@mobilat> On Thu, Mar 16, 2006 at 09:26:09PM +0300, Andrew Gaydenko wrote: > Are there alternatives for 'ams' and 'om'? My problems are: > > - 'ams' has not text fields to type-in controls values with needed precision, > sliders are not sufficient, > - 'om' engine has too many crashes (I see, it is normal, as the app is under > development). gAlan. its all there... > > Anything else? > -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From a at gaydenko.com Thu Mar 16 14:14:08 2006 From: a at gaydenko.com (Andrew Gaydenko) Date: Thu Mar 16 14:14:13 2006 Subject: [linux-audio-dev] LADSPA processing: ams, om, ... Anything else? In-Reply-To: References: <200603162126.09058@goldspace.net> Message-ID: <200603162214.08569@goldspace.net> Unfortunately, in case you have, say, 20-30 different plugin instances (non-linear connected), cited (nice and known!) apps are not sutable :-( ======= On Thursday 16 March 2006 21:49, Jesse Chappell wrote: ======= On 3/16/06, Andrew Gaydenko wrote: > Are there alternatives for 'ams' and 'om'? My problems are: > > - 'ams' has not text fields to type-in controls values with needed precision, > sliders are not sufficient, > - 'om' engine has too many crashes (I see, it is normal, as the app is under > development). > > Anything else? Ardour and jack-rack both satisfy your requirements.. jlc From a at gaydenko.com Thu Mar 16 14:21:12 2006 From: a at gaydenko.com (Andrew Gaydenko) Date: Thu Mar 16 14:21:14 2006 Subject: [linux-audio-dev] LADSPA processing: ams, om, ... Anything else? In-Reply-To: <1142535709.12231.16.camel@c213-100-50-8.swipnet.se> References: <200603162126.09058@goldspace.net> <1142535709.12231.16.camel@c213-100-50-8.swipnet.se> Message-ID: <200603162221.12257@goldspace.net> Lars, Segfaults, segfaults... I have not noticed any concrete reproducable step sequence yet, as have tried the app rather shortly. ======= On Thursday 16 March 2006 22:01, Lars Luthman wrote: ======= ... > - 'om' engine has too many crashes (I see, it is normal, as the app is under > development). The engine has been rock solid for me for the last month or so (modulo a few bugs that has been fixed quickly). What sort of crashes are you seeing? ... -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E From S.W.Harris at ecs.soton.ac.uk Thu Mar 16 14:35:40 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Thu Mar 16 14:35:52 2006 Subject: [linux-audio-dev] LADSPA processing: ams, om, ... Anything else? In-Reply-To: <1142535709.12231.16.camel@c213-100-50-8.swipnet.se> References: <200603162126.09058@goldspace.net> <1142535709.12231.16.camel@c213-100-50-8.swipnet.se> Message-ID: <20060316193540.GA17577@login.ecs.soton.ac.uk> On Thu, Mar 16, 2006 at 08:01:49PM +0100, Lars Luthman wrote: > > Anything else? > > I think Csound supports LADSPAs. So do Pd and SpiralSynthModular. - Steve From fbar at footils.org Thu Mar 16 18:22:39 2006 From: fbar at footils.org (Frank Barknecht) Date: Thu Mar 16 18:22:21 2006 Subject: [linux-audio-dev] LADSPA processing: ams, om, ... Anything else? In-Reply-To: <200603162126.09058@goldspace.net> References: <200603162126.09058@goldspace.net> Message-ID: <20060316232239.GU29404@fliwatut.scifi> Hallo, Andrew Gaydenko hat gesagt: // Andrew Gaydenko wrote: > Are there alternatives for 'ams' and 'om'? My problems are: > > - 'ams' has not text fields to type-in controls values with needed precision, > sliders are not sufficient, > - 'om' engine has too many crashes (I see, it is normal, as the app is under > development). > > Anything else? Pd. It will be easy to start for you, as you already know how modular synths work, and Pd generally is rock-stable (if you don't do some of the more exotic things that can crash Pd as well). You may even discover that for many things you don't need LADSPA - or that you can do things, no LADSPA plugin can do yet. The current LADSPA external for Pd called [plugin~] is a bit unusual to use because it doesn't support control names with spaces in it, you have to use a numeric name there, but there are alternatives in development, also you get a [dssi~] external if you want. Pd may not look as pretty, but what it lacks in looks it makes up for in technical merits. Ciao -- Frank Barknecht _ ______footils.org_ __goto10.org__ From kjetil at ccrma.stanford.edu Thu Mar 16 18:30:55 2006 From: kjetil at ccrma.stanford.edu (Kjetil S. Matheussen) Date: Thu Mar 16 18:31:01 2006 Subject: [linux-audio-dev] Re: linux-audio-dev] LADSPA processing: ams, om, ... Anything else? In-Reply-To: <20060316191418.E4297B6B4E3@music.columbia.edu> References: <20060316191418.E4297B6B4E3@music.columbia.edu> Message-ID: Andrew Gaydenko: > Are there alternatives for 'ams' and 'om'? My problems are: > > - 'ams' has not text fields to type-in controls values with needed > precision, sliders are not sufficient, > - 'om' engine has too many crashes (I see, it is normal, as the app is > under development). > > Anything else? PD is probably what you are looking for, http://pure-data.sf.net You can also use SND, but signal routing is text-based, http://ccrma.stanford.edu/software/snd/ http://www.notam02.no/arkiv/doc/snd-rt/html/rt-Z-H-1.html#node_toc_node_sec_5.10 gAlan might also be an alternative, http://galan.sourceforge.net/ And probably a bounch of others. :-) From ltdav1 at student.monash.edu.au Fri Mar 17 08:23:21 2006 From: ltdav1 at student.monash.edu.au (Loki Davison) Date: Fri Mar 17 08:23:26 2006 Subject: [linux-audio-dev] LADSPA processing: ams, om, ... Anything else? In-Reply-To: <200603162221.12257@goldspace.net> References: <200603162126.09058@goldspace.net> <1142535709.12231.16.camel@c213-100-50-8.swipnet.se> <200603162221.12257@goldspace.net> Message-ID: On 3/17/06, Andrew Gaydenko wrote: > Lars, > > Segfaults, segfaults... I have not noticed any concrete reproducable step sequence yet, > as have tried the app rather shortly. I really don't get it to crash for quite a few months. Please chat to dave on irc, or submit bugreports From drobilla at connect.carleton.ca Fri Mar 17 19:21:51 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Fri Mar 17 19:21:56 2006 Subject: [linux-audio-dev] LADSPA processing: ams, om, ... Anything else? In-Reply-To: <200603162126.09058@goldspace.net> References: <200603162126.09058@goldspace.net> Message-ID: <1142641311.24795.6.camel@localhost.localdomain> On Thu, 2006-16-03 at 21:26 +0300, Andrew Gaydenko wrote: > Are there alternatives for 'ams' and 'om'? My problems are: [snip] > - 'om' engine has too many crashes (I see, it is normal, as the app is under > development). No, actually engine segfaults are not even remotely close to "normal". I don't recall any bug reports from you - my magic crystal ball (from which I derive my psychic powers) must be malfunctioning. What exactly do you expect, if you don't even report bugs? -DR- From a at gaydenko.com Fri Mar 17 19:39:34 2006 From: a at gaydenko.com (Andrew Gaydenko) Date: Fri Mar 17 19:39:32 2006 Subject: [linux-audio-dev] LADSPA processing: ams, om, ... =?utf-8?q?Anything=09else=3F?= In-Reply-To: <1142641311.24795.6.camel@localhost.localdomain> References: <200603162126.09058@goldspace.net> <1142641311.24795.6.camel@localhost.localdomain> Message-ID: <200603180339.34471@goldspace.net> Dave, I needed to have quick result in my aufio DIY-ering test, and I have got it with (among other apps) 'om' - in spite of segfaults :-) Next time I'll arrange a console side by side with om_gtk window to hook segfault reason. Now I can add, 'lashd' was running, DSSI scope was used besides trivial LADSPA plugins like 'sine's, 'Constant', 'amplifier' and so on. And ... thanks for the app! Be sure, all is right with your magic power supplier :-) Andrew ======= On Saturday 18 March 2006 03:21, Dave Robillard wrote: ======= On Thu, 2006-16-03 at 21:26 +0300, Andrew Gaydenko wrote: > Are there alternatives for 'ams' and 'om'? My problems are: [snip] > - 'om' engine has too many crashes (I see, it is normal, as the app is under > development). No, actually engine segfaults are not even remotely close to "normal". I don't recall any bug reports from you - my magic crystal ball (from which I derive my psychic powers) must be malfunctioning. What exactly do you expect, if you don't even report bugs? -DR- From denisfalqueto at gmail.com Sat Mar 18 09:05:21 2006 From: denisfalqueto at gmail.com (Denis Alessandro Altoe Falqueto) Date: Sat Mar 18 09:05:25 2006 Subject: [linux-audio-dev] LADSPA processing: ams, om, ... Anything else? In-Reply-To: <200603180339.34471@goldspace.net> References: <200603162126.09058@goldspace.net> <1142641311.24795.6.camel@localhost.localdomain> <200603180339.34471@goldspace.net> Message-ID: On 3/17/06, Andrew Gaydenko wrote: > Dave, > > I needed to have quick result in my aufio DIY-ering test, and I have got > it with (among other apps) 'om' - in spite of segfaults :-) Next time I'll > arrange a console side by side with om_gtk window to hook segfault > reason. Now I can add, 'lashd' was running, DSSI scope was used besides > trivial LADSPA plugins like 'sine's, 'Constant', 'amplifier' and so on. > > And ... thanks for the app! Be sure, all is right with your magic power > supplier :-) > > > Andrew > > ======= On Saturday 18 March 2006 03:21, Dave Robillard wrote: ======= > On Thu, 2006-16-03 at 21:26 +0300, Andrew Gaydenko wrote: > > Are there alternatives for 'ams' and 'om'? My problems are: > [snip] > > - 'om' engine has too many crashes (I see, it is normal, as the app is under > > development). > > No, actually engine segfaults are not even remotely close to "normal". > > I don't recall any bug reports from you - my magic crystal ball (from > which I derive my psychic powers) must be malfunctioning. > > What exactly do you expect, if you don't even report bugs? > > -DR- > > > Hi, Andrew. I was experiencing this segmentation faults every time too... until I found that my /etc/hosts file was not correctly set. When I put my real hostname in there, it worked. This is because the OSC server needs the /etc/hosts file right for sending and receiving data in the local computer. Don't know if I explained myself right, but it worked for me... I am using Arch Linux and its policy is not to have tools to configure the system, so I had to do it by myself. HTH. -- ------------------------------------------- Denis A. Altoe Falqueto ------------------------------------------- From a at gaydenko.com Sat Mar 18 09:45:30 2006 From: a at gaydenko.com (Andrew Gaydenko) Date: Sat Mar 18 09:45:44 2006 Subject: [linux-audio-dev] LADSPA processing: ams, om, ... Anything else? In-Reply-To: References: <200603162126.09058@goldspace.net> <200603180339.34471@goldspace.net> Message-ID: <200603181745.30107@goldspace.net> Denis, Do you mean, om-engine doesn't work at all without appropriate records inside 'hosts' file ? In my case generally it works. ======= On Saturday 18 March 2006 17:05, Denis Alessandro Altoe Falqueto wrote: ======= ... Hi, Andrew. I was experiencing this segmentation faults every time too... until I found that my /etc/hosts file was not correctly set. When I put my real hostname in there, it worked. This is because the OSC server needs the /etc/hosts file right for sending and receiving data in the local computer. Don't know if I explained myself right, but it worked for me... I am using Arch Linux and its policy is not to have tools to configure the system, so I had to do it by myself. HTH. -- ------------------------------------------- Denis A. Altoe Falqueto ------------------------------------------- From denisfalqueto at gmail.com Sat Mar 18 10:02:40 2006 From: denisfalqueto at gmail.com (Denis Alessandro Altoe Falqueto) Date: Sat Mar 18 10:02:44 2006 Subject: Fwd: [linux-audio-dev] LADSPA processing: ams, om, ... Anything else? In-Reply-To: <200603181745.30107@goldspace.net> References: <200603162126.09058@goldspace.net> <200603180339.34471@goldspace.net> <200603181745.30107@goldspace.net> Message-ID: On 3/18/06, Andrew Gaydenko wrote: > Denis, > > Do you mean, om-engine doesn't work at all without appropriate records inside 'hosts' > file ? In my case generally it works. > Andrew, To me, it was like this: the engine starts and sits down waiting for a client to connect. But when I start om_gtk, the engine segfaults... and the client can't do anything. The client keeps runing but I can't use it for nothing. When I configured the /etc/hosts it worked right. My /etc/hosts was like this: 127.0.0.1 localhost.localdomain localhost I changed it to: 127.0.0.1 bach bach And it all worked. I found the solution in the hexter homepage, at the bottom of the page, at the FAQ. It explains why the OSC server needs this to work. Regards, -- ------------------------------------------- Denis A. Altoe Falqueto ------------------------------------------- From fons.adriaensen at skynet.be Sat Mar 18 10:28:33 2006 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Sat Mar 18 10:21:38 2006 Subject: Fwd: [linux-audio-dev] LADSPA processing: ams, om, ... Anything else? In-Reply-To: References: <200603162126.09058@goldspace.net> <200603180339.34471@goldspace.net> <200603181745.30107@goldspace.net> Message-ID: <20060318152833.GB4825@linux-1> On Sat, Mar 18, 2006 at 12:02:40PM -0300, Denis Alessandro Altoe Falqueto wrote: > My /etc/hosts was like this: > > 127.0.0.1 localhost.localdomain localhost > > I changed it to: > > 127.0.0.1 bach bach > > And it all worked. I found the solution in the hexter homepage, at the > bottom of the page, at the FAQ. It explains why the OSC server needs > this to work. It may be a good idea to keep the localhost entry, and *add* the one you need. Also when no hostname is supplied, apps IMHO should not try to look up the local host name but just use the loopback interface (127.0.0.1). -- FA Follie ! Follie delirio vano e' questo ! From denisfalqueto at gmail.com Sat Mar 18 10:27:05 2006 From: denisfalqueto at gmail.com (Denis Alessandro Altoe Falqueto) Date: Sat Mar 18 10:27:11 2006 Subject: Fwd: [linux-audio-dev] LADSPA processing: ams, om, ... Anything else? In-Reply-To: <20060318152833.GB4825@linux-1> References: <200603162126.09058@goldspace.net> <200603180339.34471@goldspace.net> <200603181745.30107@goldspace.net> <20060318152833.GB4825@linux-1> Message-ID: On 3/18/06, fons adriaensen wrote: > It may be a good idea to keep the localhost entry, and *add* the > one you need. Oh, thanks very much, Fons. I'll do that. :-) -- ------------------------------------------- Denis A. Altoe Falqueto ------------------------------------------- From ivarga at csounds.com Sat Mar 18 12:01:21 2006 From: ivarga at csounds.com (Istvan Varga) Date: Sat Mar 18 12:03:11 2006 Subject: [linux-audio-dev] [ANN] Csound 5.01 release Message-ID: <200603181801.21896.ivarga@csounds.com> Source and binary packages can be downloaded from here: http://sourceforge.net/project/showfiles.php?group_id=81968 The following Linux binaries are available; these all include the HTML manual as well: Csound5.01-i386d.tar.gz this was built on SuSE 9.3 (x86, GCC 3.x) with double precision floats, and includes a simple GUI installer Csound5.01-i386f.tar.gz same as above, but with single precision floats Csound5.01-x86_64d.tar.gz same as Csound5.01-i386d.tar.gz, but for the AMD64 platform Csound5.01-x86_64f.tar.gz same as above, but single precision floats Csound5.01_i686.rpm an RPM package built on SuSE 10.0 (x86, GCC 4.0) with both single and double precision floats, and includes the following additional features that are not available in the .tar.gz packages: * csoundapi~ object for PD (32 bit floats only) * CsoundVST (GUI frontend and Python module for algorithmic composition; 64 bit floats only) * STK (Perry Cook's Synthesis ToolKit) opcodes * VIM files for syntax highlighting and keyword help --------------------------------------------------------------------------- Changes since Csound 5.00 ------------------------- New features: Made it possible to load opcode plugins only when the opcode is actually used. New opcodes: New track processing opcodes for PVS system: trscale - streaming partial track frequency scaling trshift - streaming partial track frequency shifting trsplit - takes an input containg a TRACKS pv streaming signal and splits it into two signals according to a k-rate frequency 'split point'. trmix - takes two inputs containg TRACKS pv streaming signals and mixes them into a single TRACKS stream trfilter - filters a TRACKS pv streaming signal using an amplitude response curve stored in a function table trcross - streaming partial track cross-synthesis trhighest - extracts the highest-frequency track from a streaming track input signal trlowest - extracts the lowest-frequency track from a streaming track input signal binit - PVS tracks to amplitude+frequency conversion barmodel - creates a tone similar to a struck metal bar max - produces a signal that is the maximum of any number of input signals min - produces a signal that is the minimum of any number of input signals maxabs - produces a signal that is the maximum of the absolute values of any number of input signals minabs - produces a signal that is the minimum of the absolute values of any number of input signals maxaccum - accumulates the maximum value of audio signals minaccum - accumulates the minimum value of audio signals maxabsaccum - accumulates the maximum of the absolute values of audio signals minabsaccum - accumulates the minimum of the absolute values of audio signals Changes: Several opcodes and opcode groups have been moved out of the Csound library and stdopcod library into separate plugins (vbap, babo, grain4, hrtferX, PhisEm opcodes). Improvements in JACK plugin to allow lower latency and remove some restrictions on buffer sizes. Bug fixes: Bug fixes in FLsetVal and FLsetVal_i; allow buttons and button banks in FLsetVal; fixed handle output of FLbutBank (not sure if this is safe); implemented cursor size parameter for FLknob. Fixed bugs in i-rate ZAK opcodes. Fixed hang on very short note before end of score or section. Added hacks to fix the problem of the else branch of an if/then/else always being executed at i-time. Fixed crash on 'then' or 'goto' in variable names in conditional expression for if/elseif. Fixed crashes on missing whitespace between if/elseif and '(' and on extra ')' in expressions. and of course a number of minor bug fixes all over Changes: 2006-03-16 Istvan Varga * Opcodes/sftype.h: check for MacOS 9 or PowerPC, and define WORDS_BIGENDIAN on those platforms. 2006-03-13 Anthony Kozar * Top/main.c: Made TYP_AIFF the default for MacOS 9. * Engine/entry1.c: Removed duplicate OENTRYs. 2006-03-12 jpff * Opcodes/bilbar.c (bar_run): Corrected boundary condition 2006-03-11 Istvan Varga * Engine/express.c: fixes in extending tokenstring buffer 2006-03-10 Anthony Kozar * Opcodes/minmax.c: * SConstruct: Added new 'minmax' plugin library with opcodes for finding minimum and maximum values among several signals. 2006-03-10 Michael Gogins * CSD style command lines in CsoundVST are now translated to orc/sco style before performance in order to save having to edit the command line after loading some CSD files. 2006-03-08 Istvan Varga * Made it possible to load opcode plugins only when the opcode is actually used. 2006-03-07 jpff * Engine/otran.c: Removed DTYPE and lclnxtdcnt as not used 2006-02-25 Michael Gogins * Updated SConstruct, custom.py, and Windows installer to build and install PortMidi. 2006-02-24 Istvan Varga * InOut/rtjack.c: Use thread locks instead of calling usleep() in a loop to implement blocking I/O; the -+jack_sleep_time option is now deprecated and ignored. Allow non power of two values for -B. Setting -b to the same value as the JACK buffer size is no longer required. * Engine/insert.c: * Engine/musmon.c: Alternate fix to problems on very short (less than 1/2 control period) notes; the previous fix introduced a new bug that resulted in early termination of the score in some cases. * H/version.h: * installer/misc/csound.spec.in: Updated version number from 5.00.1 to 5.01.0 to reflect the addition of new opcodes. 2006-02-24 Victor Lazzarini * Opcodes/psynth.c new track processing opcodes (also added manual pages): trscale, trshift, trsplit, trmix, trfilter, trcross, trhighest, trlowest, binit. 2006-02-15 Istvan Varga * InOut/widgets.h: moved file from H/ * InOut/widgets.cpp: bug fixes in FLsetVal and FLsetVal_i allow buttons and button banks in FLsetVal fixed handle output of FLbutBank (not sure if this is safe) implemented cursor size parameter for FLknob 2006-02-13 Istvan Varga * OOps/ugrw1.c: fixed bugs in i-rate ZAK opcodes 2006-02-09 Istvan Varga * Engine/rdorch.c: splitline(): made checking for invalid characters stricter fixed labels before else/endif allow bitwise NOT operator in UTF-8 format 2006-02-06 Istvan Varga * Engine/entry1.c: cogoto requires an i-rate conditional * Engine/musmon.c: fixed hang on very short note before end of score or section * Engine/rdorch.c: added hacks to fix the problem of the else branch of an if/then/else always being executed at i-time. Fixed crash on 'then' or 'goto' in variable names in conditional expression for if/elseif (still does not work if there are no parentheses around the conditional expression). 2006-02-03 Istvan Varga * Engine/rdorch.c: fixed crash on extra ) in expressions * Engine/rdorch.c: fixed crash on missing whitespace between if/elseif and ( this needs more testing From drobilla at connect.carleton.ca Sat Mar 18 12:51:33 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sat Mar 18 12:51:37 2006 Subject: [linux-audio-dev] LADSPA processing: ams, om, ... Anything else? In-Reply-To: <200603181745.30107@goldspace.net> References: <200603162126.09058@goldspace.net> <200603180339.34471@goldspace.net> <200603181745.30107@goldspace.net> Message-ID: <1142704293.29961.2.camel@localhost.localdomain> On Sat, 2006-18-03 at 17:45 +0300, Andrew Gaydenko wrote: > Denis, > > Do you mean, om-engine doesn't work at all without appropriate records inside 'hosts' > file ? In my case generally it works. Some people have issues with the engine not being able to communicate with the client without a specific record in /etc/hosts. If it works at all, this isn't your problem though. BTW, please don't top-post, it ruins the thread. Post your replies at the bottom of the quoted message -DR- From torbenh at gmx.de Sat Mar 18 12:48:36 2006 From: torbenh at gmx.de (torbenh@gmx.de) Date: Sat Mar 18 12:53:30 2006 Subject: [linux-audio-dev] [ANN] netjack-0.9 with alsa I/O (also can be used to bind jackd to 2 soundcards) Message-ID: <20060318174836.GB7988@mobilat> ok... netjack-0.9 is here. this is basically netjack-0.9rc4 with the transport offset of one period fixed. additionally i have added 2 jack clients which open unrelated soundcards. these are fixed reimplementations of the old alsa_client. fully configurable, and better than the alsa_client. it does even work with usb soundcards. using a second soundcard for monitoring purposes is now possible. the only current limitation to this is 16bit. but this will be changed soon... -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From hans at fugal.net Sat Mar 18 13:38:27 2006 From: hans at fugal.net (Hans Fugal) Date: Sat Mar 18 13:38:35 2006 Subject: Fwd: [linux-audio-dev] LADSPA processing: ams, om, ... Anything else? In-Reply-To: <20060318152833.GB4825@linux-1> References: <200603162126.09058@goldspace.net> <200603180339.34471@goldspace.net> <200603181745.30107@goldspace.net> <20060318152833.GB4825@linux-1> Message-ID: <20060318183827.GA11769@falcon.fugal.net> On Sat, 18 Mar 2006 at 16:28 +0100, fons adriaensen wrote: > On Sat, Mar 18, 2006 at 12:02:40PM -0300, Denis Alessandro Altoe Falqueto wrote: > > when no hostname is supplied, apps IMHO should > not try to look up the local host name but just use the loopback > interface (127.0.0.1). FWIW I'm with you on this policy. -- Hans Fugal ; http://hans.fugal.net There's nothing remarkable about it. All one has to do is hit the right keys at the right time and the instrument plays itself. -- Johann Sebastian Bach -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060318/9e4af3d5/attachment-0001.bin From rj at spamatica.se Sat Mar 18 15:06:45 2006 From: rj at spamatica.se (Robert Jonsson) Date: Sat Mar 18 15:06:57 2006 Subject: [linux-audio-dev] [Announce] MusE 0.8 released Message-ID: <200603182106.45849.rj@spamatica.se> MusE 0.8 is here at last. [Introduction] MusE 0.8 was originally intended to be called 0.7.2 but for various reasons (featuritis, time, and because 'I wanna!') we decided to call it 0.8. This is most likely the last release in the old series, next up is the much rewritten 1.0. This release contains a number of new features lots of stability and usability improvements. All users are encouraged to upgrade. [Notable new features] - Syncronization with external hardware using Midi Clock now works (see Errata on homepage for known limitations) - Support for restaring jack during runtime - Import and export of midi parts with drag&drop support - Import of plugin-presets with drag&drop support - Internal lightweight wave editor + link to external editor - Lots and lots of improvements, see compressed ChangeLog below [New instrument definition files] - Emu Proteus 200 - Roland E-28 - Roland SCD-70 - Yamaha PSR-275 - MC-505 - Roland Fantom XR - Roland SRX-02 - Roland SRX-09 - Waldorf-Q - Yamaha 01v - Yamaha Motif - Yamaha P100 [Translations] - New polish translation - New german translation - Updated swedish translation - Updated french translation - Updated russian translation [Notable known issues] See the errata section on the homepage for the latest: http://www.muse-sequencer.org/wiki/index.php/Errata0.8 [Compressed list of changes from the ChangeLog] ? - Extern sync with partial looping support - muse now starts even if jack is not found - fixed a number of divide by zero errors mainly affecting zoom - Updated/improved swedish translation. - Fix for softsynths going silent under load. - amd64 fix for rtc timer - Added updated french translation from Intent - Fixed crash bug in pianoroll when moving several events outside part. - Added popup when enabling rec for a track unable to create it's wave file - Enlarged listeditor dialog (FR:1392090) - Fixed crash bug when arrowing left in an empty editor - Fixed bug in detection of RTC - Organ softsynth did not work correctly - VAM softsynth did not work correctly - Changed audio prefetch buffer to be dynamically sized after the jack buffers - Fixed race condition between threads caused lockup upon quit and load project. - dynamically extends parts, fixes bug:1363066 Paste outside segment - now tries both RTC and Alsa (in that sequence) for main timer - updated muse_ru.ts from Alexandre Prokoudine - removed assert, fixes bug:1376783, deleting track with pianoroll open crashes muse - fixed crash bug for showing plugin-guis when the plugin did not exist - fixed seg fault when deleting last note in pianoroll editor - Fixed bug 1329537 (User defined fonts not updated) - added emuproteus200.idf from Piotr Sawicki - added polish translation from Piotr Sawicki - Handle restart of Jack and restart of audio - Added new timer classes from Jonathan Woithe. - Solo for audio tracks improved by removing the possibility to mute Output tracks - Implemented REPLACE for midi recording - Fixes for Appearance dialog, background pic, event display - Marker window now toggling - Added "raise" to more dialog windows - bounce now stops correctly - Fixed position of import of wave files, inserted at cursor, now inserts at mouse - Added drag&drop support to plugin racks in mixer, internal and to/from disk - Added quick search to LADSPA plugin dialog - Implemented resize of waveparts - Added Idf files by Steve D for Roland FantomXR, SRX-02 and SRX-09 - Internal wave editor enabled with common operations, fade, cut, amplify, etc - Fixed bug with loading of background pixmaps - Fixed bug 1199171 (Time change: a part does not completely fit into 4 bars), part resize problem - Added scrollwheel support for vertical scrolling in arranger, pianoroll and drumeditor - Fixed bug 1056996: Multiple selection, but single paste. Possible to copy several parts in arranger - Fixed bug 1092424: bug in reposition of instruments in drumeditor - Fix for drumtracks and part export/import - Fix for opening Midi port/softsynth dialog when already open (now raised and set to active window) - Added export/import of midi parts (.mpt-files), drag & drop also possible - Fix for generating midi clock - Added Roland E-28 idf file from Jonathan Woithe (js) - Allows for several midi devices with the same name - Fix for bug 1198747, tests for fluidsynth and rtcap in configure.ac - Fix for bug 1198744, added patch for reading browser setting from config without crashing, from Philip Nelson - Fix for bug 1188767, downmix won't stop playback until reaching the right marker - the instrument list in the drumeditor now has fixed width when resizing the window - added nudge event position left/right w keyboard (ctrl+left/rightarrow as default) to pianoroll and drumeditor - added fixed length command to pianoroll, uses snap-to value - added snap/quantize patch from Petr Mazanec (snap of notes in pianoroll+drumeditor is now controlled by snap, not quantize) - simpledrums: added save/load of setup to file, bugfixes. simpledrums version is now 1.0 (go figure! ;) - No longer crashed when enabling audio metronome when there's an aux - fluidsynth: bankno is saved to project, switched to hbank from lbank - make sleep() in watchdog thread non interruptible to avoid watchdog timeouts at startup - added vst preallocation of memory "fix" - More fixes to filenames containing dots (for instance wca files) - Added Yamaha-PSR275 instrument file by Petr Mazanec - fixed patch-info issue in Fluidsynth (bug 1191214) - fixed bug w paste in drumeditor, 1189267, patch from P Mazanec - Fixed bug 1152441, filename can now have several dots - Fixed bug 1183980: fluidsynth pitch controller wasn't given to MusE from the synth - Added an error popup when importing wave files fails. - added support for german localization - help: changed muse homepage location - Fix for overflow when importing midi - Added some fixed on dialog handling, mainly "esc" will close the widget now. - New icons - Added Roland-SCD70.idf from Emiliano Grilli - New version of MC505.idf from Wim VW - Added script to convert MusE 0.6 songs to 0.7-0.8 format - For a complete list of changes see the ChangeLog. For a complete list of changes see the ChangeLog: http://cvs.sourceforge.net/viewcvs.py/lmuse/muse/ChangeLog?rev=1.214.2.141&only_with_tag=REL07&view=auto Source download available: http://sourceforge.net/project/showfiles.php?group_id=93414&package_id=184215&release_id=402687 Regards, /MusE Development team From drobilla at connect.carleton.ca Sat Mar 18 21:19:48 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sat Mar 18 21:19:51 2006 Subject: Fwd: [linux-audio-dev] LADSPA processing: ams, om, ... Anything else? In-Reply-To: <20060318183827.GA11769@falcon.fugal.net> References: <200603162126.09058@goldspace.net> <200603180339.34471@goldspace.net> <200603181745.30107@goldspace.net> <20060318152833.GB4825@linux-1> <20060318183827.GA11769@falcon.fugal.net> Message-ID: <1142734788.7224.0.camel@localhost.localdomain> On Sat, 2006-18-03 at 11:38 -0700, Hans Fugal wrote: > On Sat, 18 Mar 2006 at 16:28 +0100, fons adriaensen wrote: > > On Sat, Mar 18, 2006 at 12:02:40PM -0300, Denis Alessandro Altoe Falqueto wrote: > > > > when no hostname is supplied, apps IMHO should > > not try to look up the local host name but just use the loopback > > interface (127.0.0.1). > > FWIW I'm with you on this policy. Any looking up of hostnames and whatnot occurs in liblo, not apps themselves -DR- From ico at vt.edu Mon Mar 20 20:06:27 2006 From: ico at vt.edu (ico) Date: Mon Mar 20 20:06:36 2006 Subject: [linux-audio-dev] What is currently the best USB audio interface for Linux? Message-ID: <4421354D@zathras> Hi all, I am in the process of considering a portable USB audio interface. Having checked the alsa matrix, I am a bit at a loss what may be the best option. Things I am looking for are as follows (they are listed in no particular order): 1) USB interface 2) Preferrably USB 2.0 capable 3) Audio and MIDI capability 4) High fidelity (higher the better) 5) More inputs/outputs, the better 6) Preferrably has some preamp inputs 7) Obviously must be supported in Linux/Alsa 8) Price not an issue Any ideas? Best wishes, Ico From luisgarrido at users.sourceforge.net Mon Mar 20 21:41:37 2006 From: luisgarrido at users.sourceforge.net (Luis Garrido) Date: Mon Mar 20 21:41:42 2006 Subject: [linux-audio-dev] What is currently the best USB audio interface for Linux? In-Reply-To: <4421354D@zathras> References: <4421354D@zathras> Message-ID: Edirol UA-25, excepting 2) & 5) Works well enough for me. Luis On 3/21/06, ico wrote: > Hi all, > > I am in the process of considering a portable USB audio interface. Having > checked the alsa matrix, I am a bit at a loss what may be the best option. > > Things I am looking for are as follows (they are listed in no particular > order): > > 1) USB interface > 2) Preferrably USB 2.0 capable > 3) Audio and MIDI capability > 4) High fidelity (higher the better) > 5) More inputs/outputs, the better > 6) Preferrably has some preamp inputs > 7) Obviously must be supported in Linux/Alsa > 8) Price not an issue > > Any ideas? > > Best wishes, > > Ico > > From rlrevell at joe-job.com Mon Mar 20 21:50:07 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Mon Mar 20 21:50:14 2006 Subject: [linux-audio-dev] What is currently the best USB audio interface for Linux? In-Reply-To: References: <4421354D@zathras> Message-ID: <1142909408.4532.111.camel@mindpipe> On Tue, 2006-03-21 at 03:41 +0100, Luis Garrido wrote: > Edirol UA-25, excepting 2) & 5) > > Works well enough for me. I don't think there are any supported USB 2.0 devices. Lee From clemens at ladisch.de Tue Mar 21 03:42:04 2006 From: clemens at ladisch.de (Clemens Ladisch) Date: Tue Mar 21 03:42:33 2006 Subject: [linux-audio-dev] What is currently the best USB audio interface for Linux? In-Reply-To: <4421354D@zathras> References: <4421354D@zathras> Message-ID: <20060321084204.GE19583@turing.informatik.uni-halle.de> ico wrote: > I am in the process of considering a portable USB audio interface. Having > checked the alsa matrix, I am a bit at a loss what may be the best option. Have a look at , too. > 2) Preferrably USB 2.0 capable The only supported USB 2.0 device is the Creative Audigy 2 NX, and high speed capturing is broken in all kernels before 2.6.17. (But who cares about audio when the remote control works ... ;-) > 4) High fidelity (higher the better) Okay, forget USB 2.0 ... > 5) More inputs/outputs, the better USB 1.x bandwidth is quite limited. It's possible to transfer eight channels of 16-bit audio at 48 kHz, but full duplex 24 bit stereo at 96 kHz is not possible. > 6) Preferrably has some preamp inputs > 7) Obviously must be supported in Linux/Alsa > 8) Price not an issue Have a look at the Edirol devices (except the UA-1000 or UA-101). HTH Clemens From fbar at footils.org Tue Mar 21 08:03:55 2006 From: fbar at footils.org (Frank Barknecht) Date: Tue Mar 21 08:03:36 2006 Subject: [linux-audio-dev] What is currently the best USB audio interface for Linux? In-Reply-To: <20060321084204.GE19583@turing.informatik.uni-halle.de> References: <4421354D@zathras> <20060321084204.GE19583@turing.informatik.uni-halle.de> Message-ID: <20060321130355.GJ6528@fliwatut.scifi> Hallo, Clemens Ladisch hat gesagt: // Clemens Ladisch wrote: > > 6) Preferrably has some preamp inputs > > 7) Obviously must be supported in Linux/Alsa > > 8) Price not an issue > > Have a look at the Edirol devices (except the UA-1000 or UA-101). The Terratec Phase26 also is nice, and some places carry it quite cheap (139 Euro in my area, which is www.musicstore-koeln.de) Ciao -- Frank Barknecht _ ______footils.org_ __goto10.org__ From ico at vt.edu Tue Mar 21 15:22:40 2006 From: ico at vt.edu (Ivica Ico Bukvic) Date: Tue Mar 21 15:22:51 2006 Subject: [linux-audio-dev] What is currently the best USB audio interfacefor Linux? In-Reply-To: <20060321130355.GJ6528@fliwatut.scifi> Message-ID: <003a01c64d25$33b9ef70$adaf52c6@64BitBadass> Thank you all for your insight! Best wishes, Ico > -----Original Message----- > From: linux-audio-dev-bounces@music.columbia.edu [mailto:linux-audio-dev- > bounces@music.columbia.edu] On Behalf Of Frank Barknecht > Sent: Tuesday, March 21, 2006 8:04 AM > To: linux-audio-dev@music.columbia.edu > Subject: Re: [linux-audio-dev] What is currently the best USB audio > interfacefor Linux? > > Hallo, > Clemens Ladisch hat gesagt: // Clemens Ladisch wrote: > > > > 6) Preferrably has some preamp inputs > > > 7) Obviously must be supported in Linux/Alsa > > > 8) Price not an issue > > > > Have a look at the Edirol devices (except the UA-1000 or UA-101). > > The Terratec Phase26 also is nice, and some places carry it quite > cheap (139 Euro in my area, which is www.musicstore-koeln.de) > > Ciao > -- > Frank Barknecht _ ______footils.org_ __goto10.org__ From paniq at paniq.org Thu Mar 23 03:33:39 2006 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Thu Mar 23 03:29:37 2006 Subject: [linux-audio-dev] Re: python and jack, performance report In-Reply-To: References: <1134315209.3234.5.camel@zeitgeist> Message-ID: <1143102819.5208.110.camel@zeitgeist> On Fri, 2005-12-16 at 13:20 +0000, Maxim Krikun wrote: > What about the latency? Do you think sure it's safe to execute arbitrary pyhton > code inside jack's thread? no, see my remark about prototyping. > Your TestClient.mix method manipulates arrays, thus it may eventually call > malloc, which is explicitly discouraged in jack api doculentation. i'm aware of that. but that only means its not good for production code, but its fine for prototyping, as i already stated. -- -- leonard "paniq" ritter -- http://www.mjoo.org -- http://www.paniq.org From richard.spindler at gmail.com Thu Mar 23 05:27:45 2006 From: richard.spindler at gmail.com (Richard Spindler) Date: Thu Mar 23 05:27:50 2006 Subject: [linux-audio-dev] ALSA Picture Message-ID: <4af8d6ff0603230227y22c67c22v@mail.gmail.com> Hi, on my quest to understand the ALSA API, I created a little Image to get an overview about the various states and how they relate to each other. http://propirate.net/oracle/bilder/ALSA.png Hopefully I got everyting right, can you have a look at this image and tell me whether this is correct? Thanks -Richard From musical_snake at gmx.de Thu Mar 23 15:13:37 2006 From: musical_snake at gmx.de (Ralf Beck) Date: Thu Mar 23 15:15:00 2006 Subject: [linux-audio-dev] Best opensource license to use? In-Reply-To: <1143102819.5208.110.camel@zeitgeist> References: <1134315209.3234.5.camel@zeitgeist> <1143102819.5208.110.camel@zeitgeist> Message-ID: <44230171.7050204@gmx.de> Hi all, i intend to release an application, which allows to use VST(i)s running on an XP machine from a linux jack client, hooked up over ethernet. Since i want to not only make the linux jack client opensource, but the XP part opensource too, what would be the best license for the latter (due to the VST header issue)? Ralf From chris.cannam at ferventsoftware.com Thu Mar 23 16:37:56 2006 From: chris.cannam at ferventsoftware.com (Chris Cannam) Date: Thu Mar 23 16:40:55 2006 Subject: [linux-audio-dev] Best opensource license to use? Message-ID: <1093552404-1143150048-cardhu_blackberry.rim.net-32474-@engine55.bwc.produk.on.blackberry> > i intend to release an application, which allows to > use VST(i)s running on an XP machine from > a linux jack client, hooked up over ethernet. If all the code is your own, consider the approach we used in dssi-vst, which is to use the GPL plus an exception to allow for the unavailability of VSTSDK sources. It won't be GPL-compatible or "Debian" free, but nothing will be if not all the source is available, and I think it best expresses the intention -- if your preference would naturally be for the GPL, that is. Meanwhile, write and remind Steinberg that their license could be more helpful to developers of Windows and Linux plugins and hosts. It won't be news and there's no real reason they should care, but it's worth a nudge that these things matter to people, including those who would like to promote, recommend and use their standard. As it happens I'm also shortly about to release a Windows plugin host that is not at all in competition with Steinberg products, but that can't host VSTs for licensing reasons and will use DSSI plugins instead. Hosting audio plugins is not a major part of this program so the difference isn't going to be all that significant to me or anyone else, but it's an interesting situation. Chris From beachnase at web.de Thu Mar 23 18:24:07 2006 From: beachnase at web.de (Frank Neumann) Date: Thu Mar 23 18:20:15 2006 Subject: [linux-audio-dev] Linux Audio Conference 2006: Register now! Message-ID: Hi all, this mail is just to inform you that registration for the 4th International Linux Audio Conference (or "LAC2006" for short), APril 27th-30th, in Karlsruhe, Germany, is possible as of now by visiting our web page at http://lac.zkm.de and clicking on the link "Registration" on the left. Like last year (and the years before), registration is free and is only necessary because we need to prepare nametags, make estimations about room sizes/required chairs and want to learn a bit about our audience. That's all, honestly! :-). Information given there will NOT be used for any kind of selling, spamming or otherwise abusing. Also, the preliminary conference program has been published a few weeks ago, available through the same link give above. Thanks for registering in case you plan to come! Greetings, Frank Neumann Goetz Dipper LAC2006 organization team From mista.tapas at gmx.net Fri Mar 24 04:52:47 2006 From: mista.tapas at gmx.net (Florian Schmidt) Date: Fri Mar 24 04:52:52 2006 Subject: [linux-audio-dev] Linux Audio Conference 2006: Register now! In-Reply-To: References: Message-ID: <20060324105247.73d7a5a8@mango.fruits> On Fri, 24 Mar 2006 00:24:07 +0100 Frank Neumann wrote: > > Hi all, > > this mail is just to inform you that registration for the 4th International > Linux Audio Conference (or "LAC2006" for short), APril 27th-30th, in Karlsruhe, > Germany, is possible as of now by visiting our web page at > > http://lac.zkm.de > > and clicking on the link "Registration" on the left. Hi, the "profession" part of the registration says "multiple checks are ok", but they aren't, as the radiobuttons allow only one selection. Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org From james at dis-dot-dat.net Fri Mar 24 06:01:20 2006 From: james at dis-dot-dat.net (james@dis-dot-dat.net) Date: Fri Mar 24 06:01:03 2006 Subject: [linux-audio-dev] Best opensource license to use? In-Reply-To: <44230171.7050204@gmx.de> References: <1134315209.3234.5.camel@zeitgeist> <1143102819.5208.110.camel@zeitgeist> <44230171.7050204@gmx.de> Message-ID: <20060324110120.GG10023@phlunky.Belkin> On Thu, 23 Mar, 2006 at 09:13PM +0100, Ralf Beck spake thus: > Hi all, > > i intend to release an application, which allows to use VST(i)s running > on an XP machine from > a linux jack client, hooked up over ethernet. > Since i want to not only make the linux jack client opensource, but the > XP part opensource too, what would > be the best license for the latter (due to the VST header issue)? Could we precompile the thinest of thin wrappers to VST stuff to distrubute as a binary, with the source available on-line, minus the VST headers but including instructions on how to get them and make the wrapper? Then for a project such as yours, you just depend on the wrapper? Maybe? > Ralf > -- "I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you." (By Vance Petree, Virginia Power) From richard.spindler at gmail.com Fri Mar 24 08:09:06 2006 From: richard.spindler at gmail.com (Richard Spindler) Date: Fri Mar 24 08:09:10 2006 Subject: [linux-audio-dev] Alsa Problem Message-ID: <4af8d6ff0603240509h7293be49m@mail.gmail.com> Hi, I'm still trying to grok alsa, and now I have the following problem: I'm using snd_pcm_writei to playback some audio, however, after a little time the call fails with the error: "File descriptor in bad state", which I believe I cannot recover from. Why does this happen, and what could I do about this? cat /proc/asound/card0/pcm0p/sub0/* prints the following stuff, I don't know whether this is helpful? access: MMAP_INTERLEAVED format: S16_LE subformat: STD channels: 2 rate: 48000 (48000/1) period_size: 8192 buffer_size: 16384 tick_time: 1000 card: 0 device: 0 subdevice: 0 stream: PLAYBACK id: VIA 8235 name: VIA 8235 subname: subdevice #0 class: 0 subclass: 0 subdevices_count: 4 subdevices_avail: 3 64 state: RUNNING trigger_time: 1143205215.076663000 tstamp : 1143205216.323831000 delay : 13856 avail : 2528 avail_max : 14368 ----- hw_ptr : 59872 appl_ptr : 73728 tstamp_mode: NONE period_step: 1 sleep_min: 0 avail_min: 8192 xfer_align: 8192 start_threshold: 1 stop_threshold: 16384 silence_threshold: 0 silence_size: 0 boundary: 1073741824 From clemens at ladisch.de Fri Mar 24 08:10:11 2006 From: clemens at ladisch.de (Clemens Ladisch) Date: Fri Mar 24 08:10:32 2006 Subject: [linux-audio-dev] ALSA Picture In-Reply-To: <4af8d6ff0603230227y22c67c22v@mail.gmail.com> References: <4af8d6ff0603230227y22c67c22v@mail.gmail.com> Message-ID: <20060324131011.GC1671@turing.informatik.uni-halle.de> Richard Spindler wrote: > on my quest to understand the ALSA API, I created a little Image to > get an overview about the various states and how they relate to each > other. > > http://propirate.net/oracle/bilder/ALSA.png Cool, the first complete page of The ALSA Programming Manual! Now we only need somebody to write the remaining 999 pages ... ;-) > Hopefully I got everyting right, can you have a look at this image and > tell me whether this is correct? snd_pcm_hw_params() goes into the SETUP state and then calls snd_pcm_prepare(); I don't know how to display this in a picture. :) You probably want an arrow from snd_pcm_writei() to RUNNING. The SUSPENDED and XRUN states can happen asynchronously, i.e., the device can go into them at any time (from some other states), and the next call to snd_pcm_writei() only reports them. In this regard, they are similar to the DISCONNECTED state. XRUN happens not only when an over/underrun occurs but also when some other error causes the device to stop (this error may be recoverable or not). Regards, Clemens From richard.spindler at gmail.com Fri Mar 24 08:30:48 2006 From: richard.spindler at gmail.com (Richard Spindler) Date: Fri Mar 24 08:30:53 2006 Subject: [linux-audio-dev] ALSA Picture In-Reply-To: <20060324131011.GC1671@turing.informatik.uni-halle.de> References: <4af8d6ff0603230227y22c67c22v@mail.gmail.com> <20060324131011.GC1671@turing.informatik.uni-halle.de> Message-ID: <4af8d6ff0603240530m3e12f4edu@mail.gmail.com> 2006/3/24, Clemens Ladisch : > snd_pcm_hw_params() goes into the SETUP state and then calls > snd_pcm_prepare(); I don't know how to display this in a picture. :) Yes, I read that, but from an App-Developers point of view, this is roughly equivalent to going to PREPARE directly, IMHO. > You probably want an arrow from snd_pcm_writei() to RUNNING. Fixed that. :) > The SUSPENDED and XRUN states can happen asynchronously, i.e., the > device can go into them at any time (from some other states), and the > next call to snd_pcm_writei() only reports them. In this regard, they > are similar to the DISCONNECTED state. Is this an issue when using this async-stuff? I think the most likely situation might be that it happens when you call writei. > XRUN happens not only when an over/underrun occurs but also when some > other error causes the device to stop (this error may be recoverable or > not). What could that be? -Richard From kurmisk at inbox.lv Fri Mar 24 09:42:36 2006 From: kurmisk at inbox.lv (kurmisk) Date: Fri Mar 24 09:43:03 2006 Subject: [linux-audio-dev] select() ?? before snd_pcm_writei(handle, buffer, frames); Message-ID: <1143211356.4424055c1f67e@www.inbox.lv> Hi Developers. I have write my small _alsa_test_program_. [C code ckunkz see below] It works good but now i wanna before call rc = snd_pcm_writei(handle, buffer, frames); somehow check - is sound device free for this call or not. For OSS i have such problem solve with select() : fdo = open("/dev/dsp", O_WRONLY ); ..... FD_ZERO(&wfds); FD_SET( fdo , &wfds); Zeit.tv_sec=0; Zeit.tv_usec=1; response=select(fdo+1, NULL, &wfds, NULL, & Zeit ); Tnx in advance Alf int alsa_snd_pcm_open_write(unsigned int sample_rate__, unsigned int chan__ , snd_pcm_uframes_t * frames_p , snd_pcm_t ** handle) { int dir; // snd_pcm_t *handle; snd_pcm_hw_params_t *params; unsigned int val; int ret_fun; int chan_nr; snd_pcm_uframes_t frames; /* Open PCM device for playback. */ ret_fun = snd_pcm_open(* &handle, "default", SND_PCM_STREAM_PLAYBACK, 0); if (ret_fun < 0){ fprintf(stderr, "unable to open pcm device: %s\n", snd_strerror(ret_fun) ); exit(1); } /* Allocate a hardware parameters object. */ snd_pcm_hw_params_alloca(¶ms); /* Fill it in with default values. */ snd_pcm_hw_params_any(* handle, params); /* Set the desired hardware parameters. */ snd_pcm_hw_params_set_access(* handle, params, SND_PCM_ACCESS_RW_INTERLEAVED); /* Interleaved mode */ snd_pcm_hw_params_set_format(* handle, params, SND_PCM_FORMAT_S16_LE); /* Signed 16-bit little-endian format */ //snd_pcm_hw_params_set_format(handle, params, SND_PCM_FORMAT_S16_BE); chan_nr = chan__; snd_pcm_hw_params_set_channels(* handle, params, chan_nr); val = sample_rate__; snd_pcm_hw_params_set_rate_near(* handle, params, &val, &dir ); frames = * frames_p; //frames = 2048; /* Set period size to __nr__ frames. */ snd_pcm_hw_params_set_period_size_near(* handle, params, &frames, &dir); * frames_p = frames; /* Write the parameters to the driver */ ret_fun = snd_pcm_hw_params(* handle, params); if (ret_fun < 0) { fprintf(stderr, "unable to set hw parameters: %s\n", snd_strerror(ret_fun)); exit(1); } /* Use a buffer large enough to hold one period */ snd_pcm_hw_params_get_period_size(params, &frames, &dir); snd_pcm_hw_params_get_period_time(params, &val, &dir); } int main(int argc, char **argv) { ........ snd_pcm_uframes_t frames; unsigned int sample_rate; unsigned int chan; snd_pcm_t *handle; //---- sample_rate=44100; chan=2; frames=1023; // 4096 // frames=2047; // 8192 // frames=4095; // 16384 // frames=8191; // 32768 alsa_snd_pcm_open_write( sample_rate , chan , & frames , & handle); ....... while (1) { ....... rc = snd_pcm_writei(handle, buffer, frames); if (rc == -EPIPE) { /* EPIPE means underrun */ fprintf(stderr, "underrun occurred\n"); snd_pcm_prepare(handle); } else if (rc < 0) { fprintf(stderr, "error from writei: %s\n", snd_strerror(rc)); } else if (rc != (int)frames) { fprintf(stderr,"short write, write %d frames\n", rc); } ....... } snd_pcm_drain(handle); snd_pcm_close(handle); }// main ------ From torbenh at gmx.de Fri Mar 24 14:18:17 2006 From: torbenh at gmx.de (torbenh@gmx.de) Date: Fri Mar 24 14:22:48 2006 Subject: [linux-audio-dev] [ANN] netjack-0.10 Message-ID: <20060324191817.GB8053@mobilat> netjack-0.10 comes with a huge quality improvement to alsa_in and alsa_out. its now ready for prime time. try alsa_out -f 10000 and listen... -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From richard.spindler at gmail.com Sat Mar 25 03:03:02 2006 From: richard.spindler at gmail.com (Richard Spindler) Date: Sat Mar 25 03:03:08 2006 Subject: [linux-audio-dev] select() ?? before snd_pcm_writei(handle, buffer, frames); In-Reply-To: <1143211356.4424055c1f67e@www.inbox.lv> References: <1143211356.4424055c1f67e@www.inbox.lv> Message-ID: <4af8d6ff0603250003x3c9e8802g@mail.gmail.com> 2006/3/24, kurmisk : > I have write my small _alsa_test_program_. > [C code ckunkz see below] > It works good but now i wanna before call > rc = snd_pcm_writei(handle, buffer, frames); > somehow check - is sound device free for this call or not. > > For OSS i have such problem solve with select() : > fdo = open("/dev/dsp", O_WRONLY ); > ..... > FD_ZERO(&wfds); > FD_SET( fdo , &wfds); Zeit.tv_sec=0; Zeit.tv_usec=1; > response=select(fdo+1, NULL, &wfds, NULL, & Zeit ); You can use snd_pcm_poll_descriptors to get a fildescriptor to select on. -Richard From kjetil at ccrma.stanford.edu Sat Mar 25 17:21:47 2006 From: kjetil at ccrma.stanford.edu (Kjetil S. Matheussen) Date: Sat Mar 25 17:22:11 2006 Subject: [linux-audio-dev] [ANN] Snd-ls V0.9.5.5, Das_Watchdog V0.2.2 and Ceres V0.44 In-Reply-To: References: Message-ID: ***************************************************************************** 1. Snd-ls v0.9.5.5 =============== Contains -------- Snd v7.15 from 17.8.2005 About ----- Snd-ls is a distribution of the sound editor Snd. Its target is people that don't know scheme very well, and don't want to spend too much time configuring Snd. It can also serve as a quick introduction to Snd and how it can be set up. Changes 0.9.5.4 -> 0.9.5.5 -------------------------- -Reenabled code in the configure script to check for liblrdf. Thanks to Andres Cabrera for pointing this out. -Simplifed the ladspa stuff. It now works with guile 1.8, use a lot less time to start, and more than one instance of the same ladspa plugin can be run at once. -Removed check code for guile earlier than 1.8. It now works with guile 1.8. -Added code to cache compiled object files. This reduces startup time a lot. -Updated rt-stuff to latest version. -Fixed that pressing any of the control on/off buttons also started playing. -Included GTK mnemonics code from Maxim Krikun. -Print debug info to stdout when something goes wrong in a hook or timed callback. -Backported Bill's fix for segfaulting when changing filter order when playing. Bug found by Tim Blechman. (-The included diff-file between SND v7.15 vs. SND-ls is now 108000 bytes. Probably time to move on to SND v7.20.) http://ccrma.stanford.edu/~kjetil/src/ ***************************************************************************** 2. Ceres V0.44 =========== Ceres is an advanced program for displaying sonograms and for doing sound effects in the frequency domain. And more. Changes 0.43 -> 0.44 --------------------- -Fixed some compiling problems for gcc4 -Give warning about the additiv resynthesis. It might not produce correct result. -Disabled built in support for jack. Sndlib does a much better job of supporting jack than ceres. -Included latest version of sndlib. The previous included version segfaulted the program at startup. Well, works now. Tested with both fedora core 4 and redhat 8. http://ccrma.stanford.edu/~kjetil/src/ ***************************************************************************** 3. Das_Watchdog V0.2.2 =================== About ----- Das_Watchdog is a general watchdog for the linux operating system that should be runned in the background at all times to ensure a realtime process won't hang the machine. Changes 0.2.1->0.2.2 -------------------- *Locked down memory. Don't know if its necessary. http://ccrma.stanford.edu/~kjetil/src/ From fbar at footils.org Sun Mar 26 05:00:14 2006 From: fbar at footils.org (Frank Barknecht) Date: Sun Mar 26 04:59:56 2006 Subject: [linux-audio-dev] [ann] PDX7 V2 - A 6-Op-FM synthesizer for Pd Message-ID: <20060326100014.GE12931@fliwatut.scifi> PDX7 V2 In 2001, I started learning Pd. The first bigger patch I did was a six operator FM synthesizer loosely modelled after the famous DX7, which I called PDX7. Now it's five years later and not only in retrospect this first patch is quite a mess. But I still like the sounds it generates. In the meantime I learned a lot more about Pd and about a lot of other things. So I thought, why not celebrate the fifth anniversary of me doing Pd, the fifth "birthday" with a cleaner version of the PDX7, that maybe others can understand to use as well. The result is the PDX7 V2. Read and hear more at: http://footils.org/cms/show/51 Ciao -- Frank Barknecht _ ______footils.org_ __goto10.org__ From tewner at jct.ac.il Sun Mar 26 05:24:20 2006 From: tewner at jct.ac.il (michael tewner) Date: Sun Mar 26 05:24:26 2006 Subject: [linux-audio-dev] [ann] PDX7 V2 - A 6-Op-FM synthesizer for Pd In-Reply-To: <20060326100014.GE12931@fliwatut.scifi> References: <20060326100014.GE12931@fliwatut.scifi> Message-ID: On Sun, 26 Mar 2006, Frank Barknecht wrote: > PDX7 V2 > > In 2001, I started learning Pd. The first bigger patch I did was a six > operator FM synthesizer loosely modelled after the famous DX7, which I > called PDX7. Now it's five years later and not only in retrospect > this first patch is quite a mess. But I still like the sounds it > generates. In the meantime I learned a lot more about Pd and about a > lot of other things. So I thought, why not celebrate the fifth > anniversary of me doing Pd, the fifth "birthday" with a cleaner > version of the PDX7, that maybe others can understand to use as well. > > The result is the PDX7 V2. Yay! I've had the distribution of pdx7 sitting on my computer for over a year now, but I havn't been able to sit down and figure it all out yet (Pd, etc). Thanks! > > Read and hear more at: http://footils.org/cms/show/51 > > Ciao > -- > Frank Barknecht _ ______footils.org_ __goto10.org__ > From mista.tapas at gmx.net Sun Mar 26 18:08:24 2006 From: mista.tapas at gmx.net (Florian Schmidt) Date: Sun Mar 26 18:08:51 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] [ANN] Kontroll In-Reply-To: <20060327004904.0382999a@mango.fruits> References: <20060327004904.0382999a@mango.fruits> Message-ID: <20060327010824.4ee303ed@mango.fruits> On Mon, 27 Mar 2006 00:49:04 +0200 Florian Schmidt wrote: > http://tapas.affenbande.org/?page_id=42 Oh and i forgot to ask a question: What is the canonical way for a gtk app to receive hotkey press events regardless of window focus? Flo -- Palimm Palimm! http://tapas.affenbande.org From paul at linuxaudiosystems.com Sun Mar 26 19:56:30 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Sun Mar 26 19:53:11 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] [ANN] Kontroll In-Reply-To: <20060327010824.4ee303ed@mango.fruits> References: <20060327004904.0382999a@mango.fruits> <20060327010824.4ee303ed@mango.fruits> Message-ID: <1143420990.21597.16.camel@localhost.localdomain> On Mon, 2006-03-27 at 01:08 +0200, Florian Schmidt wrote: > On Mon, 27 Mar 2006 00:49:04 +0200 > Florian Schmidt wrote: > > > http://tapas.affenbande.org/?page_id=42 > > Oh and i forgot to ask a question: > > What is the canonical way for a gtk app to receive hotkey press events > regardless of window focus? there are two ways: * the key snooper * a handler for button_press_events on the window(s) they each have their advantages and disadvantages. --p From rlrevell at joe-job.com Sun Mar 26 23:50:48 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Sun Mar 26 23:50:55 2006 Subject: [linux-audio-dev] Alsa Problem In-Reply-To: <4af8d6ff0603240509h7293be49m@mail.gmail.com> References: <4af8d6ff0603240509h7293be49m@mail.gmail.com> Message-ID: <1143435049.1792.224.camel@mindpipe> On Fri, 2006-03-24 at 14:09 +0100, Richard Spindler wrote: > I'm using snd_pcm_writei to playback some audio, however, after a > little time the call fails with the error: "File descriptor in bad > state", which I believe I cannot recover from. > > Why does this happen, and what could I do about this? > > cat /proc/asound/card0/pcm0p/sub0/* prints the following stuff, I > don't know whether this is helpful? > > access: MMAP_INTERLEAVED You have set up the device for MMAP mode with snd_pcm_hw_params_set_access() but are trying to use read/write which won't work. Set the access mode to RW. Lee From richard.spindler at gmail.com Mon Mar 27 01:52:34 2006 From: richard.spindler at gmail.com (Richard Spindler) Date: Mon Mar 27 01:52:37 2006 Subject: [linux-audio-dev] Alsa Problem In-Reply-To: <1143435049.1792.224.camel@mindpipe> References: <4af8d6ff0603240509h7293be49m@mail.gmail.com> <1143435049.1792.224.camel@mindpipe> Message-ID: <4af8d6ff0603262252o6c833fa1i@mail.gmail.com> 2006/3/27, Lee Revell : > > access: MMAP_INTERLEAVED > > You have set up the device for MMAP mode with > snd_pcm_hw_params_set_access() but are trying to use read/write which > won't work. Set the access mode to RW. Hm, I'm calling snd_pcm_hw_params_set_access( handle, params, SND_PCM_ACCESS_RW_INTERLEAVED ) in my code, but it seems as if there is something screwed. I'll check that, thanks for the hint. -Richard From clemens at ladisch.de Mon Mar 27 04:31:38 2006 From: clemens at ladisch.de (Clemens Ladisch) Date: Mon Mar 27 04:32:58 2006 Subject: [linux-audio-dev] Alsa Problem In-Reply-To: <1143435049.1792.224.camel@mindpipe> References: <4af8d6ff0603240509h7293be49m@mail.gmail.com> <1143435049.1792.224.camel@mindpipe> Message-ID: <20060327093138.GI2521@turing.informatik.uni-halle.de> Lee Revell wrote: > On Fri, 2006-03-24 at 14:09 +0100, Richard Spindler wrote: > > I'm using snd_pcm_writei to playback some audio, however, after a > > little time the call fails with the error: "File descriptor in bad > > state", which I believe I cannot recover from. > > > > Why does this happen, and what could I do about this? > > > > cat /proc/asound/card0/pcm0p/sub0/* prints the following stuff, I > > don't know whether this is helpful? > > > > access: MMAP_INTERLEAVED > > You have set up the device for MMAP mode I guess the actual device being used is "default" which is probably a dmix device that uses the hardware device as a slave. In this case, the hardware device will continue running even when the dmix device is in a bad state. Richard, was is the state of your device? (See snd_pcm_dump() or snd_pcm_state().) Regards, Clemens From clemens at ladisch.de Mon Mar 27 04:38:06 2006 From: clemens at ladisch.de (Clemens Ladisch) Date: Mon Mar 27 04:39:08 2006 Subject: [linux-audio-dev] select() ?? before snd_pcm_writei(handle, buffer, frames); In-Reply-To: <1143211356.4424055c1f67e@www.inbox.lv> References: <1143211356.4424055c1f67e@www.inbox.lv> Message-ID: <20060327093806.GJ2521@turing.informatik.uni-halle.de> kurmisk wrote: > I have write my small _alsa_test_program_. > [C code ckunkz see below] > It works good but now i wanna before call > rc = snd_pcm_writei(handle, buffer, frames); > somehow check - is sound device free for this call or not. You could call snd_pcm_avail_update(). If you don't want the write function to block, you can set the device to non-blocking mode, then snd_pcm_writei() will only write as much data as can be written without waiting, or will return -EAGAIN if there isn't free space at all. You can use snd_pcm_poll_descriptors() to get file handle(s) for polling (poll() is preferred over select()). HTH Clemens From clemens at ladisch.de Mon Mar 27 04:48:32 2006 From: clemens at ladisch.de (Clemens Ladisch) Date: Mon Mar 27 04:50:34 2006 Subject: [linux-audio-dev] ALSA Picture In-Reply-To: <4af8d6ff0603240530m3e12f4edu@mail.gmail.com> References: <4af8d6ff0603230227y22c67c22v@mail.gmail.com> <20060324131011.GC1671@turing.informatik.uni-halle.de> <4af8d6ff0603240530m3e12f4edu@mail.gmail.com> Message-ID: <20060327094832.GA3765@turing.informatik.uni-halle.de> Richard Spindler wrote: > 2006/3/24, Clemens Ladisch : > > The SUSPENDED and XRUN states can happen asynchronously, i.e., the > > device can go into them at any time (from some other states), and the > > next call to snd_pcm_writei() only reports them. In this regard, they > > are similar to the DISCONNECTED state. > > Is this an issue when using this async-stuff? I think the most likely > situation might be that it happens when you call writei. XRUN won't happen unless the device is running, but SUSPENDED can happen with any function that tries to access the hardware (like, e.g., snd_pcm_hw_params()). > > XRUN happens not only when an over/underrun occurs but also when some > > other error causes the device to stop (this error may be recoverable or > > not). > > What could that be? Some drivers stop the device when a DMA error occurs (which may be a real over/underrun when there was too much other activity on the PCI bus so that the data could not be transferred). The AK4114/4117 drivers put the capture device into the DRAINING state when the sample rate of the digital input changes. HTH Clemens From ico at vt.edu Mon Mar 27 13:47:09 2006 From: ico at vt.edu (ico) Date: Mon Mar 27 13:55:30 2006 Subject: [linux-audio-dev] FW: [linux-audio-user] More about consolidation of the Linux audio online resources (was: linuxdj...) Message-ID: <4439E323@zathras> Just realized that this also matters LAD members, so I am also forwarding it to the LAD list. Best wishes, Ico > -----Original Message----- > From: linux-audio-user-bounces@music.columbia.edu [mailto:linux-audio- > user-bounces@music.columbia.edu] On Behalf Of Eric Dantan Rzewnicki > Sent: Monday, March 27, 2006 12:29 PM > To: A list for linux audio users > Cc: daniel@linuxaudio.org > Subject: Re: [linux-audio-user] More about consolidation of the Linux > audioonline resources (was: linuxdj...) > > ico wrote: > > Sounds absolutely fine by me! > > > > I am not sure which would sound better, linuxaudio.org/developers or > > linuxaudio.org/lad. IMHO both have merit. Should we have both (via a > > sym-link)? > > > > Please contact me off-list for the necessary login info so that I can > begin > > uploading stuff. > > So, Do we have a new LAD site available now? > > -ERic Rz. Not yet, I initially misunderstood Paul by skimming over his e-mail that he wanted to move the content. Now that I've figured that out, it seems that the only thing we need to get the site linked is Paul's current URL/IP where he's hosting the content. Paul? Also, I am not sure what would be more effective in terms of linking linuxaudio.org/developer or linuxaudio.org/lad. IMHO both have merit (the first does not have any redundancy in its name, but the second one is more accurate in terms of traditional LAD name). Perhaps someone else wants to chime in with an opinion on this one, or should we simply link both of them for the time being so that the site becomes available while we discuss the details? ;-) Ico From pshirkey at boosthardware.com Mon Mar 27 14:51:41 2006 From: pshirkey at boosthardware.com (Patrick Shirkey) Date: Mon Mar 27 14:50:10 2006 Subject: [linux-audio-dev] FW: [linux-audio-user] More about consolidation of the Linux audio online resources (was: linuxdj...) In-Reply-To: <4439E323@zathras> References: <4439E323@zathras> Message-ID: <4428424D.9090401@boosthardware.com> ico wrote: > Just realized that this also matters LAD members, so I am also forwarding it > to the LAD list. > > Best wishes, > > Ico > >> -----Original Message----- >> From: linux-audio-user-bounces@music.columbia.edu [mailto:linux-audio- >> user-bounces@music.columbia.edu] On Behalf Of Eric Dantan Rzewnicki >> Sent: Monday, March 27, 2006 12:29 PM >> To: A list for linux audio users >> Cc: daniel@linuxaudio.org >> Subject: Re: [linux-audio-user] More about consolidation of the Linux >> audioonline resources (was: linuxdj...) >> >> ico wrote: >>> Sounds absolutely fine by me! >>> >>> I am not sure which would sound better, linuxaudio.org/developers or >>> linuxaudio.org/lad. IMHO both have merit. Should we have both (via a >>> sym-link)? >>> >>> Please contact me off-list for the necessary login info so that I can >> begin >>> uploading stuff. >> So, Do we have a new LAD site available now? >> >> -ERic Rz. > > Not yet, > > I initially misunderstood Paul by skimming over his e-mail that he wanted to > move the content. Now that I've figured that out, it seems that the only thing > we need to get the site linked is Paul's current URL/IP where he's hosting the > content. Paul? > > Also, I am not sure what would be more effective in terms of linking > linuxaudio.org/developer or linuxaudio.org/lad. IMHO both have merit (the > first does not have any redundancy in its name, but the second one is more > accurate in terms of traditional LAD name). Perhaps someone else wants to > chime in with an opinion on this one, or should we simply link both of them > for the time being so that the site becomes available while we discuss the > details? ;-) > > Ico > > vote++ => both; -- Patrick Shirkey - Boost Hardware Ltd. Http://www.boosthardware.com Http://www.djcj.org/LAU/guide/ - The Linux Audio Users guide ======================================== Apparently upon the beginning of the barrage, the donkey broke discipline and panicked, toppling the cart. At that point, the rockets disconnected from the timer, leaving them strewn around the street. Tethered to the now toppled cart, the donkey was unable to escape before the arrival of U.S. troops. United Press International Rockets on donkeys hit major Baghdad sites By P. MITCHELL PROTHERO Published 11/21/2003 11:13 AM From krampenschiesser at freenet.de Mon Mar 27 14:50:44 2006 From: krampenschiesser at freenet.de (krampenschiesser@freenet.de) Date: Mon Mar 27 14:51:07 2006 Subject: [linux-audio-dev] Midi Sync Message-ID: <20060327215044.afd387cd.krampenschiesser@freenet.de> Hi all, I'm currently writing a very simple step sequencer. It runs fine and has many features I wanted :P But the sync causes me headaches. I can start my sequencer more then one time(of course), so they all start in a sepereate window and have an own midi out thread. My problem is to sync them all. I thought that the main app, from which I launch the step seqs, has got an own thread, which count a whole tact and starts the selected midi out thread of the new seq. But as it is possible to use crazy length(as 1/7 or so) I think my sequencers will get out of sync. And if one sequencer hangs, it will get out of sync, too. But how can I get it back in sync? Questions questions questions... I hope you understand my problem and have a solution. p.s.: I want to keep it platform independent, as it uses rtmidi and sdl which run on all audio platforms. Christian -- If the facts don't fit the theory, change the facts. -- Albert Einstein From rj at spamatica.se Mon Mar 27 16:52:49 2006 From: rj at spamatica.se (Robert Jonsson) Date: Mon Mar 27 15:52:45 2006 Subject: [linux-audio-dev] [Announce] MusE 0.8.1 released Message-ID: <200603272252.49444.rj@spamatica.se> This release note is for MusE 0.8.1. It is basically a bug fix release for a note-off bug that crept into 0.8. [General] MusE is a multitrack virtual studio with midi, external, softsynths and audio support. And a bunch of other things. [URL] http://www.muse-sequencer.org/ [Changes from the ChangeLog] * Added next/prev marker, keyboard shortcut * Added LASH support (patch from evermind @ gentoo) this also means that ladcca is no longer supported * Reverted fix for silent softsynths, synths were not silenced upon [stop]. * Added Motif-Rack idf from europeen [Known issues] See the errata section on the homepage for the latest: http://www.muse-sequencer.org/wiki/index.php/Errata0.8 For a complete list of changes see the ChangeLog: http://cvs.sourceforge.net/viewcvs.py/lmuse/muse/ChangeLog?rev=1.214.2.147&on ly_with_tag=REL07&view=auto Source download available: http://sourceforge.net/project/showfiles.php?group_id=93414&package_id=184215&release_id=405163 Regards, /MusE Development team From ico at vt.edu Mon Mar 27 16:23:32 2006 From: ico at vt.edu (ico) Date: Mon Mar 27 16:27:03 2006 Subject: [linux-audio-dev] RE: [linux-audio-user] More about consolidation of the Linux audio online resources (was: linuxdj...) Message-ID: <443C4938@zathras> > i haven't even unpacked the split tarballs i got from benno. i am happy > to host (i have disk space and bandwidth), but i'd be even slightly > happier giving it to someone else to host. your call :) :-) Well, apropos the "consolidation" concept, IMHO I think it would be a good idea. Then again, I do not wish to push this onto the LAD community unless others (or at least majority), and especially yourself (since you have volunteered your resources before me), are fine with it as well. So, FWIW I'd suggest moving the site as long as others are fine with it as well. My sincere apologies if my response seems to reek of vagueness :-) > i think we should go for the lad variant for now. Sounds good! Best wishes, Ico From mista.tapas at gmx.net Mon Mar 27 16:53:48 2006 From: mista.tapas at gmx.net (Florian Schmidt) Date: Mon Mar 27 16:54:09 2006 Subject: [linux-audio-dev] [Announce] MusE 0.8.1 released In-Reply-To: <200603272252.49444.rj@spamatica.se> References: <200603272252.49444.rj@spamatica.se> Message-ID: <20060327235348.1c1be8bf@mango.fruits> On Mon, 27 Mar 2006 22:52:49 +0100 Robert Jonsson wrote: > This release note is for MusE 0.8.1. > It is basically a bug fix release for a note-off bug that crept into 0.8. > [Known issues] > See the errata section on the homepage for the latest: > http://www.muse-sequencer.org/wiki/index.php/Errata0.8 Hmm, i don't know what's up with that, but ./configure says "build without lash support" and lateron it fails: /bin/sh ../../libtool --tag=CXX --mode=link g++ -g -fno-exceptions -Wall -W -D_G NU_SOURCE -D_REENTRANT -DQT_CLEAN_NAMESPACE -DQT_NO_COMPAT -I../.. -I../../m use/widgets -I/usr/share/qt3/include -I.. -I../../synti -I../../muse/widgets -DQ T_SHARED -DQT_THREAD_SUPPORT -DQT_PLUGIN -fPIC -O3 -ffast-math -fno-exceptions - g -O2 -o fluidsynth.la -rpath /usr/local/lib/muse/synthi -module -avoid-versio n fluidsynti.lo fluidsynthgui.lo fluidsynthguibase.lo moc_fluidsynthgui.lo ../li bsynti/libsynti.la -lfluidsynth -lasound -lm -ldl -L/usr/share/qt3/lib -lqt-mt - lqui grep: /usr/lib/libladcca.la: No such file or directory /bin/sed: can't read /usr/lib/libladcca.la: No such file or directory libtool: link: `/usr/lib/libladcca.la' is not a valid libtool archive make[5]: *** [fluidsynth.la] Error 1 make[5]: Leaving directory `/home/tapas/source/build_stuff/muse-0.8.1/synti/flui dsynth' make[4]: *** [all] Error 2 make[4]: Leaving directory `/home/tapas/source/build_stuff/muse-0.8.1/synti/flui dsynth' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/tapas/source/build_stuff/muse-0.8.1/synti' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/tapas/source/build_stuff/muse-0.8.1/synti' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/tapas/source/build_stuff/muse-0.8.1' make: *** [all] Error 2 configure: WARNING: LASH support is disabled [snip] configure: MusE configured using rtcap: no LASH support: no setuid root install: no setuid root build: no VST/win support: no jade: jade doxygen: /usr/bin/doxygen graphviz: no perl: /usr/bin/perl treeviews in doxygen html output: yes C++ compiler: g++ optimizing: no debug: no optimise for arch: none installation prefix: /usr/local Software synths --------------- FluidSynth: yes System is debian unstable (gcc 4.0.3).. Flo -- Palimm Palimm! http://tapas.affenbande.org From loki.davison at gmail.com Mon Mar 27 21:21:56 2006 From: loki.davison at gmail.com (Loki Davison) Date: Mon Mar 27 21:22:00 2006 Subject: [linux-audio-dev] Re: MusE 0.8.1 released In-Reply-To: <20060327235348.1c1be8bf@mango.fruits> References: <200603272252.49444.rj@spamatica.se> <20060327235348.1c1be8bf@mango.fruits> Message-ID: On 3/28/06, Florian Schmidt wrote: > On Mon, 27 Mar 2006 22:52:49 +0100 > Robert Jonsson wrote: > > > This release note is for MusE 0.8.1. > > It is basically a bug fix release for a note-off bug that crept into 0.8. > > > [Known issues] > > See the errata section on the homepage for the latest: > > http://www.muse-sequencer.org/wiki/index.php/Errata0.8 > > Hmm, i don't know what's up with that, but ./configure says "build > without lash support" and lateron it fails: > > /bin/sh ../../libtool --tag=CXX --mode=link g++ -g -fno-exceptions -Wall -W > -D_G > NU_SOURCE -D_REENTRANT -DQT_CLEAN_NAMESPACE -DQT_NO_COMPAT -I../.. > -I../../m > use/widgets -I/usr/share/qt3/include -I.. -I../../synti -I../../muse/widgets > -DQ > T_SHARED -DQT_THREAD_SUPPORT -DQT_PLUGIN -fPIC -O3 -ffast-math > -fno-exceptions - > g -O2 -o fluidsynth.la -rpath /usr/local/lib/muse/synthi -module > -avoid-versio > n fluidsynti.lo fluidsynthgui.lo fluidsynthguibase.lo moc_fluidsynthgui.lo > ../li > bsynti/libsynti.la -lfluidsynth -lasound -lm -ldl -L/usr/share/qt3/lib > -lqt-mt - > lqui > grep: /usr/lib/libladcca.la: No such file or directory > /bin/sed: can't read /usr/lib/libladcca.la: No such file or directory > libtool: link: `/usr/lib/libladcca.la' is not a valid libtool archive > make[5]: *** [fluidsynth.la] Error 1 > make[5]: Leaving directory > `/home/tapas/source/build_stuff/muse-0.8.1/synti/flui > dsynth' > make[4]: *** [all] Error 2 > make[4]: Leaving directory > `/home/tapas/source/build_stuff/muse-0.8.1/synti/flui > dsynth' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory `/home/tapas/source/build_stuff/muse-0.8.1/synti' > make[2]: *** [all] Error 2 > make[2]: Leaving directory `/home/tapas/source/build_stuff/muse-0.8.1/synti' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/tapas/source/build_stuff/muse-0.8.1' > make: *** [all] Error 2 > > > configure: WARNING: LASH support is disabled > [snip] > configure: > > MusE configured > > using rtcap: no > LASH support: no > setuid root install: no > setuid root build: no > VST/win support: no > > jade: jade > doxygen: /usr/bin/doxygen > graphviz: no > perl: /usr/bin/perl > treeviews in doxygen > html output: yes > > C++ compiler: g++ > optimizing: no > debug: no > optimise for arch: none > > installation prefix: /usr/local > > Software synths > --------------- > FluidSynth: yes > > > System is debian unstable (gcc 4.0.3).. > > Flo > > > -- > Palimm Palimm! > http://tapas.affenbande.org > What lash is this anyway? is the modern, useful, actually handy for stuff lash as in http://www.nongnu.org/lash/ or the ladcca from dawn of time one? Loki From drobilla at connect.carleton.ca Tue Mar 28 00:31:03 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Tue Mar 28 01:02:36 2006 Subject: [linux-audio-dev] Re: MusE 0.8.1 released In-Reply-To: References: <200603272252.49444.rj@spamatica.se> <20060327235348.1c1be8bf@mango.fruits> Message-ID: <1143523863.16919.2.camel@localhost.localdomain> On Tue, 2006-28-03 at 12:21 +1000, Loki Davison wrote: > On 3/28/06, Florian Schmidt wrote: > > Hmm, i don't know what's up with that, but ./configure says "build > > without lash support" and lateron it fails: > > > > /bin/sh ../../libtool --tag=CXX --mode=link g++ -g -fno-exceptions -Wall -W > > -D_G > > NU_SOURCE -D_REENTRANT -DQT_CLEAN_NAMESPACE -DQT_NO_COMPAT -I../.. > > -I../../m > > use/widgets -I/usr/share/qt3/include -I.. -I../../synti -I../../muse/widgets > > -DQ > > T_SHARED -DQT_THREAD_SUPPORT -DQT_PLUGIN -fPIC -O3 -ffast-math > > -fno-exceptions - > > g -O2 -o fluidsynth.la -rpath /usr/local/lib/muse/synthi -module > > -avoid-versio > > n fluidsynti.lo fluidsynthgui.lo fluidsynthguibase.lo moc_fluidsynthgui.lo > > ../li > > bsynti/libsynti.la -lfluidsynth -lasound -lm -ldl -L/usr/share/qt3/lib > > -lqt-mt - > > lqui > > grep: /usr/lib/libladcca.la: No such file or directory > > /bin/sed: can't read /usr/lib/libladcca.la: No such file or directory > > libtool: link: `/usr/lib/libladcca.la' is not a valid libtool archive > > make[5]: *** [fluidsynth.la] Error 1 [snip] > What lash is this anyway? is the modern, useful, actually handy for > stuff lash as in http://www.nongnu.org/lash/ or the ladcca from dawn > of time one? 0.5.0+ versions of LASH do not contain the phrase "ladcca" in any way (including filenames). >From a quick glance, neither does Muse 0.8.1, so I would assume this is a system configuration problem. -DR- From rj at spamatica.se Tue Mar 28 02:20:25 2006 From: rj at spamatica.se (Robert Jonsson) Date: Tue Mar 28 02:20:37 2006 Subject: [linux-audio-dev] Re: MusE 0.8.1 released In-Reply-To: <1143523863.16919.2.camel@localhost.localdomain> References: <200603272252.49444.rj@spamatica.se> <1143523863.16919.2.camel@localhost.localdomain> Message-ID: <200603280920.25897.rj@spamatica.se> Hopefully it's configuration. I'll check for ladcca to be sure. To answer the previous question, the support is for lash-0.5.0, I've tested it and it works reasonbly (closing the project leads to a double-delete error in glibc which I don't know what causes) --- Also, for some reason lash has a tendency of taking down jack when closing on my system (regardless if muse is used). Does someone else see this? I should debug this a bit.. Regards, Robert On Tuesday 28 March 2006 07:31, Dave Robillard wrote: > On Tue, 2006-28-03 at 12:21 +1000, Loki Davison wrote: > > On 3/28/06, Florian Schmidt wrote: > > > Hmm, i don't know what's up with that, but ./configure says "build > > > without lash support" and lateron it fails: > > > > > > /bin/sh ../../libtool --tag=CXX --mode=link g++ -g -fno-exceptions > > > -Wall -W -D_G > > > NU_SOURCE -D_REENTRANT -DQT_CLEAN_NAMESPACE -DQT_NO_COMPAT -I../.. > > > -I../../m > > > use/widgets -I/usr/share/qt3/include -I.. -I../../synti > > > -I../../muse/widgets -DQ > > > T_SHARED -DQT_THREAD_SUPPORT -DQT_PLUGIN -fPIC -O3 -ffast-math > > > -fno-exceptions - > > > g -O2 -o fluidsynth.la -rpath /usr/local/lib/muse/synthi -module > > > -avoid-versio > > > n fluidsynti.lo fluidsynthgui.lo fluidsynthguibase.lo > > > moc_fluidsynthgui.lo ../li > > > bsynti/libsynti.la -lfluidsynth -lasound -lm -ldl -L/usr/share/qt3/lib > > > -lqt-mt - > > > lqui > > > grep: /usr/lib/libladcca.la: No such file or directory > > > /bin/sed: can't read /usr/lib/libladcca.la: No such file or directory > > > libtool: link: `/usr/lib/libladcca.la' is not a valid libtool archive > > > make[5]: *** [fluidsynth.la] Error 1 > > [snip] > > > What lash is this anyway? is the modern, useful, actually handy for > > stuff lash as in http://www.nongnu.org/lash/ or the ladcca from dawn > > of time one? > > 0.5.0+ versions of LASH do not contain the phrase "ladcca" in any way > (including filenames). > > >From a quick glance, neither does Muse 0.8.1, so I would assume this is a > > system > > configuration problem. > > -DR- From mista.tapas at gmx.net Tue Mar 28 03:44:08 2006 From: mista.tapas at gmx.net (Florian Schmidt) Date: Tue Mar 28 03:44:11 2006 Subject: [linux-audio-dev] Re: MusE 0.8.1 released In-Reply-To: <1143523863.16919.2.camel@localhost.localdomain> References: <200603272252.49444.rj@spamatica.se> <20060327235348.1c1be8bf@mango.fruits> <1143523863.16919.2.camel@localhost.localdomain> Message-ID: <20060328104408.7876c8f6@mango.fruits> On Tue, 28 Mar 2006 00:31:03 -0500 Dave Robillard wrote: > > > What lash is this anyway? is the modern, useful, actually handy for > > stuff lash as in http://www.nongnu.org/lash/ or the ladcca from dawn > > of time one? > > 0.5.0+ versions of LASH do not contain the phrase "ladcca" in any way (including > filenames). > > >From a quick glance, neither does Muse 0.8.1, so I would assume this is a system > configuration problem. I _do_ have cvs lash installed and debian's ladcca package, too. I asssumed that because of the differing naming schemes i wouldn't run into trouble. Seems i was wrong. Flo -- Palimm Palimm! http://tapas.affenbande.org From mista.tapas at gmx.net Tue Mar 28 04:13:14 2006 From: mista.tapas at gmx.net (Florian Schmidt) Date: Tue Mar 28 04:13:22 2006 Subject: [linux-audio-dev] Re: MusE 0.8.1 released In-Reply-To: <20060328104408.7876c8f6@mango.fruits> References: <200603272252.49444.rj@spamatica.se> <20060327235348.1c1be8bf@mango.fruits> <1143523863.16919.2.camel@localhost.localdomain> <20060328104408.7876c8f6@mango.fruits> Message-ID: <20060328111314.1cb2ad97@mango.fruits> On Tue, 28 Mar 2006 10:44:08 +0200 Florian Schmidt wrote: > I _do_ have cvs lash installed and debian's ladcca package, too. I > asssumed that because of the differing naming schemes i wouldn't run > into trouble. Seems i was wrong. Oh well, it seems it was a problem with debians libfluidsynth package. Running ./configure --disable-fluidsynth --enable-lash seems to change something about it as configure now fails with checking for SNDFILE... configure: error: need libsndfile >= 1.0.0 but ~/source/build_stuff/muse-0.8.1$ dpkg -l libsndfile1-dev Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-==============-==============-============================================ ii libsndfile1-de 1.0.15-1 Library for reading/writing audio files Anyways, Thorsten Willms mentioned the export PKG_CONFIG=/usr/bin/pkg-config thing and now it _seems_ to build. We'll see.. Flo -- Palimm Palimm! http://tapas.affenbande.org From rj at spamatica.se Tue Mar 28 12:43:06 2006 From: rj at spamatica.se (Robert Jonsson) Date: Tue Mar 28 11:42:56 2006 Subject: [linux-audio-dev] Re: MusE 0.8.1 released In-Reply-To: <20060328111314.1cb2ad97@mango.fruits> References: <200603272252.49444.rj@spamatica.se> <20060328104408.7876c8f6@mango.fruits> <20060328111314.1cb2ad97@mango.fruits> Message-ID: <200603281843.07266.rj@spamatica.se> On Tuesday 28 Mar 2006 10:13, Florian Schmidt wrote: <...> > > thing and now it _seems_ to build. We'll see.. > > Flo Just curious, did it work out? Regards, Robert -- http://spamatica.se/musicsite/ From mista.tapas at gmx.net Tue Mar 28 12:54:08 2006 From: mista.tapas at gmx.net (Florian Schmidt) Date: Tue Mar 28 12:54:19 2006 Subject: [linux-audio-dev] Re: MusE 0.8.1 released In-Reply-To: <200603281843.07266.rj@spamatica.se> References: <200603272252.49444.rj@spamatica.se> <20060328104408.7876c8f6@mango.fruits> <20060328111314.1cb2ad97@mango.fruits> <200603281843.07266.rj@spamatica.se> Message-ID: <20060328195408.16ba893d@mango.fruits> On Tue, 28 Mar 2006 18:43:06 +0100 Robert Jonsson wrote: > On Tuesday 28 Mar 2006 10:13, Florian Schmidt wrote: > <...> > > > > thing and now it _seems_ to build. We'll see.. > > > > Flo > > Just curious, did it work out? Nope make[4]: Entering directory `/home/tapas/source/build_stuff/muse-0.8.1/muse' if g++ -DHAVE_CONFIG_H -I. -I. -I.. -Imidiedit -Iarranger -Iliste -Iwidgets -Im ixer -Idriver -Iwaveedit -Implugins -Iinstruments -DINSTPREFIX=\"/usr/local\" - g -fno-exceptions -Wall -W -D_GNU_SOURCE -D_REENTRANT -DQT_CLEAN_NAMESPACE -DQ T_NO_COMPAT -I.. -I../muse/widgets -I/usr/share/qt3/include -I.. -I../synti -I ../muse/widgets -DQT_SHARED -DQT_THREAD_SUPPORT -DQT_PLUGIN -I/usr/include/alsa -I/usr/local/include/lash-1.0 -g -O2 -MT app.o -MD -MP -MF ".deps/app.Tpo" -c -o app.o app.cpp; \ then mv -f ".deps/app.Tpo" ".deps/app.Po"; else rm -f ".deps/app.Tpo"; e xit 1; fi widgets/canvas.h:93: warning: unused parameter 'item' widgets/canvas.h:111: warning: unused parameter 'item' widgets/canvas.h:111: warning: unused parameter 'n' widgets/canvas.h:111: warning: unused parameter 'pt' /usr/share/qt3/include/qtooltip.h:86: warning: 'class QToolTip' has virtual func tions but non-virtual destructor midiedit/drumedit.h:61: warning: 'class DHeaderTip' has virtual functions but no n-virtual destructor ./synth.h:75: warning: 'class SynthIF' has virtual functions but non-virtual des tructor ./synth.h:173: warning: 'class MessSynthIF' has virtual functions but non-virtua l destructor /usr/share/qt3/include/qnetworkprotocol.h:58: warning: 'class QNetworkProtocolFa ctoryBase' has virtual functions but non-virtual destructor /usr/share/qt3/include/qfiledialog.h:78: warning: 'class QFilePreview' has virtu al functions but non-virtual destructor app.cpp: In member function 'void MusE::toplevelDeleted(long unsigned int)': app.cpp:1642: warning: format '%x' expects type 'unsigned int', but argument 2 h as type 'long unsigned int' app.cpp: At global scope: app.cpp:1766: warning: unused parameter 'e' app.cpp: In member function 'void MusE::lash_idle_cb()': app.cpp:2730: error: jump to case label app.cpp:2720: error: crosses initialization of 'int ok' app.cpp:2719: error: crosses initialization of 'const char* name' app.cpp:2736: error: jump to case label app.cpp:2720: error: crosses initialization of 'int ok' app.cpp:2719: error: crosses initialization of 'const char* name' app.cpp:2743: error: jump to case label app.cpp:2720: error: crosses initialization of 'int ok' app.cpp:2719: error: crosses initialization of 'const char* name' make[4]: *** [app.o] Error 1 make[4]: Leaving directory `/home/tapas/source/build_stuff/muse-0.8.1/muse' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/tapas/source/build_stuff/muse-0.8.1/muse' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/tapas/source/build_stuff/muse-0.8.1/muse' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/tapas/source/build_stuff/muse-0.8.1' make: *** [all] Error 2 Looks like Frieder's Patch might fix it.. Testing.. Flo -- Palimm Palimm! http://tapas.affenbande.org From rj at spamatica.se Tue Mar 28 13:25:39 2006 From: rj at spamatica.se (Robert Jonsson) Date: Tue Mar 28 13:25:52 2006 Subject: [linux-audio-dev] Re: MusE 0.8.1 released In-Reply-To: <20060328195408.16ba893d@mango.fruits> References: <200603272252.49444.rj@spamatica.se> <200603281843.07266.rj@spamatica.se> <20060328195408.16ba893d@mango.fruits> Message-ID: <200603282025.39317.rj@spamatica.se> > app.cpp:2730: error: jump to case label > app.cpp:2720: error: crosses initialization of 'int ok' <...> > Looks like Frieder's Patch might fix it.. Testing.. Yes I think so. FWIW there's a new package on the site now where this is added. Regards, Robert > > Flo From drobilla at connect.carleton.ca Wed Mar 29 02:03:05 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Wed Mar 29 02:03:10 2006 Subject: [linux-audio-dev] Re: MusE 0.8.1 released In-Reply-To: <200603280920.25897.rj@spamatica.se> References: <200603272252.49444.rj@spamatica.se> <1143523863.16919.2.camel@localhost.localdomain> <200603280920.25897.rj@spamatica.se> Message-ID: <1143615785.25850.1.camel@localhost.localdomain> On Tue, 2006-28-03 at 09:20 +0200, Robert Jonsson wrote: > Hopefully it's configuration. I'll check for ladcca to be sure. > > To answer the previous question, the support is for lash-0.5.0, I've tested it > and it works reasonbly (closing the project leads to a double-delete error in > glibc which I don't know what causes) > > --- > Also, for some reason lash has a tendency of taking down jack when closing on > my system (regardless if muse is used). Does someone else see this? I should > debug this a bit.. When closing a session, or killing lashd entirely? -DR- From dlphillips at woh.rr.com Wed Mar 29 06:21:15 2006 From: dlphillips at woh.rr.com (Dave Phillips) Date: Wed Mar 29 05:48:46 2006 Subject: [linux-audio-dev] regarding the 2nd Book Of Linux Music & Sound Message-ID: <442A6DAB.1010004@woh.rr.com> Greetings: My publisher, Bill Pollock, has been gently pressuring me to commit to completing the 2nd edition of The Book Of Linux Music & Sound. Unfortunately I'm in a precarious position to commit myself to the work. The first book nearly wiped me out, I'm not sure I can sustain the effort to bring the next edition to light. Nevertheless, I'm still interested in seeing this book through to completion. So I have some questions for the community : 1. Is there a real need for another book such as the The Book Of Linux Music & Sound ? 2. If so, would I be wise to ignore the 2.4 kernel series ? (It would make it easier to ignore material re: OSS/Free) 3. Would anyone be interested in co-authoring the book ? I've considered offering some chapters to certain people on these lists, but the issue of reimbursement gets sticky WRT royalties and other compensation. I made very little money from the first book, but money wasn't the true reward anyway, so perhaps there's a way to turn it into a community-based work. 4. Is anyone else already working on such a project ? I don't want to duplicate efforts. Btw, this is the last hurrah for this project. If I don't take it now I won't be taking it on at all. I have a life, it's pretty full, and committing to this edition would be a major disruption. I can guarantee that it would be the last book I'll ever write. I look forward to your comments and advice. Best regards, dp From dak at gnu.org Wed Mar 29 05:53:00 2006 From: dak at gnu.org (David Kastrup) Date: Wed Mar 29 05:53:13 2006 Subject: [linux-audio-dev] regarding the 2nd Book Of Linux Music & Sound In-Reply-To: <442A6DAB.1010004@woh.rr.com> (Dave Phillips's message of "Wed, 29 Mar 2006 06:21:15 -0500") References: <442A6DAB.1010004@woh.rr.com> Message-ID: <857j6ded4j.fsf@lola.goethe.zz> Dave Phillips writes: > 2. If so, would I be wise to ignore the 2.4 kernel series ? (It > would make it easier to ignore material re: OSS/Free) I'd say so. People with enough interest in sound to buy the book will not be likely running old kernels. 2.4 sounds like not being worth considering in my opinion. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum From aamehl at actcom.net.il Wed Mar 29 07:20:57 2006 From: aamehl at actcom.net.il (aamehl@actcom.net.il) Date: Wed Mar 29 07:21:14 2006 Subject: [linux-audio-dev] regarding the 2nd Book Of Linux Music & Sound In-Reply-To: <442A6DAB.1010004@woh.rr.com> References: <442A6DAB.1010004@woh.rr.com> Message-ID: <1143634857.442a7ba995a67@webmail.actcom.net.il> Hi Dave, You don't have to do everything, you know. I would say that if I was to vote, I would vote for a community based project. This have to be closed ended, what I mean is since the projects themselves have much to gain by being included in such a book, if they are interested in the exposure why wouldn't they be interested in contributing. Beyond that if the publisher is agreeable to having two versions: one for sale and one free, then it could evolve into sorta a linuxaudio-docs project. I would think this is an important project, but not to kill yourself over. Aaron If I didn't just start a course and full-time techwriting, I would have said I would write it...... Aaron From elisa.zwei at googlemail.com Wed Mar 29 08:41:52 2006 From: elisa.zwei at googlemail.com (Tobias Scharnberg) Date: Wed Mar 29 08:41:57 2006 Subject: [linux-audio-dev] fast linear resampling on ARM - suggestions? Message-ID: <1448f040603290541p1877e76bscb8b3773505031e7@mail.gmail.com> Hello List, I'm trying to find a library or code-snippet in order to do audio resampling from 8khz to 44,1khz and from 44,1khz to 8khz. I need to resample the data in realtime - resampling a buffer of data, not a soundfile. The quality doesn't need to be good so I guess the best solution might be linear audio resampling. The device to do the resampling on is an ARM CM-X255 running at 400MHz. I tried out libsamplerate so far but when I tested it with the soundfile conversion test program it needed 3,5 secs to sample from 8kHz to 44,1 khz for a 1,7 secs audiofile - which is too slow for me. Is there something faster that can do the job? Any suggestions are highly welcome Greetings, Tobias From mle+la at mega-nerd.com Wed Mar 29 08:47:30 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Wed Mar 29 08:47:38 2006 Subject: [linux-audio-dev] fast linear resampling on ARM - suggestions? In-Reply-To: <1448f040603290541p1877e76bscb8b3773505031e7@mail.gmail.com> References: <1448f040603290541p1877e76bscb8b3773505031e7@mail.gmail.com> Message-ID: <20060329234730.733e22b9.mle+la@mega-nerd.com> Tobias Scharnberg wrote: > Hello List, > I'm trying to find a library or code-snippet in order to do audio > resampling from 8khz to 44,1khz and from 44,1khz to 8khz. I need to > resample the data in realtime - resampling a buffer of data, not a > soundfile. The quality doesn't need to be good so I guess the best > solution might be linear audio resampling. The device to do the > resampling on is an ARM CM-X255 running at 400MHz. > > I tried out libsamplerate so far but when I tested it with the > soundfile conversion test program it needed 3,5 secs to sample from > 8kHz to 44,1 khz for a 1,7 secs audiofile - which is too slow for me. libsamplerate uses floating point calculations and most ARM CPUs don't have an FPU. Julius O. Smith's original resample program used integer arithmetic and would therefore be a better choice. However, please do not use linear resampling; its just too crappy. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "I have never met anyone who can do Scheme, Haskell, and C pointers who can't pick up Java in two days, and create better Java code than people with five years of experience in Java." -- http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html From luisgarrido at users.sourceforge.net Wed Mar 29 10:41:56 2006 From: luisgarrido at users.sourceforge.net (Luis Garrido) Date: Wed Mar 29 10:42:02 2006 Subject: [linux-audio-dev] regarding the 2nd Book Of Linux Music & Sound In-Reply-To: <442A6DAB.1010004@woh.rr.com> References: <442A6DAB.1010004@woh.rr.com> Message-ID: > 1. Is there a real need for another book such as the The Book Of Linux > Music & Sound ? > I bought my latest computer book some ten years ago. Things go too fast nowadays and from the moment the author ends the writing until it reaches my bookshop the information it contains is already dated. Furthermore, linux audio is at a fluid point where many things are coming together, but are not there just yet for the end user. As far as I am concerned, and of course YMMV, key areas where I feel commercial software is still years ahead are Virtual Studio and WYSIWYG music notation, among others. What is the profile of the potential reader? Non-technical people will be scared of Linux if their distro doesn't detect their hardware at the installation. Developers are used to find the information they need on the net, although they can appreciate a good reference book on _stable_ technologies. For the technically oriented musician perhaps there is not that much readily usable software yet. I think I wouldn't take the job if the only reasons were financial. Perhaps in a couple of years. Until then, I am looking forward to this web that aggregates the scattered resources around that people have been talking about. My 2 eurocents, Luis From rzewnickie at rfa.org Wed Mar 29 12:47:33 2006 From: rzewnickie at rfa.org (Eric Dantan Rzewnicki) Date: Wed Mar 29 12:47:46 2006 Subject: [linux-audio-dev] regarding the 2nd Book Of Linux Music & Sound In-Reply-To: <1143634857.442a7ba995a67@webmail.actcom.net.il> References: <442A6DAB.1010004@woh.rr.com> <1143634857.442a7ba995a67@webmail.actcom.net.il> Message-ID: <20060329174733.GB2569@rfa.org> On Wed, Mar 29, 2006 at 02:20:57PM +0200, aamehl@actcom.net.il wrote: > Hi Dave, > You don't have to do everything, you know. > > I would say that if I was to vote, I would vote for a community based project. > This have to be closed ended, what I mean is since the projects themselves have > much to gain by being included in such a book, if they are interested in the > exposure why wouldn't they be interested in contributing. > > Beyond that if the publisher is agreeable to having two versions: > > one for sale and one free, then it could evolve into sorta a linuxaudio-docs > project. IIRC, there was such an agreement with regard to Dave's book becoming the docs for the A/Demudi project at one point ... > I would think this is an important project, but not to kill yourself over. Second that. I think everyone here wants Dave around for as long as possible in a coherent and healthy state. :) > Aaron > If I didn't just start a course and full-time techwriting, I would have said I > would write it...... I would like to help, too, but then I seem to say that about way too many things. So, as usual I can't promise anything just yet. If I could just ditch my job and be a full time linux audio bum I would definitely help ... but, well, reality and all that ... -- Eric Dantan Rzewnicki Apprentice Linux Audio Developer and Mostly Harmless Sysadmin (text below this line mandated by management) Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact network@rfa.org. From pcoccoli at gmail.com Wed Mar 29 13:08:40 2006 From: pcoccoli at gmail.com (Paul Coccoli) Date: Wed Mar 29 13:08:50 2006 Subject: [linux-audio-dev] regarding the 2nd Book Of Linux Music & Sound In-Reply-To: References: <442A6DAB.1010004@woh.rr.com> Message-ID: <8d27a0610603291008o26eeb4c8kf68a84606abcb194@mail.gmail.com> On 3/29/06, Luis Garrido wrote: > > 1. Is there a real need for another book such as the The Book Of Linux > > Music & Sound ? > > > > I bought my latest computer book some ten years ago. Things go too > fast nowadays and from the moment the author ends the writing until it > reaches my bookshop the information it contains is already dated. > > Furthermore, linux audio is at a fluid point where many things are > coming together, but are not there just yet for the end user. As far > as I am concerned, and of course YMMV, key areas where I feel > commercial software is still years ahead are Virtual Studio and > WYSIWYG music notation, among others. > > What is the profile of the potential reader? Non-technical people will > be scared of Linux if their distro doesn't detect their hardware at > the installation. Developers are used to find the information they > need on the net, although they can appreciate a good reference book on > _stable_ technologies. For the technically oriented musician perhaps > there is not that much readily usable software yet. > > I think I wouldn't take the job if the only reasons were financial. > Perhaps in a couple of years. Until then, I am looking forward to this > web that aggregates the scattered resources around that people have > been talking about. > > My 2 eurocents, > > Luis > I think I have to second this. I own the first edition, but I don't think a second would be helpful to me or too many others (due to the current rate of development). The type of info that would be in a second edition, in addition to the tutorial-style stuff mentioned in another post, would be a great reference for everyone if it were on-line and maintained by capable writers (like Dave). However, the current scattered and incomplete tutorials, Howtos, manuals, and wikis make me think that such a resource will never exist. I'm not blaming anyone for that, since I never contribute to those efforts either. From torbenh at gmx.de Wed Mar 29 15:05:22 2006 From: torbenh at gmx.de (torbenh@gmx.de) Date: Wed Mar 29 15:09:41 2006 Subject: [linux-audio-dev] linear resampling is crap ? (was: fast linear resampling on ARM - suggestions?) In-Reply-To: <20060329234730.733e22b9.mle+la@mega-nerd.com> References: <1448f040603290541p1877e76bscb8b3773505031e7@mail.gmail.com> <20060329234730.733e22b9.mle+la@mega-nerd.com> Message-ID: <20060329200522.GB8430@mobilat> On Wed, Mar 29, 2006 at 11:47:30PM +1000, Erik de Castro Lopo wrote: > Tobias Scharnberg wrote: > > However, please do not use linear resampling; its just too crappy. urgh... i just switched my local copies of alsa_in and _out to linear resampling, because SRC_SINC_FASTEST was eating CPU juice. i should add yet another switch to the programs. -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From ico.bukvic at gmail.com Wed Mar 29 17:28:42 2006 From: ico.bukvic at gmail.com (Ivica Ico Bukvic) Date: Wed Mar 29 17:28:53 2006 Subject: [linux-audio-dev] New LAD site is up and needs work Message-ID: <002401c65380$24692e30$0f00000a@64BitBadass> Hi all, I've uploaded the LAD materials from Paul's server and Daniel has updated the DNS. So, the new site is residing at lad.linuxaudio.org and should be available as soon as I get the php working (hacking an OSX machine remotely is like pulling teeth :-P). That being said, the site as it is has tons of hard links utilizing the old linuxdj site and some of the subdir structure is messy (i.e. the lad site is currently in lad.linuxaudio.org/lad). This needs to be worked on before the site is fully functional. Whoever commits to fixing this up, I will gladly get you the account/pass info into the lad account so that you can make the necessary updates. Not to point any fingers, but I thought I saw Eric raise his hand to volunteer for this task? ;-) On a side-note, the consortium site has been also transferred. E-mail accounts have not been ported as of yet, but I hope to take care of that in the next week or so. In the meantime I've posted my work e-mail on the website until this transfer is complete. Dave, if you want to have your e-mail temporarily displayed on the linuxaudio.org contact page, so that you can be also contacted until the e-mail transfer is complete, just let me know and I'll update the site accordingly. Best wishes, Ivica Ico Bukvic, D.M.A. Composition Virginia Tech Dept. of Music - 0240 Blacksburg, VA 24061 (540) 231-7047 (540) 231-5034 (fax) ico@vt.edu http://www.music.vt.edu/people/faculty/bukvic/ From ico.bukvic at gmail.com Wed Mar 29 17:34:18 2006 From: ico.bukvic at gmail.com (Ivica Ico Bukvic) Date: Wed Mar 29 17:34:31 2006 Subject: [linux-audio-dev] RE: New LAD site is up and needs work Message-ID: <000001c65380$ed095950$0f00000a@64BitBadass> OK, php is up-and-running. So, the LAD site is now working fine at lad.linuxaudio.org/lad. Ico From kjetil at ccrma.stanford.edu Wed Mar 29 17:40:51 2006 From: kjetil at ccrma.stanford.edu (Kjetil S. Matheussen) Date: Wed Mar 29 17:40:57 2006 Subject: [linux-audio-dev] Re: fast linear resampling on ARM - suggestions? In-Reply-To: <20060329223434.E158BDAD186@music.columbia.edu> References: <20060329223434.E158BDAD186@music.columbia.edu> Message-ID: "Tobias Scharnberg": > > Hello List, > I'm trying to find a library or code-snippet in order to do audio > resampling from 8khz to 44,1khz and from 44,1khz to 8khz. I need to > resample the data in realtime - resampling a buffer of data, not a > soundfile. The quality doesn't need to be good so I guess the best > solution might be linear audio resampling. The device to do the > resampling on is an ARM CM-X255 running at 400MHz. > > I tried out libsamplerate so far but when I tested it with the > soundfile conversion test program it needed 3,5 secs to sample from > 8kHz to 44,1 khz for a 1,7 secs audiofile - which is too slow for me. > > Is there something faster that can do the job? > Was this with the linear resampler lib libsamplerate? In case, you should know that its terrible slow. Last time I tried, the fastest sinc resampler in CLM was almost as fast as the linear resampler in libsamplerate. (Erik, you should do something about that...) I don't know of any other libraries that does linear resampling, but its not that difficult to make one manually. I'm sure there are example codes floating around as well. From v2 at iki.fi Thu Mar 30 00:55:44 2006 From: v2 at iki.fi (Sampo Savolainen) Date: Thu Mar 30 00:56:10 2006 Subject: [linux-audio-dev] Re: [ardour-users] Jack is Jacked Message-ID: <1143698144.442b72e04e644@www1.helsinki.fi> Quoting Mike Fisher : > Gentoo Linux 2.6.10 kernel > > alsa-driver-1.0.10 > jack -0.100.7 > qjackctl-0.2.19a > > Nah... jack isn't really jacked. I just keep having a strange > occurance. > > Everytime i start jack for the first time I get this message.... > > cannot write to jackstart sync pipe 4 (Bad file descriptor) > ... > jackd: wait for startup process exit failed > jackd 0.100.7 > > and a pop-up in qjackctl that reads "Could not connect to JACK server as > client. Please check the messages window for more info." You probably have multiple versions of jack installed. Both in /usr and in /usr/local/ Have you by any chance built jackd yourself (without specifying --prefix=/usr to the "configure" script) and installed a version of jackd from your distribution? If yes, you should remove the one you don't want to use. Either remove the package installed from your distribution via rpm or apt-get or whatever your distro uses, or do a "make uninstall" from the jackd source directory you built & installed jackd from. Sampo From mle+la at mega-nerd.com Thu Mar 30 01:34:43 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Thu Mar 30 01:34:51 2006 Subject: [linux-audio-dev] linear resampling is crap ? (was: fast linear resampling on ARM - suggestions?) In-Reply-To: <20060329200522.GB8430@mobilat> References: <1448f040603290541p1877e76bscb8b3773505031e7@mail.gmail.com> <20060329234730.733e22b9.mle+la@mega-nerd.com> <20060329200522.GB8430@mobilat> Message-ID: <20060330163443.0a6ab1e4.mle+la@mega-nerd.com> torbenh@gmx.de wrote: > On Wed, Mar 29, 2006 at 11:47:30PM +1000, Erik de Castro Lopo wrote: > > Tobias Scharnberg wrote: > > > > However, please do not use linear resampling; its just too crappy. > > urgh... i just switched my local copies of alsa_in and _out to linear > resampling, because SRC_SINC_FASTEST was eating CPU juice. Just out of curiosity, what kind of hardware are you running this on and what sort of performance would you find acceptable for your application. An estimate that provides: - input and output sample rates - samples per second per channel throughput wrt the output rate would give me the best idea of what you are after. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ Question #2459: Ruling on shaking hands with the opposite sex http://islamqa.com/index.php?ln=eng&ds=qa&lv=browse&QR=2459&dgn=4 From mle+la at mega-nerd.com Thu Mar 30 01:34:58 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Thu Mar 30 01:35:16 2006 Subject: [linux-audio-dev] Re: fast linear resampling on ARM - suggestions? In-Reply-To: References: <20060329223434.E158BDAD186@music.columbia.edu> Message-ID: <20060330163458.19375965.mle+la@mega-nerd.com> Kjetil S. Matheussen wrote: > Was this with the linear resampler lib libsamplerate? In case, you should > know that its terrible slow. Last time I tried, the fastest sinc resampler > in CLM was almost as fast as the linear resampler in libsamplerate. > (Erik, you should do something about that...) Maybe I haven't made myself clear. IMHO linear resampling sucks for audio. It is included in libsamplerate purely so I can show how bad it actually is. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "I do have a policy of mandatory evisceration where the crime of whitespace in filenames is perpetrated on my systems. This has inspired a new range of designer colostomy bag covers in corduroy, velvet, and the ever popular denim." -- jdub on the SLUG mailing list From luisgarrido at users.sourceforge.net Thu Mar 30 03:12:02 2006 From: luisgarrido at users.sourceforge.net (Luis Garrido) Date: Thu Mar 30 03:12:55 2006 Subject: [linux-audio-dev] Re: fast linear resampling on ARM - suggestions? In-Reply-To: <20060330163458.19375965.mle+la@mega-nerd.com> References: <20060329223434.E158BDAD186@music.columbia.edu> <20060330163458.19375965.mle+la@mega-nerd.com> Message-ID: Fast 'n dirty vs slow 'n clean is a common trade-off in a zillion applications. It is good to have choices. Luis On 3/30/06, Erik de Castro Lopo wrote: > Kjetil S. Matheussen wrote: > > > Was this with the linear resampler lib libsamplerate? In case, you should > > know that its terrible slow. Last time I tried, the fastest sinc resampler > > in CLM was almost as fast as the linear resampler in libsamplerate. > > (Erik, you should do something about that...) > > Maybe I haven't made myself clear. IMHO linear resampling sucks > for audio. It is included in libsamplerate purely so I can > show how bad it actually is. > > Erik > -- > +-----------------------------------------------------------+ > Erik de Castro Lopo > +-----------------------------------------------------------+ > "I do have a policy of mandatory evisceration where the crime of > whitespace in filenames is perpetrated on my systems. This has > inspired a new range of designer colostomy bag covers in corduroy, > velvet, and the ever popular denim." > -- jdub on the SLUG mailing list > From stefan at space.twc.de Thu Mar 30 06:51:26 2006 From: stefan at space.twc.de (Stefan Westerfeld) Date: Thu Mar 30 03:35:38 2006 Subject: [linux-audio-dev] linear resampling is crap ? (was: fast linear resampling on ARM - suggestions?) In-Reply-To: <20060330163443.0a6ab1e4.mle+la@mega-nerd.com> References: <1448f040603290541p1877e76bscb8b3773505031e7@mail.gmail.com> <20060329234730.733e22b9.mle+la@mega-nerd.com> <20060329200522.GB8430@mobilat> <20060330163443.0a6ab1e4.mle+la@mega-nerd.com> Message-ID: <20060330115126.GA31683@space.twc.de> Hi! On Thu, Mar 30, 2006 at 04:34:43PM +1000, Erik de Castro Lopo wrote: > torbenh@gmx.de wrote: > > > On Wed, Mar 29, 2006 at 11:47:30PM +1000, Erik de Castro Lopo wrote: > > > Tobias Scharnberg wrote: > > > > > > However, please do not use linear resampling; its just too crappy. > > > > urgh... i just switched my local copies of alsa_in and _out to linear > > resampling, because SRC_SINC_FASTEST was eating CPU juice. > > Just out of curiosity, what kind of hardware are you running this > on and what sort of performance would you find acceptable for your > application. An estimate that provides: > > - input and output sample rates > - samples per second per channel throughput wrt the output rate > > would give me the best idea of what you are after. By the way, if you have a clear idea how to constrain the resampling process, it should be possible to be quite fast (well, of course it depends on what fast is) while maintaining good quality. From my recent work on SSE based resampling code for BEAST: performance test for factor 2 upsampling using SSE instructions (performance will be normalized to upsampler input samples) total samples processed = 64000000 processing_time = 1.268400 samples / second = 50457270.836486 which means the resampler can process 1144.16 44100 Hz streams simultaneusly or one 44100 Hz stream takes 0.087401 % CPU usage Note that it is normalized to input rate, not output rate. It would perform twice as good when normalized to output rate. But it is not an arbitary-rate upsampler but factor 2 upsampling, and values were measured on a fast processor (AMD64, 2200 MHz). Details: http://mail.gnome.org/archives/beast/2006-March/msg00001.html Measuring the same example with libsamplerate with SRC_SINC_FASTEST gives a throughput of 1233140 samples/second, which means that my code is about 41 times faster. Cu... Stefan -- Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan From asbjs at stud.ntnu.no Thu Mar 30 03:50:44 2006 From: asbjs at stud.ntnu.no (=?iso-8859-1?B?QXNiavhybiBT5mL4?=) Date: Thu Mar 30 03:51:08 2006 Subject: [linux-audio-dev] regarding the 2nd Book Of Linux Music & Sound In-Reply-To: <442A6DAB.1010004@woh.rr.com> References: <442A6DAB.1010004@woh.rr.com> Message-ID: <20060330085044.GA27656@stud.ntnu.no> On Wed, Mar 29, 2006 at 06:21:15AM -0500, Dave Phillips wrote: > Greetings: > > My publisher, Bill Pollock, has been gently pressuring me to commit to > completing the 2nd edition of The Book Of Linux Music & Sound. > Unfortunately I'm in a precarious position to commit myself to the work. > The first book nearly wiped me out, I'm not sure I can sustain the > effort to bring the next edition to light. Nevertheless, I'm still > interested in seeing this book through to completion. So I have some > questions for the community : > > 1. Is there a real need for another book such as the The Book Of Linux > Music & Sound ? I have been missing it, and would most probably buy it. I would encourage you to do it. Asbj?rn From kjetil at ccrma.stanford.edu Thu Mar 30 03:52:37 2006 From: kjetil at ccrma.stanford.edu (Kjetil S. Matheussen) Date: Thu Mar 30 03:52:43 2006 Subject: [linux-audio-dev] Re: fast linear resampling on ARM - suggestions? Message-ID: Erik de Castro Lopo: >Kjetil S. Matheussen wrote: > >> Was this with the linear resampler lib libsamplerate? In case, you should >> know that its terrible slow. Last time I tried, the fastest sinc resampler >> in CLM was almost as fast as the linear resampler in libsamplerate. >> (Erik, you should do something about that...) > >Maybe I haven't made myself clear. IMHO linear resampling sucks >for audio. It is included in libsamplerate purely so I can >show how bad it actually is. Yeah, I remember you wrote something like that once. But you should write it into the documentation as well, and include a note that it is not implemented efficiently. Actually, the best is probably if you just remove the linear resampler all together if you are not willing to implement it properly. It is very irritating spending lots of time figuring out why things are so slow. Don't get me wrong, I appreciate your work very much, but this particular issue is irritating. There are situations where linear resampling is useful, for example when resampling xx sounds at once. From jussi.laako at pp.inet.fi Thu Mar 30 04:12:23 2006 From: jussi.laako at pp.inet.fi (Jussi Laako) Date: Thu Mar 30 04:12:35 2006 Subject: [linux-audio-dev] linear resampling is crap ? In-Reply-To: <20060330115126.GA31683@space.twc.de> References: <1448f040603290541p1877e76bscb8b3773505031e7@mail.gmail.com> <20060329234730.733e22b9.mle+la@mega-nerd.com> <20060329200522.GB8430@mobilat> <20060330163443.0a6ab1e4.mle+la@mega-nerd.com> <20060330115126.GA31683@space.twc.de> Message-ID: <442BA0F7.8090301@pp.inet.fi> Stefan Westerfeld wrote: > process, it should be possible to be quite fast (well, of course it > depends on what fast is) while maintaining good quality. From my recent > work on SSE based resampling code for BEAST: At least you can make SSE process four float streams in parallel without significant limitations to the algorithm itself. Getting all the benefits of SIMD with single stream would probably mean limitations or significant modifications to the algorithm. Typically filter codes are something where compilers fail to generate fast code and where hand written asm usually helps. Complex math is another thing. I've seen this with FIR and especially IIR filters. - Jussi From S.W.Harris at ecs.soton.ac.uk Thu Mar 30 04:31:29 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Thu Mar 30 04:31:46 2006 Subject: [linux-audio-dev] linear resampling is crap ? In-Reply-To: <442BA0F7.8090301@pp.inet.fi> References: <1448f040603290541p1877e76bscb8b3773505031e7@mail.gmail.com> <20060329234730.733e22b9.mle+la@mega-nerd.com> <20060329200522.GB8430@mobilat> <20060330163443.0a6ab1e4.mle+la@mega-nerd.com> <20060330115126.GA31683@space.twc.de> <442BA0F7.8090301@pp.inet.fi> Message-ID: <20060330093129.GE1304@login.ecs.soton.ac.uk> On Thu, Mar 30, 2006 at 12:12:23 +0300, Jussi Laako wrote: > Stefan Westerfeld wrote: > >process, it should be possible to be quite fast (well, of course it > >depends on what fast is) while maintaining good quality. From my recent > >work on SSE based resampling code for BEAST: > > At least you can make SSE process four float streams in parallel without > significant limitations to the algorithm itself. Getting all the > benefits of SIMD with single stream would probably mean limitations or > significant modifications to the algorithm. I'm not so sure, the cascading technique used by Faust[1] produces very efficient SIMD implementations for filters. However you wouldn't want to write that code by hand, you really need a compiler to do it. [1] ftp://ftp.grame.fr/pub/Documents/JIM2003vect.pdf - Steve From mle+la at mega-nerd.com Thu Mar 30 04:34:16 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Thu Mar 30 04:34:24 2006 Subject: [linux-audio-dev] Re: fast linear resampling on ARM - suggestions? In-Reply-To: References: Message-ID: <20060330193416.48d86d5a.mle+la@mega-nerd.com> Kjetil S. Matheussen wrote: > Don't get me wrong, I appreciate your work very much, but this > particular issue is irritating. There are situations where linear > resampling is useful, for example when resampling xx sounds at once. I'm rather busy, but I'll have a look at it. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ The Myth of Islamic Tolerance http://answering-islam.org.uk/Shamoun/badawi_tolerance.htm From mle+la at mega-nerd.com Thu Mar 30 04:48:02 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Thu Mar 30 04:48:09 2006 Subject: [linux-audio-dev] linear resampling is crap ? (was: fast linear resampling on ARM - suggestions?) In-Reply-To: <20060330115126.GA31683@space.twc.de> References: <1448f040603290541p1877e76bscb8b3773505031e7@mail.gmail.com> <20060329234730.733e22b9.mle+la@mega-nerd.com> <20060329200522.GB8430@mobilat> <20060330163443.0a6ab1e4.mle+la@mega-nerd.com> <20060330115126.GA31683@space.twc.de> Message-ID: <20060330194802.19ed910e.mle+la@mega-nerd.com> Stefan Westerfeld wrote: > Measuring the same example with libsamplerate with SRC_SINC_FASTEST > gives a throughput of 1233140 samples/second, which means that my code > is about 41 times faster. Are you comparing apples to apples here? What is the bandwidth of your resampler? >From the comments in the code it seems that your resampler is not an abritrary resampler like mine but an 2 times upsampler. Its not really a fair comparison to compare a general time varying resampler like mine to a 2 times upsampler. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ Pastafarianism : http://www.venganza.org/ The intelligent alternative to 'Intelligent Design'. From bil at ccrma.Stanford.EDU Thu Mar 30 06:23:05 2006 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Thu Mar 30 06:23:12 2006 Subject: [linux-audio-dev] Re:sampling speed In-Reply-To: <20060330085249.C1BCEDBE3CD@music.columbia.edu> References: <20060330085249.C1BCEDBE3CD@music.columbia.edu> Message-ID: <20060330111514.M74968@ccrma.Stanford.EDU> > Fast 'n dirty vs slow 'n clean is a common trade-off in a zillion > applications And some have fast'n clean. If my src is "dirty", send me an example. I wonder if this contest is misleading -- the default sinc width I use was originally aimed at CLM-users; perhaps Eric's uses a different default, so comparisons are of apples and oranges, so to speak. I agree with Kjetil that linear resampling can be useful -- I based "Leviathan" on that effect. Sometimes "clean" isn't the main criterion. From stefan at space.twc.de Thu Mar 30 11:16:16 2006 From: stefan at space.twc.de (Stefan Westerfeld) Date: Thu Mar 30 07:59:11 2006 Subject: [linux-audio-dev] linear resampling is crap ? (was: fast linear resampling on ARM - suggestions?) In-Reply-To: <20060330194802.19ed910e.mle+la@mega-nerd.com> References: <1448f040603290541p1877e76bscb8b3773505031e7@mail.gmail.com> <20060329234730.733e22b9.mle+la@mega-nerd.com> <20060329200522.GB8430@mobilat> <20060330163443.0a6ab1e4.mle+la@mega-nerd.com> <20060330115126.GA31683@space.twc.de> <20060330194802.19ed910e.mle+la@mega-nerd.com> Message-ID: <20060330161616.GA368@space.twc.de> Hi! On Thu, Mar 30, 2006 at 07:48:02PM +1000, Erik de Castro Lopo wrote: > Stefan Westerfeld wrote: > > > Measuring the same example with libsamplerate with SRC_SINC_FASTEST > > gives a throughput of 1233140 samples/second, which means that my code > > is about 41 times faster. > > Are you comparing apples to apples here? No, I am not. I just wanted to say that if you can constrain your resampler and need not to be as generic as libsamplerate, then you can be a lot faster. > What is the bandwidth of your resampler? I think its hard to compare my filter directly to one of your quality settings (or bandwidth). The reason is that I am using a halfband filter, which means that the filter is at -6dB at the nyquist frequency, so it produces some aliasing for very high frequencies, which I assumed to be not or barely audible. But here are a few numbers, which are - if I understood your comments in the source right - normalized to your normalization (0..2): -3dB attenuation at 0.975 -96dB attenuation at 1.184 And here is a frequency plot of the filter made with gnuplot: http://space.twc.de/~stefan/kde/download/us32_resample_filter.png > From the comments in the code it seems that your resampler is not an > abritrary resampler like mine but an 2 times upsampler. Its not really > a fair comparison to compare a general time varying resampler like > mine to a 2 times upsampler. Yes. And the results don't mean that libsamplerate performs bad for what it does. They just mean that if you don't need a general time varying resampler, you can produce a more efficient implementation. Cu... Stefan -- Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan From hans at fugal.net Thu Mar 30 08:52:50 2006 From: hans at fugal.net (Hans Fugal) Date: Thu Mar 30 08:52:59 2006 Subject: [linux-audio-dev] regarding the 2nd Book Of Linux Music & Sound In-Reply-To: <8d27a0610603291008o26eeb4c8kf68a84606abcb194@mail.gmail.com> References: <442A6DAB.1010004@woh.rr.com> <8d27a0610603291008o26eeb4c8kf68a84606abcb194@mail.gmail.com> Message-ID: <20060330135250.GB7152@falcon.fugal.net> On Wed, 29 Mar 2006 at 13:08 -0500, Paul Coccoli wrote: > The type of info that would be in a second edition, in addition to the > tutorial-style stuff mentioned in another post, would be a great > reference for everyone if it were on-line and maintained by capable > writers (like Dave). However, the current scattered and incomplete > tutorials, Howtos, manuals, and wikis make me think that such a > resource will never exist. I'm not blaming anyone for that, since I > never contribute to those efforts either. Need it always be so? Or can we get a little organized and greatly improve the situation? My own opinion is that the community can do this with a little organization and motivation. Someone well-repsected and experienced in documenting (e.g. Dave) could head the organization, and the publishing carrot would provide just enough motivation for many people. Without the publishing carrot I think we would still benefit from a little organization. Dave, I have always enjoyed reading your articles and posts and of course the linux-audio site. I don't have the old book, simply because it was already too old when I came onto the scene. If you had the time and energy to continue to be a one-man show I would be delighted. But assuming you don't, as you have stated, let's consider organizing the community into documentation cells. One or two people could be in charge of a reasonably-sized topic with a lightweight organizational structure (just big enough). I have a friend who has done just this for the Asterisk community, and in the end it ended up an O'Reilly book, so if we need any advice we can ask them. asteriskdocs.org -- Hans Fugal ; http://hans.fugal.net There's nothing remarkable about it. All one has to do is hit the right keys at the right time and the instrument plays itself. -- Johann Sebastian Bach -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060330/b8dcc7fe/attachment.bin From rlrevell at joe-job.com Thu Mar 30 13:24:33 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Thu Mar 30 13:24:48 2006 Subject: [linux-audio-dev] regarding the 2nd Book Of Linux Music & Sound In-Reply-To: <20060330135250.GB7152@falcon.fugal.net> References: <442A6DAB.1010004@woh.rr.com> <8d27a0610603291008o26eeb4c8kf68a84606abcb194@mail.gmail.com> <20060330135250.GB7152@falcon.fugal.net> Message-ID: <1143743074.15145.26.camel@mindpipe> On Thu, 2006-03-30 at 06:52 -0700, Hans Fugal wrote: > > Need it always be so? Or can we get a little organized and greatly > improve the situation? My own opinion is that the community can do this > with a little organization and motivation. Someone well-repsected and > experienced in documenting (e.g. Dave) could head the organization, and > the publishing carrot would provide just enough motivation for many > people. Without the publishing carrot I think we would still benefit > from a little organization. Before anyone starts writing new documentation, what is most desperately needed is for someone to remove all the bad documentation out there (for example most of the ALSA wiki dealing with .asoundrc files and dmix) Lee From lazzaro at eecs.berkeley.edu Thu Mar 30 14:30:25 2006 From: lazzaro at eecs.berkeley.edu (lazzaro) Date: Thu Mar 30 14:30:32 2006 Subject: [linux-audio-dev] Re: fast linear resampling on ARM - suggestions? In-Reply-To: <20060330085249.C1BCEDBE3CD@music.columbia.edu> References: <20060330085249.C1BCEDBE3CD@music.columbia.edu> Message-ID: <4C811AF5-F05E-4370-B9AB-DD220E2F7A38@eecs.berkeley.edu> On Mar 30, 2006, at 12:52 AM, linux-audio-dev- request@music.columbia.edu wrote: > Maybe I haven't made myself clear. IMHO linear resampling sucks > for audio. It is included in libsamplerate purely so I can > show how bad it actually is. "Vintage" gear from the first few decades of digital audio were largely implemented using linear resampling. As a result, the linear aliasing characteristics have become an "effect" that artists are actively looking for in some situations. Ditto drop-sample resampling (Ensoniq Mirage). So I think it makes sense to make it as fast as it can be, and present it as an option. "Bitcrusher" plug-ins are popular for a reason :-). This paper (sadly not available online): D. Rossum, ``Constraint based audio interpolators,'' Proceedings of the IEEE Workshop on Applications of Signal Processing to Audio and Acoustics, New Paltz, NY, 1993. Shows why linear sampling can often sound "good enough" in practice. Basically, in linear resampling some of the high-energy aliases are masked by the signal. The paper shows how this property isn't present for some of the resamplers that are higher-order than linear but lower-order than sync interpolators. So, if you can't afford to do a sync interpolator, you have to be careful what alternative you choose, or else you may end up with something that sounds worse than linear! --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- From torbenh at gmx.de Thu Mar 30 15:30:24 2006 From: torbenh at gmx.de (torbenh@gmx.de) Date: Thu Mar 30 15:34:41 2006 Subject: [linux-audio-dev] linear resampling is crap ? (was: fast linear resampling on ARM - suggestions?) In-Reply-To: <20060330163443.0a6ab1e4.mle+la@mega-nerd.com> References: <1448f040603290541p1877e76bscb8b3773505031e7@mail.gmail.com> <20060329234730.733e22b9.mle+la@mega-nerd.com> <20060329200522.GB8430@mobilat> <20060330163443.0a6ab1e4.mle+la@mega-nerd.com> Message-ID: <20060330203024.GA8210@mobilat> On Thu, Mar 30, 2006 at 04:34:43PM +1000, Erik de Castro Lopo wrote: > torbenh@gmx.de wrote: > > > On Wed, Mar 29, 2006 at 11:47:30PM +1000, Erik de Castro Lopo wrote: > > > Tobias Scharnberg wrote: > > > > > > However, please do not use linear resampling; its just too crappy. > > > > urgh... i just switched my local copies of alsa_in and _out to linear > > resampling, because SRC_SINC_FASTEST was eating CPU juice. > > Just out of curiosity, what kind of hardware are you running this > on and what sort of performance would you find acceptable for your > application. An estimate that provides: ok... the program is a jack application, that opens an alsa pcm device (obviously not the one, jackd is bound to) and either outputs or inputs the sound. > > - input and output sample rates input is usually 48000 or 44100 (the jackd samplerate) outputrate depends on the soundcard used. 48k or 44k1 +- 10 Hz varying with clock drift... and calculation of resampling factor in float. i will improve the detection algorithm soon again. so that the samplerate is changing slower... > - samples per second per channel throughput wrt the output rate realtime. when the jack source clock is not very bursty (ie LAN or local) 2 channels take 7% cpu on an athlon xp 2000 with a bursty clock source from the internet the cpu usage in top is much higher. like 20% or so. a little too much for a soundcard IO :) > > would give me the best idea of what you are after. i hope you get what i am after now. i am heavily exercising libsrc... > > Erik > -- > +-----------------------------------------------------------+ > Erik de Castro Lopo > +-----------------------------------------------------------+ > Question #2459: Ruling on shaking hands with the opposite sex > http://islamqa.com/index.php?ln=eng&ds=qa&lv=browse&QR=2459&dgn=4 > -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From torbenh at gmx.de Thu Mar 30 15:33:58 2006 From: torbenh at gmx.de (torbenh@gmx.de) Date: Thu Mar 30 15:38:17 2006 Subject: [linux-audio-dev] linear resampling is crap ? (was: fast linear resampling on ARM - suggestions?) In-Reply-To: <20060330194802.19ed910e.mle+la@mega-nerd.com> References: <1448f040603290541p1877e76bscb8b3773505031e7@mail.gmail.com> <20060329234730.733e22b9.mle+la@mega-nerd.com> <20060329200522.GB8430@mobilat> <20060330163443.0a6ab1e4.mle+la@mega-nerd.com> <20060330115126.GA31683@space.twc.de> <20060330194802.19ed910e.mle+la@mega-nerd.com> Message-ID: <20060330203358.GB8210@mobilat> On Thu, Mar 30, 2006 at 07:48:02PM +1000, Erik de Castro Lopo wrote: > Stefan Westerfeld wrote: > > > Measuring the same example with libsamplerate with SRC_SINC_FASTEST > > gives a throughput of 1233140 samples/second, which means that my code > > is about 41 times faster. > > Are you comparing apples to apples here? > > What is the bandwidth of your resampler? > > >From the comments in the code it seems that your resampler is not an > abritrary resampler like mine but an 2 times upsampler. Its not really > a fair comparison to compare a general time varying resampler like > mine to a 2 times upsampler. i cant use a 2 times upsampler.... i want to use an unsynced soundcard with clockdrift as a recording source. and i really dont want to make any quality compromises. i need all features of libsrc (slowly changing samplerate, and resample factors of 1.00001 or so) > > Erik > -- > +-----------------------------------------------------------+ > Erik de Castro Lopo > +-----------------------------------------------------------+ > Pastafarianism : http://www.venganza.org/ > The intelligent alternative to 'Intelligent Design'. > -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From hans at fugal.net Thu Mar 30 18:46:25 2006 From: hans at fugal.net (Hans Fugal) Date: Thu Mar 30 18:46:42 2006 Subject: [linux-audio-dev] VST host for LADSPA plugins Message-ID: <20060330234625.GA13009@falcon.fugal.net> Has anyone written a VST host for LADSPA plugins? I see a lot of work in the other direction on Google. Would such a beast even be possible, considering licensing? -- Hans Fugal ; http://hans.fugal.net There's nothing remarkable about it. All one has to do is hit the right keys at the right time and the instrument plays itself. -- Johann Sebastian Bach -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060330/0cdc026b/attachment.bin From hans at fugal.net Thu Mar 30 18:48:06 2006 From: hans at fugal.net (Hans Fugal) Date: Thu Mar 30 18:48:15 2006 Subject: [linux-audio-dev] regarding the 2nd Book Of Linux Music & Sound In-Reply-To: <1143743074.15145.26.camel@mindpipe> References: <442A6DAB.1010004@woh.rr.com> <8d27a0610603291008o26eeb4c8kf68a84606abcb194@mail.gmail.com> <20060330135250.GB7152@falcon.fugal.net> <1143743074.15145.26.camel@mindpipe> Message-ID: <20060330234806.GB13009@falcon.fugal.net> On Thu, 30 Mar 2006 at 13:24 -0500, Lee Revell wrote: > On Thu, 2006-03-30 at 06:52 -0700, Hans Fugal wrote: > > > > Need it always be so? Or can we get a little organized and greatly > > improve the situation? My own opinion is that the community can do this > > with a little organization and motivation. Someone well-repsected and > > experienced in documenting (e.g. Dave) could head the organization, and > > the publishing carrot would provide just enough motivation for many > > people. Without the publishing carrot I think we would still benefit > > from a little organization. > > Before anyone starts writing new documentation, what is most desperately > needed is for someone to remove all the bad documentation out there (for > example most of the ALSA wiki dealing with .asoundrc files and dmix) Yes, absolutely. -- Hans Fugal ; http://hans.fugal.net There's nothing remarkable about it. All one has to do is hit the right keys at the right time and the instrument plays itself. -- Johann Sebastian Bach -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060330/46b43306/attachment.bin From ico.bukvic at gmail.com Thu Mar 30 19:36:34 2006 From: ico.bukvic at gmail.com (Ivica Ico Bukvic) Date: Thu Mar 30 19:37:06 2006 Subject: [linux-audio-dev] regarding the 2nd Book Of Linux Music & Sound In-Reply-To: <20060330234806.GB13009@falcon.fugal.net> Message-ID: <000301c6545b$2d35de60$03dbdf80@64BitBadass> > > > Need it always be so? Or can we get a little organized and greatly > > > improve the situation? My own opinion is that the community can do > this > > > with a little organization and motivation. Someone well-repsected and > > > experienced in documenting (e.g. Dave) could head the organization, > and > > > the publishing carrot would provide just enough motivation for many > > > people. Without the publishing carrot I think we would still benefit > > > from a little organization. > > > > Before anyone starts writing new documentation, what is most desperately > > needed is for someone to remove all the bad documentation out there (for > > example most of the ALSA wiki dealing with .asoundrc files and dmix) > > Yes, absolutely. Seems to me that what could solve both the issue of consolidation and of duplicate, mostly outdated documentation is generating a central website that provides one Wiki page for every pertinent topic, whether that be a specific software, system setup topic (i.e. ALSA), and/or distribution-specific how-to. The end-users and/or project devs/contributors could help generate the material, while Dave would assist in its shaping, so that it is translated into a well-structured learning resource and subsequently book-friendly format. Eventually, Dave could sum all this up into a book and everyone's happy ;-). If this proves to be something the LA community wishes to pursue, Linuxaudio.org could help foot the space. Just like the new home for LAD (lad.linuxaudio.org), we could have the aforementioned Wikis populated within the same domain (i.e. documentation.linuxaudio.org/pd, doc.linuxaudio.org/muse, doc.ardour.linuxaudio.org, or something along those lines), utilizing similar formatting, and therefore generating a kind of a reliable, uniform, and familiar interface for users, regardless of the topic they wish to pursue. FWIW, I am looking to do exactly this with one of my ongoing projects, simply because the scope of the project I am engaged in encourages feedback from as many artists as possible. Considering that anything associated with technology is an elusive target, books covering such topics are practically outdated as soon as they hit the shelves. Hence, the aforementioned approach IMHO may soon become the only reliable option if the author(s) wishes to generate content that is more time-resistant. This kind of an approach could also help speed-up publishing of subsequent editions--Dave could simply recompile project summaries from the aforementioned Wikis once per year and, publisher willing, release a new edition of the book for those who prefer to have documentation in a paper form (i.e. for teaching and/or reference purposes). Best wishes, Ico From rlrevell at joe-job.com Thu Mar 30 21:52:24 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Thu Mar 30 22:48:13 2006 Subject: [linux-audio-user] RE: [linux-audio-dev] regarding the 2nd Book Of Linux Music & Sound In-Reply-To: <000301c6545b$2d35de60$03dbdf80@64BitBadass> References: <000301c6545b$2d35de60$03dbdf80@64BitBadass> Message-ID: <1143773545.22771.21.camel@mindpipe> On Thu, 2006-03-30 at 19:36 -0500, Ivica Ico Bukvic wrote: > > > Before anyone starts writing new documentation, what is most desperately > > > needed is for someone to remove all the bad documentation out there (for > > > example most of the ALSA wiki dealing with .asoundrc files and dmix) > > > > Yes, absolutely. > > Seems to me that what could solve both the issue of consolidation and of > duplicate, mostly outdated documentation is generating a central website > that provides one Wiki page for every pertinent topic, whether that be a > specific software, system setup topic (i.e. ALSA), and/or > distribution-specific how-to. The end-users and/or project devs/contributors > could help generate the material IMHO wikis are what got us into this mess - there's nothing to stop users from posting wildly inaccurate information. So you end up with dozens of users posting .asoundrcs that they don't understand, but happened to solve (or hide) some problem for them. Lee From ico.bukvic at gmail.com Fri Mar 31 03:17:18 2006 From: ico.bukvic at gmail.com (Ivica Ico Bukvic) Date: Fri Mar 31 03:17:29 2006 Subject: [linux-audio-user] RE: [linux-audio-dev] regarding the 2nd Book Of Linux Music & Sound In-Reply-To: <1143773545.22771.21.camel@mindpipe> Message-ID: <001101c6549b$88403090$1700000a@64BitBadass> > > Seems to me that what could solve both the issue of consolidation and of > > duplicate, mostly outdated documentation is generating a central website > > that provides one Wiki page for every pertinent topic, whether that be a > > specific software, system setup topic (i.e. ALSA), and/or > > distribution-specific how-to. The end-users and/or project > devs/contributors > > could help generate the material > > IMHO wikis are what got us into this mess - there's nothing to stop > users from posting wildly inaccurate information. So you end up with > dozens of users posting .asoundrcs that they don't understand, but > happened to solve (or hide) some problem for them. Well, unattended ones are prone to doing that. Having multiple unrelated instances further magnifies this issue. However, in the aforementioned proposal, I suggested that Dave (and perhaps others? i.e. devs) would help oversee and/or shape this *single* documentation resource in order to keep it current and accurate. Hence, IMHO I see this as an all-encompassing solution. Best wishes, Ico From elisa.zwei at googlemail.com Fri Mar 31 05:05:01 2006 From: elisa.zwei at googlemail.com (Tobias Scharnberg) Date: Fri Mar 31 05:05:06 2006 Subject: [linux-audio-dev] Re: fast linear resampling on ARM - suggestions? In-Reply-To: References: <20060329223434.E158BDAD186@music.columbia.edu> Message-ID: <1448f040603310205w385e2166ub515df0b71beb9f7@mail.gmail.com> So ok, I can't use floating point - guess I missed that information. Thanks for the heads up, Erik! > I don't know of any other libraries that does linear resampling, but its > not that difficult to make one manually. I'm sure there are example codes > floating around as well. I tried to understand the original resample (JOS) sourcecode which also has a linear resampling besides the filter resampling. But I am still not sure how I can use it to resample my 16bit mono sample-stream instead of reading data from a soundfile. More than strange enough it shifts the read data down by 8 bits before doing the resampling operation on it. When it is done, data is shifted up again by 8 bits to write it to a new file.. I cant understand why it does that and if I can use my 16bit stream without the bit shifts.. I also googled for linear resampling sample codes in c - but found none... maybe I searched with the wrong phrases. So, if somebody is willing to give me a hint on resample, I would be very happy! Greetings, Tobias From rncbc at rncbc.org Fri Mar 31 05:12:34 2006 From: rncbc at rncbc.org (Rui Nuno Capela) Date: Fri Mar 31 05:14:48 2006 Subject: [linux-audio-dev] Re: fast linear resampling on ARM - suggestions? In-Reply-To: <1448f040603310205w385e2166ub515df0b71beb9f7@mail.gmail.com> References: <20060329223434.E158BDAD186@music.columbia.edu> <1448f040603310205w385e2166ub515df0b71beb9f7@mail.gmail.com> Message-ID: <44366.195.245.190.94.1143799954.squirrel@www.rncbc.org> On Fri, March 31, 2006 11:05, Tobias Scharnberg wrote: > > I also googled for linear resampling sample codes in c - but found > none... maybe I searched with the wrong phrases. > > So, if somebody is willing to give me a hint on resample, I would be > very happy! > Retry with "audio linear interpolation" as your search string ;) Bye. -- rncbc aka Rui Nuno Capela rncbc@rncbc.org From dlphillips at woh.rr.com Fri Mar 31 07:39:55 2006 From: dlphillips at woh.rr.com (Dave Phillips) Date: Fri Mar 31 07:07:06 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] regarding the 2nd Book Of Linux Music & Sound Message-ID: <442D231B.2060206@woh.rr.com> Greetings: First, thank you to everyone who responded to my original query. I now have a much better idea how I want to do this project. I definitely want to involve members of this group. Some of you have offered to take on particular chapters, and that seems to me the best approach. I believe we can complete the work in record time by spreading the work around. I'll speak with my publisher about this plan. If he approves this approach we'll start work immediately. Some respondents wrote to me off-list and have offered to assist. I'll be in touch with you all after talking with Bill Pollock. If Bill gives us a green light I'll start organizing the distribution of work immediately. I'll communicate directly with you regarding style preferences, format requirements, deadlines, etc. I must emphasize that this project is commercial work, i.e., we'll have editors at the publishing house and there will be demands that certain dates be met. Please, only take on the work if you're sure you can work under those conditions. If the community approach is accepted I'll post a list of topics and areas that need attention. I have a large amount of unedited/incomplete material that I'm willing to offer as starting points. I've been thinking about the royalties issue. I'm far from a final plan, but I think it might be possible to route some (all?) of the royalties to the Linux Audio Consortium. The community can then decide how to use it. I can't leave this issue vague, my publisher will need to know who is in charge of accounts receivable, and I can't simply accept contributions from the community and not reimburse those contributors. How that reimbursement takes place can be left to the individual contributors, or we may decide to simply throw everything in one direction (e.g. linuxaudio.org). Btw, I especially appreciate the community's response re: the 2.4 kernel series. It is laid to rest, there will be coverage only from kernel 2.6 upwards. Thank goodness. No Starch has already accepted my outline for the project. At some point I'll post that outline on the Web for the community to consider. However, please bear in mind that there will be limitations of space and scope. I'm unlikely to be able to cover games, consumer devices, or telephony. Alas, material for a programmer's guide will probably not be accepted. IMO that really requires a separate book now. A developer's guide to ALSA and JACK is certainly timely and needed, but I'm not the one to write that book. Again, if you're interested in writing for this project please contact me off-list. Specify your area of interest and we'll go from there. Best regards, dp From hans at fugal.net Fri Mar 31 09:48:54 2006 From: hans at fugal.net (Hans Fugal) Date: Fri Mar 31 09:49:07 2006 Subject: [linux-audio-user] RE: [linux-audio-dev] regarding the 2nd Book Of Linux Music & Sound In-Reply-To: <1143773545.22771.21.camel@mindpipe> References: <000301c6545b$2d35de60$03dbdf80@64BitBadass> <1143773545.22771.21.camel@mindpipe> Message-ID: <20060331144854.GA26738@falcon.fugal.net> On Thu, 30 Mar 2006 at 21:52 -0500, Lee Revell wrote: > On Thu, 2006-03-30 at 19:36 -0500, Ivica Ico Bukvic wrote: > > > > Before anyone starts writing new documentation, what is most desperately > > > > needed is for someone to remove all the bad documentation out there (for > > > > example most of the ALSA wiki dealing with .asoundrc files and dmix) > > > > > > Yes, absolutely. > > > > Seems to me that what could solve both the issue of consolidation and of > > duplicate, mostly outdated documentation is generating a central website > > that provides one Wiki page for every pertinent topic, whether that be a > > specific software, system setup topic (i.e. ALSA), and/or > > distribution-specific how-to. The end-users and/or project devs/contributors > > could help generate the material > > IMHO wikis are what got us into this mess - there's nothing to stop > users from posting wildly inaccurate information. So you end up with > dozens of users posting .asoundrcs that they don't understand, but > happened to solve (or hide) some problem for them. I don't think Lee is the only one with concerns about Wikis, and because there are other solutions that would work just as well I recommend we just steer towards them from the get-go. I think Hieraki may be a good choice. It gets its name from wiki+hierarchy (and access control). As their demo is not really working, here's an example hieraki-powered site: http://docs.rubyrake.org/read/book/1 The hieraki website is http://www.hieraki.org/trac/ and a good overview with screenshots is at http://www2.truman.edu/~ah428/noc.html I probably don't have the bandwidth to sustain the site long-term, but if we want to try out hieraki before asking linuxaudio.org (or wherever) to install it, I could host a quick test setup of it. -- Hans Fugal ; http://hans.fugal.net There's nothing remarkable about it. All one has to do is hit the right keys at the right time and the instrument plays itself. -- Johann Sebastian Bach -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060331/f737996c/attachment.bin From libero.mureddu at gmail.com Fri Mar 31 11:50:23 2006 From: libero.mureddu at gmail.com (Libero Mureddu) Date: Fri Mar 31 11:50:55 2006 Subject: [linux-audio-dev] newbie problem compiling ladspaSDK on mac Message-ID: <5e3636ba0603310850h61035d52q3bc79969a99263e1@mail.gmail.com> Hi to everybody, I am new to this list. Many thanks to all the developers, It's already more than two years that I'm a happy user of free software for music on my ibook. But only recently I've decided that it's worth to learn woh to compile and install by myself the softwares that I use more often. I'm using a lot the LADSPA plugins packaged for os x, but I'm trying to compile the ladspa sdk. I've modified the makefile following the patch provided with fink, and the compilation seems to go well. However, at the end, I get the following error: ../bin/analyseplugin ../plugins/amp.so ../bin/analyseplugin ../plugins/noise.so time ../bin/applyplugin -s 1 \ ../snd/noise.wav /tmp/test.wav \ ../plugins/filter.so lpf 500 \ ../plugins/filter.so lpf 500 \ ../plugins/sine.so sine_fcaa 6000 \ ../plugins/delay.so delay_5s 1 0.1 \ ../plugins/amp.so amp_mono 4 \ Unable to find label "lpf" in plugin library file "../plugins/filter.so". 0.01 real 0.00 user 0.00 sys make: *** [/tmp/test.wav] Error 1 Can someone help me to solve this problem? I'm using mac os 10.4.4 on a g4 ibook. Regards, Libero Mureddu