From arnold.krille at gmail.com Sat Oct 1 08:54:58 2005 From: arnold.krille at gmail.com (Arnold Krille) Date: Sat Oct 1 08:55:04 2005 Subject: [linux-audio-dev] snd-usb-usx2y on amd64? Message-ID: <2def88b80510010554k7145035bx@mail.gmail.com> Hi all, sorry for cross-posting. I just wanted to know wether there are any known problems with the snd-usb-usx2y on amd64? 'Cause I got such a laptop now and experience some trouble with my tascam. :-( If I use it at non-realtime and high-realtime is works (at least for the first start of jackd) but realtime and/or low-latency just freezes the system. Maybe there is something I can do to increase the verbosity of the driver while crashing? The data of my machine: kernel is gentoo-2.6.13-r2 with the bundled alsa-1.0.9b, the usb-driver is ohci-hcd. The machine is a turion64 and I have acpi turned on... Thanks in advance, 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 jens.andreasen at chello.se Sun Oct 2 05:59:16 2005 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Sun Oct 2 05:59:22 2005 Subject: [linux-audio-dev] Parameter feedback in Rosegarden (and elsewhere) Message-ID: <1128247156.10832.27.camel@c80-216-125-193.cm-upc.chello.se> Hi! I have noticed that the midi-mixing-console in Rosegarden is not listening to external events (like knobs on your fancy midi-controller) I also recall that getting the Mx44 to display current parameters from selected patch without going into a loop (midi-update-> widget-update-> midi-update-> ...) was a challenge. Most probably I just tried to do it wrongly :) Should we perhaps do a (shortish) readme on how to get widgets to stay in sync with an associted midi-input-stream? mvh // Jens M Andreasen From mlang at delysid.org Sun Oct 2 08:01:50 2005 From: mlang at delysid.org (Mario Lang) Date: Sun Oct 2 08:01:55 2005 Subject: [linux-audio-dev] Sound file format detection? Message-ID: <87k6gwdt5d.fsf@lexx.delysid.org> Hi. My little time-compressing audio player yatm currently supports 3 different audio formats, ogg and speex via the xiph libraries, and mpeg via libmad. I currently just blindly try to launch the decoder for either ogg, speex or mp3 in series. SO if the first fails, I try the second, and so on. Which kinda works but is a bit ugly. I'd like to add flac support at some point, which would make this even more ugly. Additionally, libsndfile support wouldnt be that bad either, so, I am wondering, is there a reliable way to detect a audio streams file format just given some bits of the header? So that I could set the appropriate decoder algorithm based on that analysis? Or is there actually a library one step higher level than libsndfile which does generic audioformat to PCM? I guess not... -- CYa, Mario From ix at replic.net Sun Oct 2 09:22:09 2005 From: ix at replic.net (carmen) Date: Sun Oct 2 09:22:06 2005 Subject: [linux-audio-dev] Sound file format detection? In-Reply-To: <87k6gwdt5d.fsf@lexx.delysid.org> References: <87k6gwdt5d.fsf@lexx.delysid.org> Message-ID: <20051002132209.GA27271@replic.net> > I currently just blindly try to launch the decoder for either ogg, speex or > mp3 in series. I'd like to add flac... a simple way - how about assuming files are properly named, eg theres no files matching *.ogg which are actually .wav format? although in the major web browsers a .gif saved with .jpg extension always loads without error..maybe good to check how xmms or similar handles this situation.. > wondering, is there a reliable way to detect a audio streams file > format just given some bits of the header? So that I could set the InfoAudio ( ftp://ftp.tsp.ece.mcgill.ca//pub/AFsp/AFsp-v8r1.tar.gz ) is quite useful mainly for all the differing .wav bitrates/formats/endiannesses but maybe libsndfile already takes care of that.. for a mp3 it just says "AFfindType - Unsupported audio file type: MPEG-1 Layer III". and it doesnt even provide that much info for ogg or FLAC.. i still like it though it would be great if there was truly one solution to this, on Mac you just use coreaudio API, on windows, you use ACM codec, but it seems each linux app has to independently support and depend on flac/ogg/speex/wav/etc libs, ad nauseum.. c From fbar at footils.org Sun Oct 2 13:55:17 2005 From: fbar at footils.org (Frank Barknecht) Date: Sun Oct 2 13:59:24 2005 Subject: [linux-audio-dev] Sound file format detection? In-Reply-To: <87k6gwdt5d.fsf@lexx.delysid.org> References: <87k6gwdt5d.fsf@lexx.delysid.org> Message-ID: <20051002175517.GB8287@fliwatut.scifi> Hallo, Mario Lang hat gesagt: // Mario Lang wrote: > My little time-compressing audio player yatm currently supports 3 different > audio formats, ogg and speex via the xiph libraries, and mpeg via libmad. > I currently just blindly try to launch the decoder for either ogg, speex or > mp3 in series. SO if the first fails, I try the second, and so on. Which > kinda works but is a bit ugly. I'd like to add flac support at some point, > which would make this even more ugly. > Additionally, libsndfile support wouldnt be that bad either, so, I am > wondering, is there a reliable way to detect a audio streams file > format just given some bits of the header? The "file" command can specify a lot of file formats just from some magic bits, see /etc/magic, /usr/share/misc/file/magic and magic(5) for this. Additionally there are some more programs for getting at detailed info for soundfiles, like sndinfo included in Csound. Maybe you can rip some of their logic. Ciao -- Frank Barknecht _ ______footils.org_ __goto10.org__ From rncbc at rncbc.org Sun Oct 2 15:58:46 2005 From: rncbc at rncbc.org (Rui Nuno Capela) Date: Sun Oct 2 15:55:52 2005 Subject: [linux-audio-dev] [ANN] Qsynth 0.2.4 released! Message-ID: <43403BF6.6000800@rncbc.org> Hi all, Let me spread the word:) finally there comes this bug and some other usability fixes on today's latest Qsynth 0.2.4 release. As you might know already, Qsynth is a fluidsynth GUI front-end application, written in C++ around the Qt3 toolkit, using Qt Designer. Please check it out from: http://qsynth.sourceforge.net Upgrade is highly recommended as this one fixes a very annoying crash bug that has been lurking for ages. As simply pasted from the change-log: - All widget captions changed to include proper application title prefix. - Attempt to bring those aging autoconf templates to date; sample SPEC file for RPM build is now being included and generated at configure time. - Missing icons on channel and soundfont setup context menus are now up; bank/program splitter widget added to channel preset dialog. - An abrupt segfault on engine restart have been finally fixed; this issue has been quite an annoyance which has been around for ages and was a highly probable showstopper just when restarting an engine due to changes on the setup settings. Not anymore, hopefully. - New tool buttons were added to the main widget, for adding a new engine and removing the current one, while trying to increase the visibility of multiple fluidsynth engine capability (for new users, at least :) - Set to use QApplication::setMainWidget() instead of registering the traditional lastWindowClosed() signal to quit() /slot, just to let the -geometry command line argument have some optional effect on X11. - Minor configure and Makefile install fixes, as Debian and Mac OS X specialties. Also, install does the right thing with target file modes (thanks to Matt Flax and Ebrahim Mayat, for pointing these out). - Fixed output disability when messages limit option is turned off (thanks to Wolfgang Woehl for spotting this one, while on qjackctl). Hope you enjoy. -- rncbc aka Rui Nuno Capela rncbc@rncbc.org From tszilagyi at users.sourceforge.net Sun Oct 2 16:11:32 2005 From: tszilagyi at users.sourceforge.net (Tom Szilagyi) Date: Sun Oct 2 16:12:16 2005 Subject: [linux-audio-dev] Sound file format detection? In-Reply-To: <87k6gwdt5d.fsf@lexx.delysid.org> Message-ID: <20051002201132.GA17154@r51> On Sun, Oct 02, 2005 at 02:01:50PM +0200, Mario Lang wrote: > Hi. > > My little time-compressing audio player yatm currently supports 3 different > audio formats, ogg and speex via the xiph libraries, and mpeg via libmad. > I currently just blindly try to launch the decoder for either ogg, speex or > mp3 in series. SO if the first fails, I try the second, and so on. Which > kinda works but is a bit ugly. I'd like to add flac support at some point, > which would make this even more ugly. > Additionally, libsndfile support wouldnt be that bad either, so, I am > wondering, is there a reliable way to detect a audio streams file > format just given some bits of the header? So that I could set the > appropriate decoder algorithm based on that analysis? Or is > there actually a library one step higher level than libsndfile which > does generic audioformat to PCM? I guess not... Hi, you might want to take a look at Aqualung (aqualung.sf.net) which is a music player program supporting a reasonable range of formats. The input library (the part of the software that opens soundfiles, determines their format and decodes them to float PCM) is a component not too tightly integrated with the rest of the app. In fact, it is built separately as a lib and linked statically to the rest of the program. However, it supports only read-only access, and was not meant to be used out of the scope of its mother application, which means you won't be able to use it as an immediate drop-in solution. (It might be possible with some hacking, since interdependencies with the rest of the program are not conceptual and remain mostly because of my laziness and limited resources.) This module (called the "file decoder") works by probing individual format plugins on the file (well, not plugins in the usual sense, they are only modules with a predefined, simple api) that are responsible for correctly reporting whether they are able to deal with the file. This part of the software itself is fairly structured (at least I believe so), there are no excessive comments but the big picture should be clear for any programmer after a bit of investigation. If you decide to take a look, download the CVS sources of Aqualung and look in src/decoder/. Feel free to contact me if you have questions. Tom From chris.cannam at ferventsoftware.com Sun Oct 2 16:45:41 2005 From: chris.cannam at ferventsoftware.com (Chris Cannam) Date: Sun Oct 2 16:47:22 2005 Subject: [linux-audio-dev] Parameter feedback in Rosegarden (and elsewhere) Message-ID: <183368689-1128286033-cardhu_blackberry.rim.net-29119-@engine12.bwc.produk.on.blackberry> Jens: > I have noticed that the midi-mixing-console in Rosegarden is not > listening to external events (like knobs on your fancy midi-controller) It does in the current CVS version, and that in Studio to Go! 1.50. You have to connect your controller to the external controllers ALSA port, though. However, I wouldn't recommend the code for this to anyone - it's a brutal hack on a design not intended for this - so I can't add much to your initial point... Chris From jens.andreasen at chello.se Sun Oct 2 18:07:33 2005 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Sun Oct 2 18:07:47 2005 Subject: [linux-audio-dev] Parameter feedback in Rosegarden (and elsewhere) In-Reply-To: <183368689-1128286033-cardhu_blackberry.rim.net-29119-@engine12.bwc.produk.on.blackberry> References: <183368689-1128286033-cardhu_blackberry.rim.net-29119-@engine12.bwc.produk.on.blackberry> Message-ID: <1128290853.10832.44.camel@c80-216-125-193.cm-upc.chello.se> Chris! This sounds promising .) Now a days I have some of those "fancy knobs." Give me a call off the list so I can help out verify that the thingh works! mvh // Jens M Andreasen On Sun, 2005-10-02 at 20:45 +0000, Chris Cannam wrote: > Jens: > > I have noticed that the midi-mixing-console in Rosegarden is not > > listening to external events (like knobs on your fancy midi-controller) > > It does in the current CVS version, and that in Studio to Go! 1.50. You have to connect your controller to the external controllers ALSA port, though. > > However, I wouldn't recommend the code for this to anyone - it's a brutal hack on a design not intended for this - so I can't add much to your initial point... > > > Chris -- From mlang at delysid.org Mon Oct 3 04:22:34 2005 From: mlang at delysid.org (Mario Lang) Date: Mon Oct 3 04:22:41 2005 Subject: [linux-audio-dev] Sound file format detection? In-Reply-To: <20051002132209.GA27271@replic.net> (ix@replic.net's message of "Sun, 2 Oct 2005 13:22:09 +0000") References: <87k6gwdt5d.fsf@lexx.delysid.org> <20051002132209.GA27271@replic.net> Message-ID: <873bnjdn79.fsf@lexx.delysid.org> carmen writes: >> I currently just blindly try to launch the decoder for either ogg, speex or >> mp3 in series. I'd like to add flac... > > a simple way - how about assuming files are properly named, eg theres no > files matching *.ogg which are actually .wav format? Sorry, but this kind of behaviour is way too microsoftian for me. File extensions lie! :-) Besides, yatm should ideally be able to stream data at some point in the future, and streams can be named anything sometimes. > although in the major web browsers a .gif saved with .jpg extension > always loads without error..maybe good to check how xmms or similar > handles this situation.. Yes, I'll look into other audio players sources... >> wondering, is there a reliable way to detect a audio streams file >> format just given some bits of the header? So that I could set the > > InfoAudio ( ftp://ftp.tsp.ece.mcgill.ca//pub/AFsp/AFsp-v8r1.tar.gz ) is quite useful mainly for all the differing .wav bitrates/formats/endiannesses but maybe libsndfile already takes care of that.. for a mp3 it just says "AFfindType - Unsupported audio file type: MPEG-1 Layer III". and it doesnt even provide that much info for ogg or FLAC.. i still like it though > > it would be great if there was truly one solution to this, on Mac you just use coreaudio API, on windows, you use ACM codec, but it seems each linux app has to independently support and depend on flac/ogg/speex/wav/etc libs, ad nauseum.. Yes, a mega-libsndfile would be very cute. -- CYa, Mario From beachnase at web.de Mon Oct 3 04:51:57 2005 From: beachnase at web.de (Frank Neumann) Date: Mon Oct 3 04:50:06 2005 Subject: [linux-audio-dev] Sound file format detection? In-Reply-To: <20051002175517.GB8287@fliwatut.scifi> References: <87k6gwdt5d.fsf@lexx.delysid.org> <20051002175517.GB8287@fliwatut.scifi> Message-ID: Hi list, On Sun, 2 Oct 2005 19:55:17 +0200 Frank Barknecht wrote: [..] > > Additionally, libsndfile support wouldnt be that bad either, so, I am > > wondering, is there a reliable way to detect a audio streams file > > format just given some bits of the header? > > The "file" command can specify a lot of file formats just from some > magic bits, see /etc/magic, /usr/share/misc/file/magic and magic(5) > for this. Additionally, the "magic" command and its detection abilities are separated nowadays - at least on my Debian system with "file" version 4.03 you also get the packages "libmagic1" and "libmagic-dev" which allow to use "file" functionality in any C/C++ program. Try "man 3 libmagic". Greetings, Frank From pieterp at joow.be Mon Oct 3 08:10:06 2005 From: pieterp at joow.be (Pieter Palmers) Date: Mon Oct 3 08:09:58 2005 Subject: [linux-audio-dev] External audio interface (edirol FA/UA-101) In-Reply-To: <433D2428.1000207@monom.org> References: <433C3CFB.1050809@konstruktiv.org> <433D2428.1000207@monom.org> Message-ID: <43411F9E.6090206@joow.be> Daniel Wagner wrote: > Dmitry S. Baikov wrote: > >>> Yes, the FA-101 works but I can't tell you the numbers for latency. >> >> >> >> The site has a nice table of working setups, but no user emails. I'd >> ask them directly. >> > Pieter Palmers has done some latency measurements. He might have > some numbers for you. > http://freebob.sourceforge.net/index.php/Some_emails_about_latency To summarize: the minimum round-trip latency I achieve with our current code is about 8ms, but there are some bugs that pop up at these low buffer sizes. the minimal round-trip latency that gives rather reliable operation is about 14ms. note that I measure 'round-trip latency' by connecting a cable between output and input of the soundcard and then look at the time difference between the played sound and the recorded sound. I'm working on a better driver structure/code that will allow lower latencies. Greets, Pieter From mle+la at mega-nerd.com Mon Oct 3 09:15:38 2005 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Mon Oct 3 09:15:50 2005 Subject: [linux-audio-dev] Sound file format detection? In-Reply-To: <87k6gwdt5d.fsf@lexx.delysid.org> References: <87k6gwdt5d.fsf@lexx.delysid.org> Message-ID: <20051003231538.2c7ac39d.mle+la@mega-nerd.com> Mario Lang wrote: > Hi. > > My little time-compressing audio player yatm currently supports 3 different > audio formats, ogg and speex via the xiph libraries, and mpeg via libmad. > I currently just blindly try to launch the decoder for either ogg, speex or > mp3 in series. SO if the first fails, I try the second, and so on. Which > kinda works but is a bit ugly. I'd like to add flac support at some point, > which would make this even more ugly. > Additionally, libsndfile support wouldnt be that bad either, so, I am > wondering, is there a reliable way to detect a audio streams file > format just given some bits of the header? For the vast majority of file formats yes. > So that I could set the > appropriate decoder algorithm based on that analysis? Or is > there actually a library one step higher level than libsndfile which > does generic audioformat to PCM? Isn't that what libsndfile does? BTW, the latest release of libsndfile supports FLAC via the same API as all the other formats. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ Spammer: Any of you guys looking for a permanent position in Scotland? Kaz Kylheku: No, I'm looking for a thug in Scotland who might be interested in beating up off-topic Usenet spammers, on a pro bono basis. From mle+la at mega-nerd.com Mon Oct 3 09:19:10 2005 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Mon Oct 3 09:19:21 2005 Subject: [linux-audio-dev] Sound file format detection? In-Reply-To: <20051002132209.GA27271@replic.net> References: <87k6gwdt5d.fsf@lexx.delysid.org> <20051002132209.GA27271@replic.net> Message-ID: <20051003231910.4dac7be1.mle+la@mega-nerd.com> carmen wrote: > > I currently just blindly try to launch the decoder for either ogg, speex or > > mp3 in series. I'd like to add flac... > > a simple way - how about assuming files are properly named, eg theres no files > matching *.ogg which are actually .wav format? No, but Ogg is a container format and may contain audio data encoded as Vorbis, Speex or Flac. > it would be great if there was truly one solution to this, on Mac you just > use coreaudio API, on windows, you use ACM codec, but it seems each linux > app has to independently support and depend on flac/ogg/speex/wav/etc libs, > ad nauseum.. Yes, thats braindamaged. However, libsndfile now supports FLAC and work on Ogg Vorbis and Ogg Speex is underway. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ Linux, the UNIX defragmentation tool. From mlang at delysid.org Mon Oct 3 10:23:05 2005 From: mlang at delysid.org (Mario Lang) Date: Mon Oct 3 10:23:21 2005 Subject: [linux-audio-dev] Sound file format detection? In-Reply-To: <20051003231538.2c7ac39d.mle+la@mega-nerd.com> (Erik de Castro Lopo's message of "Mon, 3 Oct 2005 23:15:38 +1000") References: <87k6gwdt5d.fsf@lexx.delysid.org> <20051003231538.2c7ac39d.mle+la@mega-nerd.com> Message-ID: <87oe66d6ie.fsf@lexx.delysid.org> Erik de Castro Lopo writes: >> So that I could set the >> appropriate decoder algorithm based on that analysis? Or is >> there actually a library one step higher level than libsndfile which >> does generic audioformat to PCM? > > Isn't that what libsndfile does? Yes :-) > > BTW, the latest release of libsndfile supports FLAC via the same API > as all the other formats. GREAT!!! I was soooo waiting for this! So now I'll be able to read flac files in SuperCollider. Now, if libsndfile only would do vorbis and mp3 too, I could just use it as the backend for everything. -- CYa, Mario From mle+la at mega-nerd.com Mon Oct 3 15:25:33 2005 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Mon Oct 3 15:25:41 2005 Subject: [linux-audio-dev] Sound file format detection? In-Reply-To: <87oe66d6ie.fsf@lexx.delysid.org> References: <87k6gwdt5d.fsf@lexx.delysid.org> <20051003231538.2c7ac39d.mle+la@mega-nerd.com> <87oe66d6ie.fsf@lexx.delysid.org> Message-ID: <20051004052533.319d2f0f.mle+la@mega-nerd.com> Mario Lang wrote: > Erik de Castro Lopo writes: > > > BTW, the latest release of libsndfile supports FLAC via the same API > > as all the other formats. > > GREAT!!! I was soooo waiting for this! So now I'll be able to read > flac files in SuperCollider. > Now, if libsndfile only would do vorbis and mp3 too, I could just > use it as the backend for everything. Vorbis is coming. MP3 won't happen because of the legal issue surrounding MP3. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ Journalist: Microsoft CEO Steve Ballmer has finally said Linux is the No. 1 threat to Windows. What's your response to that? Linus : "Tag, you're it." I don't care. They've had a lot of enemies in their time. Let them fight one enemy that doesn't care for a change. From fons.adriaensen at skynet.be Mon Oct 3 18:12:16 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Mon Oct 3 18:07:47 2005 Subject: [linux-audio-dev] MVC - multiple CV Message-ID: <20051003221216.GC4954@linux-1> Hi all, working on the strict MVC-fication of Aeolus (a precondition for its OSC-fication), I'm again confronted with a problem that has been discussed a number of times on this list. It has been stated that the model should send updates to all clients except the one that originated a parameter change. While this will work if all communication is synchronous, it will go wrong easily when there are delays, e.g. over a network. Imagine an M and to CV clients, A and B. There are two transmission paths: A -> M -> B, and B- > M -> A. If the two ever intersect in time, the originator of the final value used by M will end up displaying the other one. So the only solution seems to echo parameter updates to all clients, including the one that requested them. In that way (and assuming messages remain in order), all clients will have the value used by M. If messages do not remain in order, the solution is to have a serial number set by M on each update and included in all messages. Finally, if the communication is unreliable as well, M should broadcast periodic updates of its state, or at least of those parts that have recently changed. Of course this may create some problems, e.g. when a GUI client's slider is being dragged, and it receives 'old' update values while this is happening. The solution seems to be simple: while dragging, ignore all updates but keep the most recent one. Execute this one when the slider is released. It may be a good idea to extend the 'ignore state' by a small time (e.g. 0.1 s) after release. Another approach would be have an originating client id in each message, and some mark to indicate the final request (upon release). Then, while dragging, ignore other clients, and always only act on marked messages from yourself. Anyone having any experience with this ? -- FA From paul at linuxaudiosystems.com Mon Oct 3 19:59:59 2005 From: paul at linuxaudiosystems.com (Paul Davis) Date: Mon Oct 3 19:58:37 2005 Subject: [linux-audio-dev] MVC - multiple CV In-Reply-To: <20051003221216.GC4954@linux-1> References: <20051003221216.GC4954@linux-1> Message-ID: <1128383999.26818.215.camel@dhin> > It has been stated that the model should send updates to > all clients except the one that originated a parameter change. never seen that stated. i consider that the CV never considers changes to have been carried out just because it asked. anything else is not really MVC. maybe the change requested by CV is not possible for M at this time. so the real signal flow is (with time on the vertical axis, increasing going down. request C(n)----------------> M . . . notification M ----------------> all V(n) > Another approach would be have an originating client id in > each message, and some mark to indicate the final request > (upon release). Then, while dragging, ignore other clients, > and always only act on marked messages from yourself. ardour uses this approach, but i have been phasing it out slowly in favor of the "pure" MVC model shown above. i use a generic void* "src" argument for changes, so that any object requesting a change passes "itself"; when changes occur, the "src" is passed along, and the object that initiated can ignore "its own" changes. but, as i said, i am trying to phase this out in favor of a model where there are no changes to the View until the Model sends a notification. this is not easy to do, especially not with most GUI toolkit control widgets like faders/sliders/knobs. for them, the approach i use is: void handle_model_state_change() { change_my_view_state_value (the_model_state->value); } void change_my_view_state_value (float newval) { if (my_view_state->value != newval) { my_view_state->value = newval; send_change_to_model (my_view_state->value); } } this causes one extra "cycle" in any state change, but ensures absolute agreement between V(C) and M. notice that C and (indirectly) M can both use change_my_view_state() to achieve their goals. --p From drobilla at connect.carleton.ca Mon Oct 3 20:29:12 2005 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Mon Oct 3 20:29:33 2005 Subject: [linux-audio-dev] MVC - multiple CV In-Reply-To: <20051003221216.GC4954@linux-1> References: <20051003221216.GC4954@linux-1> Message-ID: <1128385752.9047.4.camel@localhost.localdomain> On Tue, 2005-04-10 at 00:12 +0200, fons adriaensen wrote: > Hi all, > > working on the strict MVC-fication of Aeolus (a precondition > for its OSC-fication), I'm again confronted with a problem > that has been discussed a number of times on this list. > > It has been stated that the model should send updates to > all clients except the one that originated a parameter change. > While this will work if all communication is synchronous, > it will go wrong easily when there are delays, e.g. over > a network. > > Imagine an M and to CV clients, A and B. There are two > transmission paths: A -> M -> B, and B- > M -> A. If the > two ever intersect in time, the originator of the final > value used by M will end up displaying the other one. > > So the only solution seems to echo parameter updates to > all clients, including the one that requested them. In that > way (and assuming messages remain in order), all clients > will have the value used by M. If messages do not remain > in order, the solution is to have a serial number set by > M on each update and included in all messages. Finally, > if the communication is unreliable as well, M should > broadcast periodic updates of its state, or at least > of those parts that have recently changed. After much fiddling around with ugly schemes to not send replies to certain clients in Om, I just echoed back /everything/ to all registered clients, and left it up to the client to deal with it. The comm layer is much simpler and understandable because of it. > Of course this may create some problems, e.g. when a GUI > client's slider is being dragged, and it receives 'old' > update values while this is happening. The solution seems > to be simple: while dragging, ignore all updates but keep > the most recent one. Execute this one when the slider is > released. It may be a good idea to extend the 'ignore state' > by a small time (e.g. 0.1 s) after release. This is what I do in my gtk client. I need to do the small time delay thing still though, as there is a problem with dragging and releasing a slider very quickly (it jumps a bit afterwards). I'm not sure this is the best solution, but it's worked well enough so far. Generally when given the choice I'll choose complexity in the client over complexity in the engine any day. YMMV. It's not a very fun problem by any means.. I guess sending everything to everyone is less efficient in terms of network load, but it's simpler at least. -DR- From fons.adriaensen at alcatel.be Tue Oct 4 05:31:02 2005 From: fons.adriaensen at alcatel.be (Alfons Adriaensen) Date: Tue Oct 4 05:31:11 2005 Subject: [linux-audio-dev] MVC - multiple CV In-Reply-To: <1128383999.26818.215.camel@dhin> References: <20051003221216.GC4954@linux-1> <1128383999.26818.215.camel@dhin> Message-ID: <20051004093102.GB17529@bth05w.ABSp.alcatel.be> On Mon, Oct 03, 2005 at 07:59:59PM -0400, Paul Davis wrote: > i consider that the CV never considers changes > to have been carried out just because it asked. anything else is not > really MVC. maybe the change requested by CV is not possible for M at > this time. Good point. So this means that when M refuses a new value, it should respond by sending the current value at least to the originator of the request. In some cases (e.g. a slider) the C and V elements are the same (the slider's knob), which amounts to an implicit assumption by CV that its request will be accepted. So a slap on its hands by M is the only way to correct such hubris. > void handle_model_state_change() > { > change_my_view_state_value (the_model_state->value); > } > > void change_my_view_state_value (float newval) > { > if (my_view_state->value != newval) { > my_view_state->value = newval; > send_change_to_model (my_view_state->value); > } > } > > this causes one extra "cycle" in any state change, but ensures absolute > agreement between V(C) and M. notice that C and (indirectly) M can both > use change_my_view_state() to achieve their goals. Interesting. I'll have to go through some mental exercise to convince myself that this will never cause infinite cycles. Dave Robillard wrote: > After much fiddling around with ugly schemes to not send replies to > certain clients in Om, I just echoed back /everything/ to all registered > clients, and left it up to the client to deal with it. The comm layer > is much simpler and understandable because of it. > ... Generally when given the choice I'll choose complexity in the client > over complexity in the engine any day. Thanks to both of you for your response. So at least two experienced developers agree that updates should go to *all* clients, and that a client can be expected to handle this gracefully. Since that was my position from the start, I'll join the club :-) -- FA From dsb at eagle.ru Tue Oct 4 10:16:09 2005 From: dsb at eagle.ru (Dmitry Baikov) Date: Tue Oct 4 10:13:45 2005 Subject: [linux-audio-dev] External audio interface (edirol FA/UA-101) Message-ID: <43428EA9.3000301@eagle.ru> > http://freebob.sourceforge.net/index.php/Some_emails_about_latency > > the minimum round-trip latency I achieve with our current code is about > 8ms, but there are some bugs that pop up at these low buffer sizes. > the minimal round-trip latency that gives rather reliable operation is > about 14ms. Thank you for the link! Some real numbers, finally :) FW solution seems to be worth considering. > note that I measure 'round-trip latency' by connecting a cable between > output and input of the soundcard and then look at the time difference > between the played sound and the recorded sound. > That means 8-14ms is really excellent, as it takes into account DAC/ADC buffering. > I'm working on a better driver structure/code that will allow lower > latencies. Amazing! If I purchase FA-101 earlier, than you finish, I'll try to help. Dmitry. From ben at glw.com Tue Oct 4 14:41:42 2005 From: ben at glw.com (Ben Loftis) Date: Tue Oct 4 14:10:39 2005 Subject: [linux-audio-dev] Re: MVC - multiple CV In-Reply-To: <200510041604.j94G4Hss016567@roar.music.columbia.edu> References: <200510041604.j94G4Hss016567@roar.music.columbia.edu> Message-ID: <200510041341.42760.ben@glw.com> On Tuesday 04 October 2005 11:04 am, linux-audio-dev-request@music.columbia.edu wrote: > From: Alfons Adriaensen > > Interesting. I'll have to go through some mental exercise to convince > myself that this will never cause infinite cycles. The controllers should not send a change back to the M when they are told by the M what their value is. You'll also want some logic in the M that says "if I receive a change that tells me to go to my current value, then don't send updates to anyone". -Ben Loftis From fons.adriaensen at skynet.be Tue Oct 4 18:08:16 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Tue Oct 4 18:04:18 2005 Subject: [linux-audio-dev] Re: MVC - multiple CV In-Reply-To: <200510041341.42760.ben@glw.com> References: <200510041604.j94G4Hss016567@roar.music.columbia.edu> <200510041341.42760.ben@glw.com> Message-ID: <20051004220816.GA4955@linux-1> On Tue, Oct 04, 2005 at 01:41:42PM -0500, Ben Loftis wrote: > > Interesting. I'll have to go through some mental exercise to convince > > myself that this will never cause infinite cycles. > > The controllers should not send a change back to the M when they are told by > the M what their value is. The whole point about Paul's scheme is that he *is* doing exactly that. And while does seem odd, I will not dismiss the idea without giving it a full-length meditation :-) > You'll also want some logic in the M that says "if I receive a change that > tells me to go to my current value, then don't send updates to anyone". This should be a rare occurence, so I wonder if it's worth the extra code. What could be important when the client is a GUI is to limit the number of updates. Dragging a slider could result in *a lot of* X move events, and it's probably unwise to try and update the model and all clients for each one. -- FA From paul at linuxaudiosystems.com Tue Oct 4 18:52:27 2005 From: paul at linuxaudiosystems.com (Paul Davis) Date: Tue Oct 4 18:51:16 2005 Subject: [linux-audio-dev] Re: MVC - multiple CV In-Reply-To: <20051004220816.GA4955@linux-1> References: <200510041604.j94G4Hss016567@roar.music.columbia.edu> <200510041341.42760.ben@glw.com> <20051004220816.GA4955@linux-1> Message-ID: <1128466347.26818.234.camel@dhin> > > The controllers should not send a change back to the M when they are told by > > the M what their value is. > > The whole point about Paul's scheme is that he *is* doing exactly that. > And while does seem odd, I will not dismiss the idea without giving it > a full-length meditation :-) > > > You'll also want some logic in the M that says "if I receive a change that > > tells me to go to my current value, then don't send updates to anyone". > > This should be a rare occurence, so I wonder if it's worth the extra code. that was precisely what my code did, though :) From fons.adriaensen at skynet.be Tue Oct 4 19:39:35 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Tue Oct 4 19:35:33 2005 Subject: [linux-audio-dev] Re: MVC - multiple CV In-Reply-To: <1128466347.26818.234.camel@dhin> References: <200510041604.j94G4Hss016567@roar.music.columbia.edu> <200510041341.42760.ben@glw.com> <20051004220816.GA4955@linux-1> <1128466347.26818.234.camel@dhin> Message-ID: <20051004233935.GB4955@linux-1> On Tue, Oct 04, 2005 at 06:52:27PM -0400, Paul Davis wrote: > > > You'll also want some logic in the M that says "if I receive a change that > > > tells me to go to my current value, then don't send updates to anyone". > > > > This should be a rare occurence, so I wonder if it's worth the extra code. > > that was precisely what my code did, though :) >From your code > void change_my_view_state_value (float newval) > { > if (my_view_state->value != newval) { > my_view_state->value = newval; > send_change_to_model (my_view_state->value); > } > } you are doing this in V, while the suggestion I commented on was to do this in M. -- FA From fredg at salemradiolabs.com Wed Oct 5 08:39:08 2005 From: fredg at salemradiolabs.com (Fred Gleason) Date: Wed Oct 5 08:39:28 2005 Subject: [linux-audio-dev] Re: MVC - multiple CV In-Reply-To: <20051004220816.GA4955@linux-1> References: <200510041604.j94G4Hss016567@roar.music.columbia.edu> <200510041341.42760.ben@glw.com> <20051004220816.GA4955@linux-1> Message-ID: <200510050839.08262.fredg@salemradiolabs.com> On Tue, Oct 04, 2005 at 01:41:42PM -0500, Ben Loftis wrote: > > The controllers should not send a change back to the M when they are told > > by the M what their value is. On Tuesday 04 October 2005 18:08, fons adriaensen wrote: > The whole point about Paul's scheme is that he *is* doing exactly that. > And while does seem odd, I will not dismiss the idea without giving it > a full-length meditation :-) Some of this may depend upon what your toolkit expects. For example, in Qt, the QSlider widget has *two* signals that are emitted when a slider position changes. One ('valueChanged(int)') is emitted whenever the position changes, for whatever reason, while the other ('sliderMoved(int)') is emitted only when the change was due to the *user* moving the control --i.e. not when updated by the program itself. Choosing the correct one to use in a given context is important in order to avoid the kind of problems Fons has mentioned. Cheers! |-------------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Director of Broadcast Software Development | | | Salem Radio Labs | |-------------------------------------------------------------------------| | Every morning in Africa, a gazelle wakes up. It knows it must run | | faster than the fastest lion or it will be killed. Every morning a | | lion wakes up. It knows it must outrun the slowest gazelle or it will | | starve to death. It doesn't matter whether you are a lion or a | | gazelle: when the sun comes up, you'd better be running! | | -- Anonymous | |-------------------------------------------------------------------------| From derek at x-i.net Wed Oct 5 13:48:10 2005 From: derek at x-i.net (Derek Holzer) Date: Wed Oct 5 13:47:01 2005 Subject: [linux-audio-dev] linux audio apps on OSX: successes and failures Message-ID: <1128534490.434411da1be86@mail.x-i.net> Dear Developers, I've just spent the last couple days trying to get some of my favorite Linux audio apps running on OSX with various degrees of success or failure. I'm posting this report in the hopes that some of you could give me pointers on finishing the job, and possibly to start a dicussion of expanding some more support to OSX. Thanks for getting us this far and please read on! 1) System: * OSX Tiger 10.4 with all developers packages installed * Fink was used for most dependencies 2) Apps which I used DMG packages for with no real problems: * Ardour 0.9beta30 * JackOSX 0.71 * SooperLooper 1.0.7 * SuperCollider3 bin-20050916 * Pure Data 0.36test2-extended-RC0 3) Apps I compiled with different degrees of success: * Jack Audio Connection Kit 0.100.0 * Jack-Rack 1.4.4 * JackEQ 0.4.0 * QJackctl 0.2.18 * Jamin 0.95.0 * Rezound 0.12.2beta * Jack Timemachine 0.3.1 * MCP Plugins 0.3.0 * REV Plugins 0.3.1 * BLOP Plugins 0.2.8 * CAPS Plugins 0.2.3 * CMT Plugins 1.15 * SWH Plugins 0.4.14 * TAP Plugins 0.7.0 4) Results and Notes: * Jack Audio Connection Kit 0.100.0 Apparently successful. Starts from the command line without problem, and is installed in a different location than the JackOSX package so I don't beleive there to be a conflict. * Jack-Rack 1.4.4 Compiles without any real difficulty. However, when run it gives the following error for each plugin installed in /usr/local/lib/ladspa: plugin_mgr_get_object_file_plugins: error opening shared object file '/usr/lib/ladspa/zm1_1428.so': dlopen(/usr/lib/ladspa/zm1_1428.so, 10): Symbol not found: _libintl_dgettext Referenced from: /usr/local/lib/ladspa/zm1_1428.so Expected in: flat namespace After which I get a GTK message stating that Jack-Rack could not find any LADSPA plugins and I should check my path (which is correct, BTW). Ardour gives the same error, so I assume it has something to do with my SWH compile. * JackEQ 0.4.0 Compiles fine. Gives runtime error: Fontconfig warning: line 251: invalid edit binding "same" Fontconfig warning: line 263: invalid edit binding "same" Registering as jackEQ Bus error and exits. Probably to do with SWH plugins. * QJackctl 0.2.18 Compiles and runs fine. Only problem is with initializing the CoreAudio device. My CoreAudio device has the identifier "-n Apple03DBDMAAudio:i2s-a:0", however there is no way to get QJackctl to enter that string in the startup command. Seems it can't handle CoreAudio/OpenFirmware(?) ID strings (QJackctl identitifes my card as "128" in the select menu). If Jackd or JackOSX are already running, QJackctl recognizes them and I can use the Connections menu. MIDI support is not there, of course, due to lack of ALSA. * Jamin 0.95.0 Compiles and runs fine, after some work to get it to recognize the LADSPA_PATH. Exits with the same "Bus error" message on startup, possibly due to SWH Plugins problem. * Rezound 0.12.2beta I've heard people using this on OSX, and I've even seen a commercial package for OSX using it, but I'll be damned if I can get it to compile. Here's as far as I got: g++ -DHAVE_CONFIG_H -I. -I. -I../../../config -I../../../src/misc -I../../../src/misc/missing/generated -I../../../src/PoolFile -g -Wall -Wno-unused-function -Wno-unused-variable -Wno-unused -MT CNestedDataFile.lo -MD -MP -MF .deps/CNestedDataFile.Tpo -c CNestedDataFile.cpp -o CNestedDataFile.o CNestedDataFile.cpp:21:2: warning: #warning parseFile doesnt need to set the filename, only the constructor and setFilename should do that CNestedDataFile.cpp:22:2: warning: #warning see about retaining the order that things were parsed in the file In file included from ../../../config/common.h:72, from CNestedDataFile.h:24, from CNestedDataFile.cpp:36: ./../../config/platform/platform.h:10:3: warning: #warning no platform determined! In file included from CNestedDataFile.cpp:45: ./../../src/misc/CPath.h:302:5: error: #error CPath::which needs to be implemented on this platform make[3]: *** [CNestedDataFile.lo] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive] Error 1 [More spew available on request]. Also cannot get ./configure to recognize fftw.h and the other FFTW headers, no matter how many PATH combinations I try. * Jack Timemachine 0.3.1 Compiles and starts without problem. A half an hour ago I was getting the following: "Cannot open file for writing: Bad file descriptor", but just now when I tried again, apparently it wrote a proper w64 file. Who knew! ;-) * MCP Plugins 0.3.0 These lack a proper ./configure file, and I did not edit the Makefile at all. Compile ends with: g++ -shared mvclpf24.o mvclpf24_if.o exp2ap.o -o mvclpf24.so powerpc-apple-darwin8-g++-4.0.0: unrecognized option '-shared' /usr/bin/ld: Undefined symbols: _main collect2: ld returned 1 exit status make: *** [mvclpf24.so] Error 1 * REV Plugins 0.3.1 Same as MCP plugs. No ./configure and ends with: g++ -shared greverb.o g2reverb.o g2reverb_if.o exp2ap.o -o g2reverb.so powerpc-apple-darwin8-g++-4.0.0: unrecognized option '-shared' /usr/bin/ld: Undefined symbols: _main collect2: ld returned 1 exit status make: *** [g2reverb.so] Error 1 * BLOP Plugins 0.2.8 Compile ends with: gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/local/include -Iinclude -I. -DLOCALEDIR=\"/usr/local/share/locale\" -pipe -Wall -O3 -Wno-unused -DNO_DEBUG -DPIC -fPIC -ffast-math -fomit-frame-pointer -funroll-loops -nostartfiles -shared -lc -o adsr_1653.so adsr_1653.so.o powerpc-apple-darwin8-gcc-4.0.0: unrecognized option '-shared' /usr/bin/ld: Undefined symbols: _libintl_bindtextdomain _libintl_gettext _libintl_textdomain dyld_stub_binding_helper collect2: ld returned 1 exit status make[3]: *** [adsr_1653.so] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 This unrecognized option '-shared' is becoming a theme, isn't it? I also wonder if there is a problem with my Fink-installed gettext, as that is the error which the SWH plugins give when a client tries to use them. * CAPS Plugins 0.2.3 No ./configure at all, I had to symlink a malloc.h to a place where it could find it, and it all ends as such: g++ -O6 -ffast-math -funroll-loops -Wall -I/usr/local/include -c Amp.cc Amp.cc:169: error: explicit specialization of 'void Descriptor::setup()' must be introduced by 'template <>' Amp.cc:169: error: template-id 'setup<>' for 'void Descriptor::setup()' does not match any template declaration Amp.cc:169: error: invalid function declaration Amp.cc:303: error: explicit specialization of 'void Descriptor::setup()' must be introduced by 'template <>' Amp.cc:303: error: template-id 'setup<>' for 'void Descriptor::setup()' does not match any template declaration Amp.cc:303: error: invalid function declaration make: *** [Amp.o] Error 1 * CMT Plugins 1.15 No ./configure at all. Issuing a "make" in the src directory yields: g++ -I/usr/local/include/ -Wall -Werror -O3 -fPIC -c -o analogue.o analogue.cpp cc1plus: warnings being treated as errors analogue.cpp: In static member function 'static void Analogue::run(void*, long unsigned int)': analogue.cpp:259: warning: 'a' may be used uninitialized in this function analogue.cpp:259: warning: 'b' may be used uninitialized in this function analogue.cpp:259: warning: 'c' may be used uninitialized in this function make: *** [analogue.o] Error 1 * SWH Plugins 0.4.14 Compiled and installed to /usr/local/lib/ladspa without a hitch, but as you can see they have caused problems for all the LADSPA hosts so far with the following: plugin_mgr_get_object_file_plugins: error opening shared object file '/usr/lib/ladspa/zm1_1428.so': dlopen(/usr/lib/ladspa/zm1_1428.so, 10): Symbol not found: _libintl_dgettext Referenced from: /usr/local/lib/ladspa/zm1_1428.so Expected in: flat namespace or simply a quieter "Bus error". Too bad, it was looking good so far... Incidentally, I also used Taybin's swh-plugins and tap-plugins DMG files and they gave me the same results. So if these DMG packages are working for someone else, then I know it's something specific to my system here (gettext perhaps?) * TAP Plugins 0.7.0 No ./configure. Compile ends with: lsgcc -I. -O3 -Wall -fomit-frame-pointer -fstrength-reduce -funroll-loops -ffast-math -c -fPIC -DPIC tap_autopan.c -o tap_autopan.o gcc -nostartfiles -shared -Wl,-Bsymbolic -lc -lm -lrt -o tap_autopan.so tap_autopan.o powerpc-apple-darwin8-gcc-4.0.0: unrecognized option '-shared' /usr/bin/ld: unknown flag: -Bsymbolic collect2: ld returned 1 exit status make: *** [tap_autopan.so] Error 1 5) Conclusion While writing this report I tried Taybin's pair of LADSPA DMG packages, hoping for the best, but getting the same results. So I'm hoping I've provided enough info for some of you to point me in the right direction. I'd be happy to run a "gdb" on anything you all would like to hear more about, and I'd love to hear some feedback about how to get through all this. Particularly the Rezound and SWH problems, as those are the two biggest sticking points. thx + best wishes, derek http://umatic.nl From musound at jps.net Wed Oct 5 19:05:23 2005 From: musound at jps.net (Sean Bolton) Date: Wed Oct 5 19:04:13 2005 Subject: [linux-audio-dev] [ANN] WhySynth DSSI softsynth Message-ID: <5fde3b6f7456e5db1800b13c7d35671e@jps.net> Introducing WhySynth, a DSSI softsynth plugin. WhySynth, as in 'Y'-synth, the super-sized, frankensteinized, evolved and mutated, still rather dorky younger sibling of Xsynth-DSSI. WhySynth, as in (I sometimes ask), "_why_ am I working on another softsynth instead of on paying gigs?" (Following my bliss? Addiction? One last shot at misspent youth?) WhySynth, as in a mostly-new design featuring: - 4 oscillators per voice, in your choice of 6 modes (minBLEP, wavecycle, asynchronous granular, FM, waveshaper, and noise), - 2 filters, also in multiple flavors, - flexible routing and mixdown to stereo output, - 3 (or is it 6?) LFOs (instrument-wide, per-voice, and multiphase), - 5 multi-mode envelope generators, - abundant modulation options, - and effects (well, Tim Goetze's Versatile plate reverb is all at the moment, unless you count the DC-blocker anti-effect). WhySynth is a work in progress. Actually, since the kid was born, progress has slowed to a near-utter standstill, but if I can't release often, I might as well release early. Get your tarball, boring screenshot, and html-ized README today at: http://home.jps.net/~musound/whysynth.html then get your butts back to making cool music -- however you define that. Cheers, -Sean From tim at quitte.de Wed Oct 5 19:30:34 2005 From: tim at quitte.de (Tim Goetze) Date: Wed Oct 5 19:31:00 2005 Subject: [linux-audio-dev] linux audio apps on OSX: successes and failures In-Reply-To: <1128534490.434411da1be86@mail.x-i.net> References: <1128534490.434411da1be86@mail.x-i.net> Message-ID: [Derek Holzer] >* CAPS Plugins 0.2.3 >No ./configure at all, I had to symlink a malloc.h to a place where it could >find it [...] If you can tell me where malloc.h is on your system and how cpp can tell it's on OSX I can fix the latter. The former needs a patch, as I'm unwilling to even touch GNU autoconf. >, and it all ends as such: > >g++ -O6 -ffast-math -funroll-loops -Wall -I/usr/local/include -c Amp.cc >Amp.cc:169: error: explicit specialization of 'void Descriptor::setup()' >must be introduced by 'template <>' >Amp.cc:169: error: template-id 'setup<>' for 'void Descriptor::setup()' >does not match any template declaration >Amp.cc:169: error: invalid function declaration >Amp.cc:303: error: explicit specialization of 'void Descriptor::setup()' >must be introduced by 'template <>' >Amp.cc:303: error: template-id 'setup<>' for 'void Descriptor::setup()' >does not match any template declaration >Amp.cc:303: error: invalid function declaration >make: *** [Amp.o] Error 1 There is a patch available from the 'Installation' section of on the caps homepage that makes g++-4 digest the sources. I'm sorry for your inconvenience, but for the record I feel I have to add that this patch has been made available the very June day I released 0.2.3. Hope you'll find your way around; patches welcome. Cheers, Tim From nipo at ssji.net Thu Oct 6 02:13:20 2005 From: nipo at ssji.net (Nicolas Pouillon) Date: Thu Oct 6 02:13:42 2005 Subject: [linux-audio-dev] linux audio apps on OSX: successes and failures In-Reply-To: References: <1128534490.434411da1be86@mail.x-i.net> Message-ID: <4344C080.1060705@ssji.net> Tim Goetze wrote: > [Derek Holzer] > >>* CAPS Plugins 0.2.3 >>No ./configure at all, I had to symlink a malloc.h to a place where it could >>find it [...] > > > If you can tell me where malloc.h is on your system and how cpp can > tell it's on OSX I can fix the latter. The former needs a patch, as > I'm unwilling to even touch GNU autoconf. I think the fix is even easier: your sources should be corrected in order to include stdlib.h and not malloc.h, the latter is not stardard. Cheers -- Nipo http://nipo.ssji.net/nipo.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 186 bytes Desc: OpenPGP digital signature Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20051006/82243b2d/signature.bin From arnold.krille at gmail.com Thu Oct 6 03:59:04 2005 From: arnold.krille at gmail.com (Arnold Krille) Date: Thu Oct 6 03:59:09 2005 Subject: [linux-audio-dev] Re: snd-usb-usx2y on amd64? In-Reply-To: <2def88b80510010554k7145035bx@mail.gmail.com> References: <2def88b80510010554k7145035bx@mail.gmail.com> Message-ID: <2def88b80510060059h3a3349f3x@mail.gmail.com> Hi again, On 10/1/05, Arnold Krille wrote: > I just wanted to know wether there are any known problems with the > snd-usb-usx2y on amd64? > The data of my machine: kernel is gentoo-2.6.13-r2 with the bundled > alsa-1.0.9b, the usb-driver is ohci-hcd. The machine is a turion64 and > I have acpi turned on... Due to the great reaction I started a bit of investigating myself and installed the mm-2.6.14-rc1 from the gentoo-portage and this seems to run more stable. I was able to use my tascam with 16ms latency running qsampler/linuxsampler and ardour at the same time. qsampler/linuxsampler plus hydrogen seemed to run stable even at 8ms latency but that didn't last to long as I tried to start ardour, which crashed jack/qjackctl which in return crippled the sounddriver and freezes the machine on a new jack-start... I don't know if the reason for the "success" is to be searched in mm-sources or in the transition from 2.6.13 to 2.6.14 but I will investigate into that... 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 fons.adriaensen at alcatel.be Thu Oct 6 04:59:11 2005 From: fons.adriaensen at alcatel.be (Alfons Adriaensen) Date: Thu Oct 6 04:59:20 2005 Subject: [linux-audio-dev] linux audio apps on OSX: successes and failures In-Reply-To: <1128534490.434411da1be86@mail.x-i.net> References: <1128534490.434411da1be86@mail.x-i.net> Message-ID: <20051006085911.GA672@bth05w.ABSp.alcatel.be> On Wed, Oct 05, 2005 at 07:48:10PM +0200, Derek Holzer wrote: > * MCP Plugins 0.3.0 > These lack a proper ./configure file, and I did not edit the Makefile at all. > Compile ends with: > > g++ -shared mvclpf24.o mvclpf24_if.o exp2ap.o -o mvclpf24.so > powerpc-apple-darwin8-g++-4.0.0: unrecognized option '-shared' > > .... > > * REV Plugins 0.3.1 > Same as MCP plugs. If someone can tell me what the linker command line should be for OSX I'd be glad to add it to the Makefile. I'm not considering using the autotools for something as trivial as these plugins - I prefer to keep simple things simple. -- FA From letz at grame.fr Thu Oct 6 05:24:19 2005 From: letz at grame.fr (=?ISO-8859-1?Q?St=E9phane_Letz?=) Date: Thu Oct 6 05:25:07 2005 Subject: [linux-audio-dev] linux audio apps on OSX: successes and failures In-Reply-To: <1128534490.434411da1be86@mail.x-i.net> References: <1128534490.434411da1be86@mail.x-i.net> Message-ID: Le 5 oct. 05 ? 19:48, Derek Holzer a ?crit : > Dear Developers, > > I've just spent the last couple days trying to get some of my > favorite Linux > audio apps running on OSX with various degrees of success or > failure. I'm > posting this report in the hopes that some of you could give me > pointers on > finishing the job, and possibly to start a dicussion of expanding > some more > support to OSX. Thanks for getting us this far and please read on! > > 1) System: > > * OSX Tiger 10.4 with all developers packages installed > * Fink was used for most dependencies > > 2) Apps which I used DMG packages for with no real problems: > > * Ardour 0.9beta30 > * JackOSX 0.71 > * SooperLooper 1.0.7 > * SuperCollider3 bin-20050916 > * Pure Data 0.36test2-extended-RC0 > > 3) Apps I compiled with different degrees of success: > > * Jack Audio Connection Kit 0.100.0 > * Jack-Rack 1.4.4 > * JackEQ 0.4.0 > * QJackctl 0.2.18 > * Jamin 0.95.0 > * Rezound 0.12.2beta > * Jack Timemachine 0.3.1 > * MCP Plugins 0.3.0 > * REV Plugins 0.3.1 > * BLOP Plugins 0.2.8 > * CAPS Plugins 0.2.3 > * CMT Plugins 1.15 > * SWH Plugins 0.4.14 > * TAP Plugins 0.7.0 > > 4) Results and Notes: > > * Jack Audio Connection Kit 0.100.0 > Apparently successful. Starts from the command line without > problem, and is > installed in a different location than the JackOSX package so I > don't beleive > there to be a conflict. Hum... I think compiling Jack Audio Connection Kit 0.100.0 will install everything in /usr/local by default, the same place use by the JackOSX installer. Thus compiling/installing Jack Audio Connection Kit 0.100.0 will overwrite the JackOSX install, but this will not prevent JackOSX to work later. > > > * Jack-Rack 1.4.4 > Compiles without any real difficulty. However, when run it gives > the following > error for each plugin installed in /usr/local/lib/ladspa: > > plugin_mgr_get_object_file_plugins: error opening shared object file > '/usr/lib/ladspa/zm1_1428.so': dlopen(/usr/lib/ladspa/zm1_1428.so, > 10): Symbol > not found: _libintl_dgettext > Referenced from: /usr/local/lib/ladspa/zm1_1428.so > Expected in: flat namespace > > After which I get a GTK message stating that Jack-Rack could not > find any LADSPA > plugins and I should check my path (which is correct, BTW). Ardour > gives the > same error, so I assume it has something to do with my SWH compile. > > * JackEQ 0.4.0 > Compiles fine. Gives runtime error: > > Fontconfig warning: line 251: invalid edit binding "same" > Fontconfig warning: line 263: invalid edit binding "same" > Registering as jackEQ > Bus error > > and exits. Probably to do with SWH plugins. > > * QJackctl 0.2.18 > Compiles and runs fine. Only problem is with initializing the > CoreAudio device. > My CoreAudio device has the identifier "-n Apple03DBDMAAudio:i2s-a: > 0", however > there is no way to get QJackctl to enter that string in the startup > command. > Seems it can't handle CoreAudio/OpenFirmware(?) ID strings (QJackctl > identitifes my card as "128" in the select menu). If Jackd or > JackOSX are > already running, QJackctl recognizes them and I can use the > Connections menu. > MIDI support is not there, of course, due to lack of ALSA. The way to identify coraudio driver has been changed recently. It was a "user frendly" name, but was changed to an internal (more persistant) ID. I don't think QJackctl has been updated to handle this new way. > > * Jamin 0.95.0 > Compiles and runs fine, after some work to get it to recognize the > LADSPA_PATH. > Exits with the same "Bus error" message on startup, possibly due to > SWH Plugins > problem. > > * Rezound 0.12.2beta > I've heard people using this on OSX, and I've even seen a > commercial package for > OSX using it, but I'll be damned if I can get it to compile. Here's > as far as I > got: > > g++ -DHAVE_CONFIG_H -I. -I. -I../../../config -I../../../src/misc > -I../../../src/misc/missing/generated -I../../../src/PoolFile -g -Wall > -Wno-unused-function -Wno-unused-variable -Wno-unused -MT > CNestedDataFile.lo > -MD -MP -MF .deps/CNestedDataFile.Tpo -c CNestedDataFile.cpp -o > CNestedDataFile.o > CNestedDataFile.cpp:21:2: warning: #warning parseFile doesnt need > to set the > filename, only the constructor and setFilename should do that > CNestedDataFile.cpp:22:2: warning: #warning see about retaining the > order that > things were parsed in the file > In file included from ../../../config/common.h:72, > from CNestedDataFile.h:24, > from CNestedDataFile.cpp:36: > ./../../config/platform/platform.h:10:3: warning: #warning no platform > determined! > In file included from CNestedDataFile.cpp:45: > ./../../src/misc/CPath.h:302:5: error: #error CPath::which needs to be > implemented on this platform > make[3]: *** [CNestedDataFile.lo] Error 1 > make[2]: *** [all-recursive] Error 1 > make[1]: *** [all-recursive] Error 1 > make: *** [all-recursive] Error 1 > > [More spew available on request]. Also cannot get ./configure to > recognize > fftw.h and the other FFTW headers, no matter how many PATH > combinations I try. > > * Jack Timemachine 0.3.1 > Compiles and starts without problem. A half an hour ago I was > getting the > following: "Cannot open file for writing: Bad file descriptor", but > just now > when I tried again, apparently it wrote a proper w64 file. Who > knew! ;-) > > * MCP Plugins 0.3.0 > These lack a proper ./configure file, and I did not edit the > Makefile at all. > Compile ends with: > > g++ -shared mvclpf24.o mvclpf24_if.o exp2ap.o -o mvclpf24.so > powerpc-apple-darwin8-g++-4.0.0: unrecognized option '-shared' > /usr/bin/ld: Undefined symbols: > _main > collect2: ld returned 1 exit status > make: *** [mvclpf24.so] Error 1 > > * REV Plugins 0.3.1 > Same as MCP plugs. No ./configure and ends with: > > g++ -shared greverb.o g2reverb.o g2reverb_if.o exp2ap.o -o g2reverb.so > powerpc-apple-darwin8-g++-4.0.0: unrecognized option '-shared' > /usr/bin/ld: Undefined symbols: > _main > collect2: ld returned 1 exit status > make: *** [g2reverb.so] Error 1 > > * BLOP Plugins 0.2.8 > > Compile ends with: > > gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/local/include -Iinclude -I. > -DLOCALEDIR=\"/usr/local/share/locale\" -pipe -Wall -O3 -Wno-unused > -DNO_DEBUG -DPIC -fPIC -ffast-math -fomit-frame-pointer > -funroll-loops -nostartfiles -shared -lc -o adsr_1653.so > adsr_1653.so.o > powerpc-apple-darwin8-gcc-4.0.0: unrecognized option '-shared' > /usr/bin/ld: Undefined symbols: > _libintl_bindtextdomain > _libintl_gettext > _libintl_textdomain > dyld_stub_binding_helper > collect2: ld returned 1 exit status > make[3]: *** [adsr_1653.so] Error 1 > make[2]: *** [all-recursive] Error 1 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 > > This unrecognized option '-shared' is becoming a theme, isn't it? I > also wonder > if there is a problem with my Fink-installed gettext, as that is > the error > which the SWH plugins give when a client tries to use them. -shared must be replaced by -bundle on OSX > > * CAPS Plugins 0.2.3 > No ./configure at all, I had to symlink a malloc.h to a place where > it could > find it, and it all ends as such: > > g++ -O6 -ffast-math -funroll-loops -Wall -I/usr/local/include -c > Amp.cc > Amp.cc:169: error: explicit specialization of 'void > Descriptor::setup()' > must be introduced by 'template <>' > Amp.cc:169: error: template-id 'setup<>' for 'void > Descriptor::setup()' > does not match any template declaration > Amp.cc:169: error: invalid function declaration > Amp.cc:303: error: explicit specialization of 'void > Descriptor::setup()' > must be introduced by 'template <>' > Amp.cc:303: error: template-id 'setup<>' for 'void > Descriptor::setup()' > does not match any template declaration > Amp.cc:303: error: invalid function declaration > make: *** [Amp.o] Error 1 > > * CMT Plugins 1.15 > No ./configure at all. Issuing a "make" in the src directory yields: > g++ -I/usr/local/include/ -Wall -Werror -O3 -fPIC -c -o analogue.o > analogue.cpp > cc1plus: warnings being treated as errors > analogue.cpp: In static member function 'static void Analogue::run > (void*, long > unsigned int)': > analogue.cpp:259: warning: 'a' may be used uninitialized in this > function > analogue.cpp:259: warning: 'b' may be used uninitialized in this > function > analogue.cpp:259: warning: 'c' may be used uninitialized in this > function > make: *** [analogue.o] Error 1 > > * SWH Plugins 0.4.14 > Compiled and installed to /usr/local/lib/ladspa without a hitch, > but as you can > see they have caused problems for all the LADSPA hosts so far with the > following: > > plugin_mgr_get_object_file_plugins: error opening shared object file > '/usr/lib/ladspa/zm1_1428.so': dlopen(/usr/lib/ladspa/zm1_1428.so, > 10): Symbol > not found: _libintl_dgettext > Referenced from: /usr/local/lib/ladspa/zm1_1428.so > Expected in: flat namespace > > or simply a quieter "Bus error". Too bad, it was looking good so > far... > > Incidentally, I also used Taybin's swh-plugins and tap-plugins DMG > files and > they gave me the same results. So if these DMG packages are working > for someone > else, then I know it's something specific to my system here > (gettext perhaps?) > > * TAP Plugins 0.7.0 > No ./configure. Compile ends with: > lsgcc -I. -O3 -Wall -fomit-frame-pointer -fstrength-reduce -funroll- > loops > -ffast-math -c -fPIC -DPIC tap_autopan.c -o tap_autopan.o > gcc -nostartfiles -shared -Wl,-Bsymbolic -lc -lm -lrt -o > tap_autopan.so > tap_autopan.o > powerpc-apple-darwin8-gcc-4.0.0: unrecognized option '-shared' > /usr/bin/ld: unknown flag: -Bsymbolic > collect2: ld returned 1 exit status > make: *** [tap_autopan.so] Error 1 > > 5) Conclusion > > While writing this report I tried Taybin's pair of LADSPA DMG > packages, hoping > for the best, but getting the same results. So I'm hoping I've > provided enough > info for some of you to point me in the right direction. > > I'd be happy to run a "gdb" on anything you all would like to hear > more about, > and I'd love to hear some feedback about how to get through all this. > Particularly the Rezound and SWH problems, as those are the two > biggest > sticking points. > > thx + best wishes, > derek > > http://umatic.nl > Stephane From tim at quitte.de Thu Oct 6 05:38:47 2005 From: tim at quitte.de (Tim Goetze) Date: Thu Oct 6 05:38:49 2005 Subject: [linux-audio-dev] linux audio apps on OSX: successes and failures In-Reply-To: <4344C080.1060705@ssji.net> References: <1128534490.434411da1be86@mail.x-i.net> <4344C080.1060705@ssji.net> Message-ID: [Nicolas Pouillon] >I think the fix is even easier: your sources should be corrected in >order to include stdlib.h and not malloc.h, the latter is not stardard. Works well. Thank you! Cheers, Tim From nescivi at gmail.com Wed Oct 5 17:23:06 2005 From: nescivi at gmail.com (nescivi) Date: Thu Oct 6 08:33:46 2005 Subject: [linux-audio-dev] linux audio apps on OSX: successes and failures In-Reply-To: <1128534490.434411da1be86@mail.x-i.net> References: <1128534490.434411da1be86@mail.x-i.net> Message-ID: <1614713842.20051005232306@gmail.com> Hello Derek, Wednesday, October 5, 2005, 7:48:10 PM, you wrote: DH> * Rezound 0.12.2beta DH> [More spew available on request]. Also cannot get ./configure to recognize DH> fftw.h and the other FFTW headers, no matter how many PATH combinations I try. I had this same problem on Linux (though I did not try as much PATH combinations, but my fftw is in a standard location, so should be found), when compiling Rezound (which is a pity, 'cause I sometimes want to load more-than-8-channel wave files with it, which can only be done if I compile it myself after changing that constant*). sincerely, Marije * I must say that I found the error message when first trying to load a wave-file with more than 8 channels, most charming and very handy. Long live open source :) From annabellesgarden at yahoo.de Thu Oct 6 08:46:14 2005 From: annabellesgarden at yahoo.de (Karsten Wiese) Date: Thu Oct 6 08:40:33 2005 Subject: [linux-audio-dev] Re: snd-usb-usx2y on amd64? In-Reply-To: <2def88b80510060059h3a3349f3x@mail.gmail.com> References: <2def88b80510010554k7145035bx@mail.gmail.com> <2def88b80510060059h3a3349f3x@mail.gmail.com> Message-ID: <200510061446.14665.annabellesgarden@yahoo.de> Am Donnerstag, 6. Oktober 2005 09:59 schrieb Arnold Krille: > Hi again, > > On 10/1/05, Arnold Krille wrote: > > I just wanted to know wether there are any known problems with the > > snd-usb-usx2y on amd64? > > The data of my machine: kernel is gentoo-2.6.13-r2 with the bundled > > alsa-1.0.9b, the usb-driver is ohci-hcd. The machine is a turion64 and > > I have acpi turned on... > > Due to the great reaction I started a bit of investigating myself and :-) ^------------^ > installed the mm-2.6.14-rc1 from the gentoo-portage and this seems to > run more stable. > > I was able to use my tascam with 16ms latency running > qsampler/linuxsampler and ardour at the same time. > qsampler/linuxsampler plus hydrogen seemed to run stable even at 8ms > latency but that didn't last to long as I tried to start ardour, which > crashed jack/qjackctl which in return crippled the sounddriver and > freezes the machine on a new jack-start... A crash backtrace would be really helpfull... Does the machine have a serial port ? Then please log the crash with a serial console. Or use netconsole. See kernel/Documentation or google for how-tos. Gruesse, Karsten ___________________________________________________________ Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de From arnold.krille at gmail.com Thu Oct 6 08:49:32 2005 From: arnold.krille at gmail.com (Arnold Krille) Date: Thu Oct 6 08:49:35 2005 Subject: [linux-audio-dev] Re: snd-usb-usx2y on amd64? In-Reply-To: <200510061446.14665.annabellesgarden@yahoo.de> References: <2def88b80510010554k7145035bx@mail.gmail.com> <2def88b80510060059h3a3349f3x@mail.gmail.com> <200510061446.14665.annabellesgarden@yahoo.de> Message-ID: <2def88b80510060549yde3b427k@mail.gmail.com> On 10/6/05, Karsten Wiese wrote: > A crash backtrace would be really helpfull... > Does the machine have a serial port ? Then please log the crash with a > serial console. I said "it freezes", not "it crashes and gives me tons of logs to post here" :-( And the newer laptops (like mine) don't have a serial port anymore... > Or use netconsole. > See kernel/Documentation or google for how-tos. Hmm, maybe I can try this. Thanks, 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 fons.adriaensen at alcatel.be Thu Oct 6 09:32:22 2005 From: fons.adriaensen at alcatel.be (Alfons Adriaensen) Date: Thu Oct 6 09:32:43 2005 Subject: [linux-audio-dev] linux audio apps on OSX: successes and failures In-Reply-To: <1614713842.20051005232306@gmail.com> References: <1128534490.434411da1be86@mail.x-i.net> <1614713842.20051005232306@gmail.com> Message-ID: <20051006133222.GB672@bth05w.ABSp.alcatel.be> On Wed, Oct 05, 2005 at 11:23:06PM +0200, nescivi wrote: > DH> [More spew available on request]. Also cannot get ./configure to recognize > DH> fftw.h and the other FFTW headers, no matter how many PATH combinations I try. > > I had this same problem on Linux (though I did not try as much PATH > combinations, but my fftw is in a standard location, so should be > found), when compiling Rezound (which is a pity, 'cause I sometimes > want to load more-than-8-channel wave files with it, which can only be > done if I compile it myself after changing that constant*). This rings a bell. IIRC (on SL9.2) there was a pk for fftw, but not for the single precision version that most audio apps want (but it was installed). IIRC I just tweaked the existing pk a bit and thing worked. -- FA From jens.andreasen at chello.se Thu Oct 6 09:54:08 2005 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Thu Oct 6 09:54:19 2005 Subject: [linux-audio-dev] linux audio apps on OSX: successes and failures In-Reply-To: <20051006085911.GA672@bth05w.ABSp.alcatel.be> References: <1128534490.434411da1be86@mail.x-i.net> <20051006085911.GA672@bth05w.ABSp.alcatel.be> Message-ID: <1128606848.12010.23.camel@c80-216-125-193.cm-upc.chello.se> On Thu, 2005-10-06 at 10:59 +0200, Alfons Adriaensen wrote: > On Wed, Oct 05, 2005 at 07:48:10PM +0200, Derek Holzer wrote: > > > * MCP Plugins 0.3.0 > > These lack a proper ./configure file, and I did not edit the Makefile at all. > > Compile ends with: > > > > g++ -shared mvclpf24.o mvclpf24_if.o exp2ap.o -o mvclpf24.so > > If someone can tell me what the linker command line should be for OSX Not absolutely sure but perhaps, replace -shared with -dynamiclib At worst, it will just fail :) -- From jens.andreasen at chello.se Thu Oct 6 10:10:02 2005 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Thu Oct 6 10:10:08 2005 Subject: [linux-audio-dev] linux audio apps on OSX: successes and failures In-Reply-To: <1128606848.12010.23.camel@c80-216-125-193.cm-upc.chello.se> References: <1128534490.434411da1be86@mail.x-i.net> <20051006085911.GA672@bth05w.ABSp.alcatel.be> <1128606848.12010.23.camel@c80-216-125-193.cm-upc.chello.se> Message-ID: <1128607802.12010.26.camel@c80-216-125-193.cm-upc.chello.se> > Not absolutely sure but perhaps, replace -shared with -dynamiclib > Or have a peek here for variations on a theme: http://fink.sourceforge.net/doc/porting/shared.php?phpLang=en > At worst, it will just fail :) .. depending on what the intended purpose was. -- From annabellesgarden at yahoo.de Thu Oct 6 11:16:21 2005 From: annabellesgarden at yahoo.de (Karsten Wiese) Date: Thu Oct 6 11:10:42 2005 Subject: [linux-audio-dev] Re: snd-usb-usx2y on amd64? In-Reply-To: <2def88b80510060549yde3b427k@mail.gmail.com> References: <2def88b80510010554k7145035bx@mail.gmail.com> <200510061446.14665.annabellesgarden@yahoo.de> <2def88b80510060549yde3b427k@mail.gmail.com> Message-ID: <200510061716.22066.annabellesgarden@yahoo.de> Am Donnerstag, 6. Oktober 2005 14:49 schrieb Arnold Krille: > On 10/6/05, Karsten Wiese wrote: > > A crash backtrace would be really helpfull... > > Does the machine have a serial port ? Then please log the crash with a > > serial console. > > I said "it freezes", not "it crashes and gives me tons of logs to post here" :-( > > And the newer laptops (like mine) don't have a serial port anymore... > > > Or use netconsole. > > See kernel/Documentation or google for how-tos. > > Hmm, maybe I can try this. Thanks, If it'd be a freeze, you can start an RT console before your test with $ chrt -f 99 xterm& If its not a crash you maybe see something there. Or stop the hog. Karsten ___________________________________________________________ Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de From ml at xung.org Fri Oct 7 13:12:16 2005 From: ml at xung.org (Olivier Guilyardi) Date: Fri Oct 7 13:12:19 2005 Subject: [linux-audio-dev] New RSS feed for Linux Audio Announce Message-ID: <4346AC70.3000006@xung.org> Hi, I have set up an RSS feed for Linux Audio Announce : http://www.samalyse.com/rss/laa.rss It is updated every hour. For example, it is useful to display news and links about other Linux audio software on a webpage. That's what I currently do on Jackbeat's homepage : http://www.samalyse.com/jackbeat I mean : it can act as a sort of ring, a way to link to each other. If you are the author of an application, you can put LAA news and links on its homepage, if you like the idea. Enjoy -- og From b0ef at esben-stien.name Fri Oct 7 21:13:10 2005 From: b0ef at esben-stien.name (Esben Stien) Date: Fri Oct 7 19:16:08 2005 Subject: [linux-audio-dev] New RSS feed for Linux Audio Announce In-Reply-To: <4346AC70.3000006@xung.org> (Olivier Guilyardi's message of "Fri, 07 Oct 2005 19:12:16 +0200") References: <4346AC70.3000006@xung.org> Message-ID: <877jcosteh.fsf@quasar.esben-stien.name> Olivier Guilyardi writes: > I have set up an RSS feed for Linux Audio Announce ;) -- 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 conrad.berhoerster at gmx.de Sat Oct 8 08:10:57 2005 From: conrad.berhoerster at gmx.de (conrad =?iso-8859-1?q?berh=F6rster?=) Date: Sat Oct 8 08:14:06 2005 Subject: [linux-audio-dev] Command line patchbay for jack In-Reply-To: <4346AC70.3000006@xung.org> References: <4346AC70.3000006@xung.org> Message-ID: <200510081410.58560.conrad.berhoerster@gmx.de> Hello all, sorry for cross posting. at the jack application page there is a link to command line port connector for jack. http://sourceforge.net/mailarchive/message.php?msg_id=1171695 but unfortunately the link to the sources is dead. is there a way to connect jack applications without qjackctl. every hint is welcome. sizu c~ From derek at x-i.net Sat Oct 8 08:28:33 2005 From: derek at x-i.net (derek holzer) Date: Sat Oct 8 08:28:47 2005 Subject: [linux-audio-dev] Command line patchbay for jack In-Reply-To: <200510081410.58560.conrad.berhoerster@gmx.de> References: <4346AC70.3000006@xung.org> <200510081410.58560.conrad.berhoerster@gmx.de> Message-ID: <4347BB71.6090403@x-i.net> Is this what you're looking for? derek@macumbista ~ $ jack_connect --help usage: jack_connect The source port must be an output port of the source client. The destination port must be an input port of the destination client. d. conrad berh?rster wrote: > Hello all, > > sorry for cross posting. > > at the jack application page there is a link to command line port connector > for jack. > http://sourceforge.net/mailarchive/message.php?msg_id=1171695 > > but unfortunately the link to the sources is dead. > > is there a way to connect jack applications without qjackctl. > > every hint is welcome. > > sizu c~ > -- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 79: "Go slowly all the way round the outside" From larsl at users.sourceforge.net Sat Oct 8 08:34:43 2005 From: larsl at users.sourceforge.net (Lars Luthman) Date: Sat Oct 8 08:34:02 2005 Subject: [linux-audio-dev] Command line patchbay for jack In-Reply-To: <200510081410.58560.conrad.berhoerster@gmx.de> References: <4346AC70.3000006@xung.org> <200510081410.58560.conrad.berhoerster@gmx.de> Message-ID: <1128774883.9544.1.camel@c213-100-50-8.swipnet.se> On Sat, 2005-10-08 at 14:10 +0200, conrad berh?rster wrote: > is there a way to connect jack applications without qjackctl. jack_lsp to list available ports and jack_connect to connect them. They should come with the JACK package (or maybe in a package called jackit-example-clients). -- Lars Luthman PGP key: http://www.d.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- 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/20051008/f64ec118/attachment.bin From b0ef at esben-stien.name Sat Oct 8 10:48:46 2005 From: b0ef at esben-stien.name (Esben Stien) Date: Sat Oct 8 08:51:34 2005 Subject: [linux-audio-dev] Command line patchbay for jack In-Reply-To: <200510081410.58560.conrad.berhoerster@gmx.de> (conrad =?utf-8?q?berh=C3=B6rster's?= message of "Sat, 8 Oct 2005 14:10:57 +0200") References: <4346AC70.3000006@xung.org> <200510081410.58560.conrad.berhoerster@gmx.de> Message-ID: <87ll14m5dd.fsf@quasar.esben-stien.name> conrad berh?rster writes: > is there a way to connect jack applications without qjackctl. jack_lsp, jack_connect, jack_disconnect Patchage is a another GUI. There is also an emacs way, of course;) -- 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 conrad.berhoerster at gmx.de Sat Oct 8 09:03:31 2005 From: conrad.berhoerster at gmx.de (conrad =?utf-8?q?berh=C3=B6rster?=) Date: Sat Oct 8 09:06:11 2005 Subject: [linux-audio-dev] Command line patchbay for jack In-Reply-To: <87ll14m5dd.fsf@quasar.esben-stien.name> References: <4346AC70.3000006@xung.org> <200510081410.58560.conrad.berhoerster@gmx.de> <87ll14m5dd.fsf@quasar.esben-stien.name> Message-ID: <200510081503.31955.conrad.berhoerster@gmx.de> thanks to all for the quick answers sizu c~ Am Samstag, 8. Oktober 2005 16:48 schrieb Esben Stien: > conrad berh?rster writes: > > is there a way to connect jack applications without qjackctl. > > jack_lsp, jack_connect, jack_disconnect > > Patchage is a another GUI. There is also an emacs way, of course;) From julien at c-lab.de Sat Oct 8 11:05:30 2005 From: julien at c-lab.de (Julien Claassen) Date: Sat Oct 8 11:05:42 2005 Subject: [linux-audio-dev] csound lpc (lpanal) and dssi-support question Message-ID: Hi mates! I wonder if anyone of you could help me a bit. Part of the question I have I asked before. I'm trying to do lpc with csound5. Unfortunitely lpanal in csound5 is still broken, so I use lpanal of older csound4 version. The output I get is silence with one or to glitches in between. Any idea what I'm doing wrong or what csound's doing wrong? Material for the analysis was speech input. Second: Does anyone know more about the status of dssi-support in csound5? I tried but I wouldn't get the expected result. Either I get silence or just the original signal (no effect applied). Any working example known? Thanks for ANY help! I would greatly appreciate it! Kindest regards Julien P.S.: If anyone knows a much better place to ask my csound questions, please give me an urls or mail-adsress. -------- 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 gml at xs4all.nl Sat Oct 8 16:14:36 2005 From: gml at xs4all.nl (vanDongen/Gilcher) Date: Sat Oct 8 14:07:38 2005 Subject: [linux-audio-dev] csound lpc (lpanal) and dssi-support question In-Reply-To: References: Message-ID: <200510082014.36551.gml@xs4all.nl> On Saturday 08 October 2005 15:05, Julien Claassen wrote: > P.S.: If anyone knows a much better place to ask my csound questions, > please give me an urls or mail-adsress. > There is the csound list and the csound development list. There were some mails on lpc recently on it IIRC. Look at http://www.csounds.com It has links for all the mailing lists, a lot references and tutorials. Gerard From jens.andreasen at chello.se Sun Oct 9 01:30:09 2005 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Sun Oct 9 01:30:18 2005 Subject: [linux-audio-dev] [ANN] WhySynth DSSI softsynth In-Reply-To: <5fde3b6f7456e5db1800b13c7d35671e@jps.net> References: <5fde3b6f7456e5db1800b13c7d35671e@jps.net> Message-ID: <1128835809.26780.9.camel@c80-216-125-193.cm-upc.chello.se> Whoaa! Some really impressive specs. Are you trying to corner the market as in "the only soffsynth you'll ever, ever need!!" :) Can it run 'stand alone'? Do you have some rough statistics on number of voices/gigahertz? /jens On Wed, 2005-10-05 at 16:05 -0700, Sean Bolton wrote: > Introducing WhySynth, a DSSI softsynth plugin. > > WhySynth, as in 'Y'-synth, the super-sized, frankensteinized, > evolved and mutated, still rather dorky younger sibling of > Xsynth-DSSI. > > WhySynth, as in (I sometimes ask), "_why_ am I working on another > softsynth instead of on paying gigs?" (Following my bliss? > Addiction? One last shot at misspent youth?) > > WhySynth, as in a mostly-new design featuring: > > - 4 oscillators per voice, in your choice of 6 modes (minBLEP, > wavecycle, asynchronous granular, FM, waveshaper, and noise), > > - 2 filters, also in multiple flavors, > > - flexible routing and mixdown to stereo output, > > - 3 (or is it 6?) LFOs (instrument-wide, per-voice, and multiphase), > > - 5 multi-mode envelope generators, > > - abundant modulation options, > > - and effects (well, Tim Goetze's Versatile plate reverb is all at > the moment, unless you count the DC-blocker anti-effect). > > WhySynth is a work in progress. Actually, since the kid was born, > progress has slowed to a near-utter standstill, but if I can't > release often, I might as well release early. > > Get your tarball, boring screenshot, and html-ized README today at: > > http://home.jps.net/~musound/whysynth.html > > then get your butts back to making cool music -- however you define > that. Cheers, > > -Sean > -- From jens.andreasen at chello.se Sun Oct 9 06:33:25 2005 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Sun Oct 9 06:33:29 2005 Subject: [linux-audio-dev] [ANN] WhySynth DSSI softsynth In-Reply-To: <5fde3b6f7456e5db1800b13c7d35671e@jps.net> References: <5fde3b6f7456e5db1800b13c7d35671e@jps.net> Message-ID: <1128854005.9616.28.camel@elephant> On Wed, 2005-10-05 at 16:05 -0700, Sean Bolton wrote: > WhySynth, as in (I sometimes ask), "_why_ am I working on another > softsynth instead of on paying gigs?" (Following my bliss? > Addiction? One last shot at misspent youth?) Heh :) Once you have done one, you are addicted. This is not nescessarily a bad thing. Laying out a synthesizer requires as much consideration as laying out say; the main theme for film-score. A few cycles of scrapping and reinventing is expected, perhaps even required. mvh // Jens M Andreasen From ml at xung.org Sun Oct 9 08:43:21 2005 From: ml at xung.org (Olivier Guilyardi) Date: Sun Oct 9 08:43:25 2005 Subject: [linux-audio-dev] New RSS feed for Linux Audio Announce In-Reply-To: <877jcosteh.fsf@quasar.esben-stien.name> References: <4346AC70.3000006@xung.org> <877jcosteh.fsf@quasar.esben-stien.name> Message-ID: <43491069.3030503@xung.org> Esben Stien wrote: > Olivier Guilyardi writes: > > >>I have set up an RSS feed for Linux Audio Announce > > > ;) > By the way, there is a little problem. I can not properly extract a (short) description from messages to fill the rss tag in. I propose that you optionally include a small section in you messages to LAD, something like : Foo 5.88.75 is online. Foo is a Bar synthetizer, etc... Is it ok with you developers ? -- og From jamesmichaelmcdermott at gmail.com Sun Oct 9 09:44:30 2005 From: jamesmichaelmcdermott at gmail.com (James McDermott) Date: Sun Oct 9 09:44:33 2005 Subject: [linux-audio-dev] [ANN] WhySynth DSSI softsynth In-Reply-To: <1128835809.26780.9.camel@c80-216-125-193.cm-upc.chello.se> References: <5fde3b6f7456e5db1800b13c7d35671e@jps.net> <1128835809.26780.9.camel@c80-216-125-193.cm-upc.chello.se> Message-ID: On 10/9/05, Jens M Andreasen wrote: > Can it run 'stand alone'? There are two fairly minimal DSSI hosts, ghostess and jack-dssi-host, which receive MIDI and output to Jack, so the stand-alone feature always comes for free... James From jens.andreasen at chello.se Sun Oct 9 10:40:41 2005 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Sun Oct 9 10:40:46 2005 Subject: [linux-audio-dev] [ANN] WhySynth DSSI softsynth In-Reply-To: References: <5fde3b6f7456e5db1800b13c7d35671e@jps.net> <1128835809.26780.9.camel@c80-216-125-193.cm-upc.chello.se> Message-ID: <1128868841.9616.90.camel@c80-216-125-193.cm-upc.chello.se> I reckon this as 'no' On Sun, 2005-10-09 at 14:44 +0100, James McDermott wrote: > On 10/9/05, Jens M Andreasen wrote: > > > Can it run 'stand alone'? > > There are two fairly minimal DSSI hosts, ghostess and jack-dssi-host, > which receive MIDI and output to Jack, so the stand-alone feature > always comes for free... > > James > -- From larsl at users.sourceforge.net Sun Oct 9 10:59:19 2005 From: larsl at users.sourceforge.net (Lars Luthman) Date: Sun Oct 9 10:58:38 2005 Subject: [linux-audio-dev] [ANN] WhySynth DSSI softsynth In-Reply-To: <1128868841.9616.90.camel@c80-216-125-193.cm-upc.chello.se> References: <5fde3b6f7456e5db1800b13c7d35671e@jps.net> <1128835809.26780.9.camel@c80-216-125-193.cm-upc.chello.se> <1128868841.9616.90.camel@c80-216-125-193.cm-upc.chello.se> Message-ID: <1128869959.8801.23.camel@c213-100-50-8.swipnet.se> On Sun, 2005-10-09 at 16:40 +0200, Jens M Andreasen wrote: > On Sun, 2005-10-09 at 14:44 +0100, James McDermott wrote: > > On 10/9/05, Jens M Andreasen wrote: > > > > > Can it run 'stand alone'? > > > > There are two fairly minimal DSSI hosts, ghostess and jack-dssi-host, > > which receive MIDI and output to Jack, so the stand-alone feature > > always comes for free... > > I reckon this as 'no' Why? jack-dssi-host whysynth.so ...and you will have a stand-alone process with an ALSA MIDI port and JACK audio output that will quit when you close the WhySynth GUI window. -- Lars Luthman PGP key: http://www.d.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- 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/20051009/52138c91/attachment.bin From cannam at all-day-breakfast.com Sun Oct 9 11:17:15 2005 From: cannam at all-day-breakfast.com (Chris Cannam) Date: Sun Oct 9 11:15:40 2005 Subject: [linux-audio-dev] [ANN] WhySynth DSSI softsynth In-Reply-To: <1128869959.8801.23.camel@c213-100-50-8.swipnet.se> References: <5fde3b6f7456e5db1800b13c7d35671e@jps.net> <1128868841.9616.90.camel@c80-216-125-193.cm-upc.chello.se> <1128869959.8801.23.camel@c213-100-50-8.swipnet.se> Message-ID: <200510091617.15617.cannam@all-day-breakfast.com> On Sunday 09 Oct 2005 15:59, Lars Luthman wrote: > jack-dssi-host whysynth.so Simpler still, start with this (or make the synth's installer do this): # ln -s jack-dssi-host /usr/bin/whysynth Then you can just run $ whysynth for the same thing (a standalone GUI program with ALSA sequencer MIDI input and JACK audio output). Chris From derek at x-i.net Sun Oct 9 11:45:33 2005 From: derek at x-i.net (derek holzer) Date: Sun Oct 9 11:45:42 2005 Subject: [linux-audio-dev] [ANN] WhySynth DSSI softsynth In-Reply-To: <200510091617.15617.cannam@all-day-breakfast.com> References: <5fde3b6f7456e5db1800b13c7d35671e@jps.net> <1128868841.9616.90.camel@c80-216-125-193.cm-upc.chello.se> <1128869959.8801.23.camel@c213-100-50-8.swipnet.se> <200510091617.15617.cannam@all-day-breakfast.com> Message-ID: <43493B1D.3060404@x-i.net> Very nice, hours of fun in there to be sure. But how can you handle MIDI bindings? For example, to control one of the filter resonance knobs rather than just the MIDI note/pitchwheel in? d. -- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 124: "Once the search is in progress, something will be found" From S.W.Harris at ecs.soton.ac.uk Sun Oct 9 12:06:32 2005 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sun Oct 9 12:06:42 2005 Subject: [linux-audio-dev] [ANN] WhySynth DSSI softsynth In-Reply-To: <43493B1D.3060404@x-i.net> References: <5fde3b6f7456e5db1800b13c7d35671e@jps.net> <1128868841.9616.90.camel@c80-216-125-193.cm-upc.chello.se> <1128869959.8801.23.camel@c213-100-50-8.swipnet.se> <200510091617.15617.cannam@all-day-breakfast.com> <43493B1D.3060404@x-i.net> Message-ID: <20051009160632.GA25833@login.ecs.soton.ac.uk> On Sun, Oct 09, 2005 at 05:45:33PM +0200, derek holzer wrote: > Very nice, hours of fun in there to be sure. But how can you handle MIDI > bindings? For example, to control one of the filter resonance knobs > rather than just the MIDI note/pitchwheel in? Plugins can specify default CC and NRPN bindgins in thier metadata. - Steve From larsl at users.sourceforge.net Sun Oct 9 12:10:43 2005 From: larsl at users.sourceforge.net (Lars Luthman) Date: Sun Oct 9 12:10:01 2005 Subject: [linux-audio-dev] [ANN] WhySynth DSSI softsynth In-Reply-To: <43493B1D.3060404@x-i.net> References: <5fde3b6f7456e5db1800b13c7d35671e@jps.net> <1128868841.9616.90.camel@c80-216-125-193.cm-upc.chello.se> <1128869959.8801.23.camel@c213-100-50-8.swipnet.se> <200510091617.15617.cannam@all-day-breakfast.com> <43493B1D.3060404@x-i.net> Message-ID: <1128874243.8801.28.camel@c213-100-50-8.swipnet.se> On Sun, 2005-10-09 at 17:45 +0200, derek holzer wrote: > Very nice, hours of fun in there to be sure. But how can you handle MIDI > bindings? For example, to control one of the filter resonance knobs > rather than just the MIDI note/pitchwheel in? DSSI plugins map MIDI CCs to control inputs (or at least they should, the DSSI API supports it). Unfortunately there is no way to see from the "outside" (i.e. from another program) what the bindings are, only the plugin host can see that - but that is a limitation in the ALSA sequencer API that would be hard to get around. -- Lars Luthman PGP key: http://www.d.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- 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/20051009/fa931740/attachment.bin From cannam at all-day-breakfast.com Sun Oct 9 12:42:08 2005 From: cannam at all-day-breakfast.com (Chris Cannam) Date: Sun Oct 9 12:40:32 2005 Subject: [linux-audio-dev] MVC - multiple CV In-Reply-To: <1128383999.26818.215.camel@dhin> References: <20051003221216.GC4954@linux-1> <1128383999.26818.215.camel@dhin> Message-ID: <200510091742.08334.cannam@all-day-breakfast.com> [I replied to this at the time, but I think my reply ended up in the moderation black hole for some reason I don't quite understand] On Tuesday 04 Oct 2005 00:59, Paul Davis wrote: > > It has been stated that the model should send updates to > > all clients except the one that originated a parameter change. > > never seen that stated. DSSI explicitly requires this behaviour for the host sending updates to plugin UIs. That requirement was the subject of some discussion at the time (see http://lalists.stanford.edu/lad/2004/07/0263.html in which Fons takes the same side of the debate as at present and Steve Harris argues for the other side). Dave Robillard wrote: > Generally when > given the choice I'll choose complexity in the client over complexity > in the engine any day. This is exactly the opposite of what DSSI aims for. The principle (which may or may not be correct) is that the host only has to be written once, and a bit of pain in the implementation won't prevent people from doing it, whereas the plugin UIs have to be written many times by lots of people and should therefore be made simpler at the cost of extra complexity in the host. FWIW I think the arguments on both sides have quite a bit of merit. One irony is that at the time of the above discussion, it would actually have been impossible for any DSSI host that used liblo to properly implement the requirement because liblo had no way to commnuicate the origin of an incoming message. We didn't notice that until a couple of months later when we discovered the reference host didn't work right. It's fixed now. > but, as i said, i am trying to phase this out in favor of a model > where there are no changes to the View until the Model sends a > notification. this is not easy to do and impossible where the view is a hardware fader, presumably -- as a DSSI UI could be. Chris From jens.andreasen at chello.se Sun Oct 9 13:01:14 2005 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Sun Oct 9 13:01:20 2005 Subject: [linux-audio-dev] [ANN] WhySynth DSSI softsynth In-Reply-To: <1128869959.8801.23.camel@c213-100-50-8.swipnet.se> References: <5fde3b6f7456e5db1800b13c7d35671e@jps.net> <1128835809.26780.9.camel@c80-216-125-193.cm-upc.chello.se> <1128868841.9616.90.camel@c80-216-125-193.cm-upc.chello.se> <1128869959.8801.23.camel@c213-100-50-8.swipnet.se> Message-ID: <1128877274.10201.4.camel@c80-216-125-193.cm-upc.chello.se> On Sun, 2005-10-09 at 16:59 +0200, Lars Luthman wrote: > > I reckon this as 'no' > > Why? > > jack-dssi-host whysynth.so > > ...and you will have a stand-alone process with an ALSA MIDI port and > JACK audio output that will quit when you close the WhySynth GUI > window. OK OK, I buy that except that it will fail if jack is not running, hence the stand alone qualifier. /j > -- From paul at linuxaudiosystems.com Sun Oct 9 13:22:50 2005 From: paul at linuxaudiosystems.com (Paul Davis) Date: Sun Oct 9 13:21:19 2005 Subject: [linux-audio-dev] [ANN] WhySynth DSSI softsynth In-Reply-To: <1128877274.10201.4.camel@c80-216-125-193.cm-upc.chello.se> References: <5fde3b6f7456e5db1800b13c7d35671e@jps.net> <1128835809.26780.9.camel@c80-216-125-193.cm-upc.chello.se> <1128868841.9616.90.camel@c80-216-125-193.cm-upc.chello.se> <1128869959.8801.23.camel@c213-100-50-8.swipnet.se> <1128877274.10201.4.camel@c80-216-125-193.cm-upc.chello.se> Message-ID: <1128878570.12415.62.camel@dhin> On Sun, 2005-10-09 at 19:01 +0200, Jens M Andreasen wrote: > On Sun, 2005-10-09 at 16:59 +0200, Lars Luthman wrote: > > > > I reckon this as 'no' > > > > Why? > > > > jack-dssi-host whysynth.so > > > > ...and you will have a stand-alone process with an ALSA MIDI port and > > JACK audio output that will quit when you close the WhySynth GUI > > window. > > OK OK, I buy that except that it will fail if jack is not running, hence > the stand alone qualifier. not if jack-dssi-host uses jack_client_open() with the appropriate flags. --p From jens.andreasen at chello.se Sun Oct 9 14:18:09 2005 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Sun Oct 9 14:18:17 2005 Subject: [linux-audio-dev] [ANN] WhySynth DSSI softsynth In-Reply-To: <1128878570.12415.62.camel@dhin> References: <5fde3b6f7456e5db1800b13c7d35671e@jps.net> <1128835809.26780.9.camel@c80-216-125-193.cm-upc.chello.se> <1128868841.9616.90.camel@c80-216-125-193.cm-upc.chello.se> <1128869959.8801.23.camel@c213-100-50-8.swipnet.se> <1128877274.10201.4.camel@c80-216-125-193.cm-upc.chello.se> <1128878570.12415.62.camel@dhin> Message-ID: <1128881889.10201.15.camel@c80-216-125-193.cm-upc.chello.se> On Sun, 2005-10-09 at 13:22 -0400, Paul Davis wrote: > On Sun, 2005-10-09 at 19:01 +0200, Jens M Andreasen wrote: > > On Sun, 2005-10-09 at 16:59 +0200, Lars Luthman wrote: > > > > > > I reckon this as 'no' > > > > > > Why? > > > > > > jack-dssi-host whysynth.so > > > > > > ...and you will have a stand-alone process with an ALSA MIDI port and > > > JACK audio output that will quit when you close the WhySynth GUI > > > window. > > > > OK OK, I buy that except that it will fail if jack is not running, hence > > the stand alone qualifier. > > not if jack-dssi-host uses jack_client_open() with the appropriate > flags. > This is getting silly. All I wanted to do was to ackowledge that I have read thru Boltons site. He has some humor in his style of expressing himself and a ton of dependencies (of which I have most installed, but not all.) Let Bolton speak for himself, please. Gentlemen please ... /j > --p > > -- From fons.adriaensen at skynet.be Sun Oct 9 16:58:50 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Sun Oct 9 17:35:25 2005 Subject: [linux-audio-dev] MVC - multiple CV In-Reply-To: <200510091742.08334.cannam@all-day-breakfast.com> References: <20051003221216.GC4954@linux-1> <1128383999.26818.215.camel@dhin> <200510091742.08334.cannam@all-day-breakfast.com> Message-ID: <20051009205850.GA4821@linux-1> On Sun, Oct 09, 2005 at 05:42:08PM +0100, Chris Cannam wrote: > DSSI explicitly requires this behaviour for the host sending updates to > plugin UIs. That requirement was the subject of some discussion at the > time (see http://lalists.stanford.edu/lad/2004/07/0263.html in which > Fons takes the same side of the debate as at present and Steve Harris > argues for the other side). I remember that discussion, and indeed I still think the same. The solution I adopted for Aeolus is like this: - Each command (C->M) is tagged by an ID from the the originator, and this is copied in all resulting messages from M to all V. - A controllor can use two IDs, one for 'transient' parameter values (e.g. a slider being dragged), and one for 'final' ones (the slider being released). It can then just ignore transient updates from itself. The logic required is trivially simple, and it solves all problems. > Dave Robillard wrote: > > Generally when > > given the choice I'll choose complexity in the client over complexity > > in the engine any day. > > This is exactly the opposite of what DSSI aims for. The principle > (which may or may not be correct) is that the host only has to be > written once, and a bit of pain in the implementation won't prevent > people from doing it, whereas the plugin UIs have to be written many > times by lots of people and should therefore be made simpler at the > cost of extra complexity in the host. > > FWIW I think the arguments on both sides have quite a bit of merit. The 'extra complexity' in the plugins consists of a simple check on one value. It could easily be built into a development toolkit and and plugin writers wouldn't even have to see it. More generally, the decision of where and how some functionality should be implemented must IMHO be guided by a *logical* analysis of the problem at hand, and not by political reasons such as 'it must be as easy as possible for the masses'. The latter, in my experience, just leads to problems and dirty-hack solutions later, when things need to be scaled up or generalised. -- FA From drobilla at connect.carleton.ca Mon Oct 10 01:34:22 2005 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Mon Oct 10 01:35:06 2005 Subject: [linux-audio-dev] MVC - multiple CV In-Reply-To: <200510091742.08334.cannam@all-day-breakfast.com> References: <20051003221216.GC4954@linux-1> <1128383999.26818.215.camel@dhin> <200510091742.08334.cannam@all-day-breakfast.com> Message-ID: <1128922462.4062.9.camel@localhost.localdomain> On Sun, 2005-09-10 at 17:42 +0100, Chris Cannam wrote: > Dave Robillard wrote: > > Generally when > > given the choice I'll choose complexity in the client over complexity > > in the engine any day. > > This is exactly the opposite of what DSSI aims for. The principle > (which may or may not be correct) is that the host only has to be > written once, and a bit of pain in the implementation won't prevent > people from doing it, whereas the plugin UIs have to be written many > times by lots of people and should therefore be made simpler at the > cost of extra complexity in the host. I don't see the plugin/host split being the same situation as the engine/UI split at all, really. If anything, DSSI plugins themselves have the same issue - complexity in the plugin (engine) vs complexity in the GUI (client). DSSI just has the convenience of skirting the issue by making hosts deal with (part of) it. Hosts don't have it so easy. :) I couldn't agree more that complexity belongs in the host over the plugin though. -DR- From loki.davison at gmail.com Mon Oct 10 03:24:20 2005 From: loki.davison at gmail.com (Loki Davison) Date: Mon Oct 10 03:24:28 2005 Subject: [linux-audio-dev] Smack 0.2 released. Message-ID: Hi all, Smack 0.2 is now out. Smack is a drum synth, 100% sample free. It's built with LADSPA plugins and the Om modular synth. New in this release are Noise and resonate filter based metallic percussion, ring modulation based drums, velocity sensitivity, control ports for all drums and random other goodness. Get it at http://smack.berlios.de/ There are also some new sound demos on the site including a physical modeling based djembe. The gui is no longer included due to huge improvements with om_gtk, and lack of time for maintaining it. Please just use om_gtk or the emacs bindings. Cheers, Loki From loki.davison at gmail.com Mon Oct 10 04:11:16 2005 From: loki.davison at gmail.com (Loki Davison) Date: Mon Oct 10 04:11:28 2005 Subject: [linux-audio-dev] Re: Smack 0.2 released. In-Reply-To: References: Message-ID: On 10/10/05, Loki Davison wrote: > Hi all, > Smack 0.2 is now out. Smack is a drum synth, 100% sample free. It's > built with LADSPA plugins and the Om modular synth. New in this > release are Noise and resonate filter based metallic percussion, ring > modulation based drums, velocity sensitivity, control ports for all > drums and random other goodness. Get it at http://smack.berlios.de/ > There are also some new sound demos on the site including a physical > modeling based djembe. The gui is no longer included due to huge > improvements with om_gtk, and lack of time for maintaining it. Please > just use om_gtk or the emacs bindings. > > Cheers, > Loki > oops... Forgot to mention, some drums do require omins cvs. If at first it doesn't work get that. A new release of omins should be out in this interglacial period. Loki From arnold.krille at gmail.com Mon Oct 10 11:52:47 2005 From: arnold.krille at gmail.com (Arnold Krille) Date: Mon Oct 10 11:52:49 2005 Subject: [linux-audio-dev] Re: snd-usb-usx2y on amd64? In-Reply-To: <200510061716.22066.annabellesgarden@yahoo.de> References: <2def88b80510010554k7145035bx@mail.gmail.com> <200510061446.14665.annabellesgarden@yahoo.de> <2def88b80510060549yde3b427k@mail.gmail.com> <200510061716.22066.annabellesgarden@yahoo.de> Message-ID: <2def88b80510100852g13adc50bi@mail.gmail.com> I made some progress over the weekend... On 10/6/05, Karsten Wiese wrote: > Am Donnerstag, 6. Oktober 2005 14:49 schrieb Arnold Krille: > > On 10/6/05, Karsten Wiese wrote: > > > Or use netconsole. > > > See kernel/Documentation or google for how-tos. > > Hmm, maybe I can try this. Thanks, Couldn't get that to run which isn't that important as I found other ways... > If it'd be a freeze, you can start an RT console before your test > with > $ chrt -f 99 xterm& Didn't had that installed either (until now)... > If its not a crash you maybe see something there. As the system doesn't seem to freeze after the first jackd-start using mm-sources, I watched the syslog in one window and got some logs: Using 2.6.14-mm-rc1 with Preemption enabled I get "should not be here with count=0" in the syslog after some (short) time and jack stops working. The message comes from usbusx2yaudio.c (I added the relevant info to the c-file to definitly know its from there and not from the second file containing the same line). Also I do get a kernel-oops which kills my usb-bus (no mouse anymore, only touchpad remains). The snd-usb-usx2y-module can never be unloaded and sometimes the system freezes on this setup... Using the same kernel but without Preemption I get the same message from the usb-usx2y-driver as above shortly after I start jackd(*) and connect the ins with the outs. On second try of starting jackd I get "usb_submit_urb() returned -22" in syslog. Maybe that helps to tell me where I can enable more debug-output to investigate the driver/kernel... One of the other things I will try the next days is to test with the rather old 2.6.11* kernel as I know that that version works on my other two systems. > Or stop the hog. Sorry for me making such a fuss, its just depressing paying a lot of money to get a state-of-the-art laptop and realizing that it doesn't even seem to be able to deal with slow usb1.1 hardware. Let me state that I am absolutely willing to help solving this problem (if it really is a usb-usx2y-on-amd64-problem). Only problem is that I don't have internet-connection at home and can't carry my tascam to work every day. Have a nice day, Arnold (*) Everytime I started jackd with "jackd -dalsa -dhw:2" -- 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 mrfisher_1 at yahoo.com Mon Oct 10 13:37:28 2005 From: mrfisher_1 at yahoo.com (Mike Fisher) Date: Mon Oct 10 13:37:38 2005 Subject: [linux-audio-dev] envy24control Message-ID: <20051010173728.6925.qmail@web61016.mail.yahoo.com> When I try to compile the envy24control package I get the following during configure. checking for ALSA CFLAGS... checking for ALSA LDFLAGS... -lasound checking for libasound headers version >= 0.5.5... found. checking for snd_cards in -lasound... no configure: error: No linkable libasound was found. using gcc 3.3.6 Now, I'm not exactly sure what libasound does, but I do know that ardour, jack, and other alsa programs work for me with no problems. Any kind of help would be good. I'm still learning linux here so sorry guys. -Mike Fisher __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From paul at linuxaudiosystems.com Mon Oct 10 13:47:24 2005 From: paul at linuxaudiosystems.com (Paul Davis) Date: Mon Oct 10 13:45:52 2005 Subject: [linux-audio-dev] Re: [ardour-users] envy24control In-Reply-To: <20051010173728.6925.qmail@web61016.mail.yahoo.com> References: <20051010173728.6925.qmail@web61016.mail.yahoo.com> Message-ID: <1128966444.12415.77.camel@dhin> On Mon, 2005-10-10 at 10:37 -0700, Mike Fisher wrote: > When I try to compile the envy24control package I get > the following during configure. > > checking for ALSA CFLAGS... > checking for ALSA LDFLAGS... -lasound > checking for libasound headers version >= 0.5.5... > found. > checking for snd_cards in -lasound... no > configure: error: No linkable libasound was found. you probably need a package called "alsa-lib-devel" installed. most distributions split libraries into two packages. one has the stuff needed by people who never compile from source, it just has whatever is needed to allow programs that use the library to run; the other ("devel") has the stuff you need to compile and link programs that use the library. in general, distros install the non-devel library and not the devel package by default, because they don't expect their new users to be compiling stuff. how to install the package will vary depending on which distribution you are using. but ... there is really no obvious reason for you to be building it from source. envy24control is part of the alsatools package --p From musound at jps.net Mon Oct 10 17:47:44 2005 From: musound at jps.net (Sean Bolton) Date: Mon Oct 10 17:46:25 2005 Subject: [linux-audio-dev] [ANN] WhySynth DSSI softsynth In-Reply-To: <1128881889.10201.15.camel@c80-216-125-193.cm-upc.chello.se> References: <5fde3b6f7456e5db1800b13c7d35671e@jps.net> <1128835809.26780.9.camel@c80-216-125-193.cm-upc.chello.se> <1128868841.9616.90.camel@c80-216-125-193.cm-upc.chello.se> <1128869959.8801.23.camel@c213-100-50-8.swipnet.se> <1128877274.10201.4.camel@c80-216-125-193.cm-upc.chello.se> <1128878570.12415.62.camel@dhin> <1128881889.10201.15.camel@c80-216-125-193.cm-upc.chello.se> Message-ID: <5e7023ac61a6a4a7e22a2b2d55e6d473@jps.net> On Oct 9, 2005, at 11:18 AM, Jens M Andreasen wrote: > Let Bolton speak for himself, please. Gentlemen please ... Bolton speaks for himself, thusly: On Oct 8, 2005, at 10:30 PM, Jens M Andreasen wrote: > Whoaa! > > Some really impressive specs. Are you trying to corner the market as in > "the only soffsynth you'll ever, ever need!!" :) Right-o, as in Guinness is the only beer you'll ever, ever need, and Gentoo is the only distro you'll ever, ever need!! > Do you have some rough statistics on number of voices/gigahertz? That depends on the patch. With a simple two-oscillator, single filter patch playing 16 voices, my 933MHz Pentium 3 barely breaks a sweat (17% CPU according to top, 22% according to qjackctl). One the other hand, with the most expensive patch I can think of, it maxes out at only two voices. On Oct 9, 2005, at 3:33 AM, Jens M Andreasen wrote: >> WhySynth, as in (I sometimes ask), "_why_ am I working on another >> softsynth instead of on paying gigs?" (Following my bliss? >> Addiction? One last shot at misspent youth?) > > Heh :) Once you have done one, you are addicted. > > This is not nescessarily a bad thing. Laying out a synthesizer > requires > as much consideration as laying out say; the main theme for film-score. > A few cycles of scrapping and reinventing is expected, perhaps even > required. Yeah, addicted is right. I code in a very experimental, improvisational way. If I could manage only a _few_ cycles of scrapping and reinventing, I would be much more efficient! On Oct 9, 2005, at 8:45 AM, derek holzer wrote: > Very nice, hours of fun in there to be sure. But how can you handle > MIDI bindings? For example, to control one of the filter resonance > knobs rather than just the MIDI note/pitchwheel in? That's one of the things I haven't done yet, and one of the awkward parts of DSSI. Several people (two?) have pointed out that DSSI provides for binding MIDI CCs/NRPNs to ports ('knobs'), but the plugin must declare these bindings to the host before the GUI gets a chance to run. So you either have to make them hard-coded, or require the user to exit-and-restart in order to implement custom bindings. If you wanna hard-code your own bindings, I'll tell you how.... (Just look in src/dssp_synth.c for the Y_PORT_GLIDE_TIME binding to the MIDI portamento time CC, follow the example, and recompile :-/) Thanks, everyone, for your comments and questions, -Sean From fons.adriaensen at skynet.be Mon Oct 10 19:02:59 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Mon Oct 10 18:58:33 2005 Subject: [linux-audio-dev] file format Message-ID: <20051010230259.GA4955@linux-1> Hi all, For one of my current projects (to be presented at LAC2006) I'm looking for a suitable file format. Each file should contain: - A number of short (+/- 10 seconds) chunks of PCM audio. The number of channels will be different in each chunk. The only sample format required is single precision floating point. For multi-channel chunks, non-interleaved is preferred. All chunks will normally use the same sample frequency. - Metadata, both numerical and textual. The format should allow to have several chunks of these, and to add new ones later without breaking compatibility (i.e. readers will ignore parts they do not understand). There is no need for the audio to be usable with normal players - it's not meant to be listened to directly. Is there any standard file/container format that would provide for this sort of thing ? I've been looking at ogg, but it's a bit over the top - I don't need any streaming features. The alternative is of course to have separate WAV files and some text file for the metadata, and combine all of this into a directory that would then be handled as a unit. But I'd prefer to have all data in a single file. -- FA From rzewnickie at rfa.org Mon Oct 10 19:14:01 2005 From: rzewnickie at rfa.org (Eric Dantan Rzewnicki) Date: Mon Oct 10 19:14:09 2005 Subject: [linux-audio-dev] file format In-Reply-To: <20051010230259.GA4955@linux-1> References: <20051010230259.GA4955@linux-1> Message-ID: <20051010231401.GO10975@rfa.org> On Tue, Oct 11, 2005 at 01:02:59AM +0200, fons adriaensen wrote: > Hi all, > For one of my current projects (to be presented at LAC2006) I'm > looking for a suitable file format. > > Each file should contain: > > - A number of short (+/- 10 seconds) chunks of PCM audio. The number > of channels will be different in each chunk. The only sample format > required is single precision floating point. For multi-channel > chunks, non-interleaved is preferred. All chunks will normally use > the same sample frequency. > > - Metadata, both numerical and textual. The format should allow to > have several chunks of these, and to add new ones later without > breaking compatibility (i.e. readers will ignore parts they do > not understand). > > There is no need for the audio to be usable with normal players - > it's not meant to be listened to directly. > > Is there any standard file/container format that would provide for > this sort of thing ? I've been looking at ogg, but it's a bit over > the top - I don't need any streaming features. > > The alternative is of course to have separate WAV files and some > text file for the metadata, and combine all of this into a directory > that would then be handled as a unit. But I'd prefer to have all > data in a single file. Maybe braodcast wav files with cart chunk chunks. -- Eric Dantan Rzewnicki | Systems Administrator 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 forums at machinehasnoagenda.com Mon Oct 10 19:37:32 2005 From: forums at machinehasnoagenda.com (Shayne O'Connor) Date: Mon Oct 10 19:37:40 2005 Subject: [linux-audio-dev] Re: Smack 0.2 released. In-Reply-To: References: Message-ID: <434AFB3C.2020209@machinehasnoagenda.com> Loki Davison wrote: > On 10/10/05, Loki Davison wrote: > >>Hi all, >>Smack 0.2 is now out. Smack is a drum synth, 100% sample free. It's >>built with LADSPA plugins and the Om modular synth. New in this >>release are Noise and resonate filter based metallic percussion, ring >>modulation based drums, velocity sensitivity, control ports for all >>drums and random other goodness. Get it at http://smack.berlios.de/ >>There are also some new sound demos on the site including a physical >>modeling based djembe. The gui is no longer included due to huge >>improvements with om_gtk, and lack of time for maintaining it. Please >>just use om_gtk or the emacs bindings. seems the configure script still requires the gui: [mrmachine@localhost smack-0.2.0]$ ./configure --prefix=/usr configure: error: cannot find sources (gui.c) in . or .. i tried commenting out the offending line, but that was just a shot in the dark, really ... me wants me smack! shayne From forums at machinehasnoagenda.com Mon Oct 10 19:44:44 2005 From: forums at machinehasnoagenda.com (Shayne O'Connor) Date: Mon Oct 10 19:44:51 2005 Subject: [linux-audio-dev] Re: Smack 0.2 released. In-Reply-To: References: Message-ID: <434AFCEC.4030800@machinehasnoagenda.com> Loki Davison wrote: > On 10/10/05, Loki Davison wrote: > >>Hi all, >>Smack 0.2 is now out. Smack is a drum synth, 100% sample free. It's >>built with LADSPA plugins and the Om modular synth. New in this >>release are Noise and resonate filter based metallic percussion, ring >>modulation based drums, velocity sensitivity, control ports for all >>drums and random other goodness. Get it at http://smack.berlios.de/ >>There are also some new sound demos on the site including a physical >>modeling based djembe. The gui is no longer included due to huge >>improvements with om_gtk, and lack of time for maintaining it. Please >>just use om_gtk or the emacs bindings. seems the configure script still requires the gui: [mrmachine@localhost smack-0.2.0]$ ./configure --prefix=/usr configure: error: cannot find sources (gui.c) in . or .. i tried commenting out the offending line, but that was just a shot in the dark, really ... me wants me smack! shayne From paul at linuxaudiosystems.com Mon Oct 10 20:08:22 2005 From: paul at linuxaudiosystems.com (Paul Davis) Date: Mon Oct 10 20:06:53 2005 Subject: [linux-audio-dev] file format In-Reply-To: <20051010230259.GA4955@linux-1> References: <20051010230259.GA4955@linux-1> Message-ID: <1128989302.12415.84.camel@dhin> On Tue, 2005-10-11 at 01:02 +0200, fons adriaensen wrote: > The alternative is of course to have separate WAV files and some > text file for the metadata, and combine all of this into a directory > that would then be handled as a unit. But I'd prefer to have all > data in a single file. tar? (paul runs for cover ...) From loki.davison at gmail.com Mon Oct 10 21:41:02 2005 From: loki.davison at gmail.com (Loki Davison) Date: Mon Oct 10 21:41:04 2005 Subject: [linux-audio-dev] Re: Smack 0.2 released. In-Reply-To: <434AFB3C.2020209@machinehasnoagenda.com> References: <434AFB3C.2020209@machinehasnoagenda.com> Message-ID: On 10/11/05, Shayne O'Connor wrote: > Loki Davison wrote: > > On 10/10/05, Loki Davison wrote: > > > >>Hi all, > >>Smack 0.2 is now out. Smack is a drum synth, 100% sample free. It's > >>built with LADSPA plugins and the Om modular synth. New in this > >>release are Noise and resonate filter based metallic percussion, ring > >>modulation based drums, velocity sensitivity, control ports for all > >>drums and random other goodness. Get it at http://smack.berlios.de/ > >>There are also some new sound demos on the site including a physical > >>modeling based djembe. The gui is no longer included due to huge > >>improvements with om_gtk, and lack of time for maintaining it. Please > >>just use om_gtk or the emacs bindings. > > > seems the configure script still requires the gui: > > [mrmachine@localhost smack-0.2.0]$ ./configure --prefix=/usr > configure: error: cannot find sources (gui.c) in . or .. > > i tried commenting out the offending line, but that was just a shot in > the dark, really ... me wants me smack! > > shayne > Well... i feel some what stupid... Thanks for testing it... bugger, really should have tested for that! Removed it from the Makefile.am but not configure ;-) The whole autotools deal isn't really needed now unless i get round to making it check that all the required ladspas are there. Anyway, new tarball is up, called 0.2.1. Give me a yell what you think. Loki From S.W.Harris at ecs.soton.ac.uk Tue Oct 11 05:12:22 2005 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Tue Oct 11 05:12:36 2005 Subject: [linux-audio-dev] file format In-Reply-To: <1128989302.12415.84.camel@dhin> References: <20051010230259.GA4955@linux-1> <1128989302.12415.84.camel@dhin> Message-ID: <20051011091222.GB20721@login.ecs.soton.ac.uk> On Mon, Oct 10, 2005 at 08:08:22 -0400, Paul Davis wrote: > On Tue, 2005-10-11 at 01:02 +0200, fons adriaensen wrote: > > The alternative is of course to have separate WAV files and some > > text file for the metadata, and combine all of this into a directory > > that would then be handled as a unit. But I'd prefer to have all > > data in a single file. > > tar? (paul runs for cover ...) Actually a zip file plus manifest (aka jar or mozilla xpi) is an ok solution, they can be "mounted" by the application and have files pulled out, whereas tar files have to be unpacked to /tmp or similar. For the metadata an ASCII encoding of RDF (eg. turtle) would be ideal, but then you knew I was going to say that ;) - Steve From arnold.krille at gmail.com Tue Oct 11 05:31:46 2005 From: arnold.krille at gmail.com (Arnold Krille) Date: Tue Oct 11 05:31:48 2005 Subject: [linux-audio-dev] Re: snd-usb-usx2y on amd64? In-Reply-To: <2def88b80510100852g13adc50bi@mail.gmail.com> References: <2def88b80510010554k7145035bx@mail.gmail.com> <200510061446.14665.annabellesgarden@yahoo.de> <2def88b80510060549yde3b427k@mail.gmail.com> <200510061716.22066.annabellesgarden@yahoo.de> <2def88b80510100852g13adc50bi@mail.gmail.com> Message-ID: <2def88b80510110231ob4f6737w@mail.gmail.com> Another update: On 10/10/05, Arnold Krille wrote: > One of the other things I will try the next days is to test with the > rather old 2.6.11* kernel as I know that that version works on my > other two systems. Today I compiled that kernel and it is somehow better than the newer ones. I can use jack in Realtime with "-n 6 -p 256" and use qsampler or zyn or hydrogen without crashes. But then I tried to load ardour with a full-featured session while qsampler was also running and again jackd (and qjackctl) got killed and there was "shouldn't be here with count=0" in syslog. Please help! 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 fons.adriaensen at alcatel.be Tue Oct 11 07:51:18 2005 From: fons.adriaensen at alcatel.be (Alfons Adriaensen) Date: Tue Oct 11 07:51:22 2005 Subject: [linux-audio-dev] file format In-Reply-To: <20051011091222.GB20721@login.ecs.soton.ac.uk> References: <20051010230259.GA4955@linux-1> <1128989302.12415.84.camel@dhin> <20051011091222.GB20721@login.ecs.soton.ac.uk> Message-ID: <20051011115117.GB1659@bth05w.ABSp.alcatel.be> On Tue, Oct 11, 2005 at 10:12:22AM +0100, Steve Harris wrote: > On Mon, Oct 10, 2005 at 08:08:22 -0400, Paul Davis wrote: > > On Tue, 2005-10-11 at 01:02 +0200, fons adriaensen wrote: > > > The alternative is of course to have separate WAV files and some > > > text file for the metadata, and combine all of this into a directory > > > that would then be handled as a unit. But I'd prefer to have all > > > data in a single file. > > > > tar? (paul runs for cover ...) > > Actually a zip file plus manifest (aka jar or mozilla xpi) is an ok > solution, they can be "mounted" by the application and have files pulled > out, whereas tar files have to be unpacked to /tmp or similar. Reading tar files directly is easy enough - emacs does it for example. Any libs for jar / xpi ? My main objection to both would probably be that it's just a bit too easy to create them using 'general' tools only. I want to avoid incompatible parts being put together accidentally. That's also the main reason for preferring a single file over a directory. > For the metadata an ASCII encoding of RDF (eg. turtle) would be ideal, but > then you knew I was going to say that ;) I knew :-) I had already typed the line "No RDF please !" in my post, but then I considered "it's such a long time we heared anything from Steve", so I left it out :-). -- FA From larsl at users.sourceforge.net Tue Oct 11 08:20:30 2005 From: larsl at users.sourceforge.net (Lars Luthman) Date: Tue Oct 11 08:19:52 2005 Subject: [linux-audio-dev] file format In-Reply-To: <20051010230259.GA4955@linux-1> References: <20051010230259.GA4955@linux-1> Message-ID: <1129033231.8929.4.camel@c213-100-50-8.swipnet.se> On Tue, 2005-10-11 at 01:02 +0200, fons adriaensen wrote: > Hi all, > > For one of my current projects (to be presented at LAC2006) I'm > looking for a suitable file format. > > Each file should contain: > > - A number of short (+/- 10 seconds) chunks of PCM audio. The number > of channels will be different in each chunk. The only sample format > required is single precision floating point. For multi-channel > chunks, non-interleaved is preferred. All chunks will normally use > the same sample frequency. > > - Metadata, both numerical and textual. The format should allow to > have several chunks of these, and to add new ones later without > breaking compatibility (i.e. readers will ignore parts they do > not understand). > > There is no need for the audio to be usable with normal players - > it's not meant to be listened to directly. > > Is there any standard file/container format that would provide for > this sort of thing ? I've been looking at ogg, but it's a bit over > the top - I don't need any streaming features. Both WAVE and AIFF are (R)IFF based, so you can put any 'chunks' of arbitrary data in them and they will still be valid WAVE or AIFF files. -- Lars Luthman PGP key: http://www.d.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- 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/20051011/37521e89/attachment.bin From rzewnickie at rfa.org Tue Oct 11 12:11:42 2005 From: rzewnickie at rfa.org (Eric Dantan Rzewnicki) Date: Tue Oct 11 12:11:53 2005 Subject: [linux-audio-dev] file format In-Reply-To: <1129033231.8929.4.camel@c213-100-50-8.swipnet.se> References: <20051010230259.GA4955@linux-1> <1129033231.8929.4.camel@c213-100-50-8.swipnet.se> Message-ID: <20051011161142.GA11188@rfa.org> On Tue, Oct 11, 2005 at 02:20:30PM +0200, Lars Luthman wrote: > On Tue, 2005-10-11 at 01:02 +0200, fons adriaensen wrote: > > Hi all, > > > > For one of my current projects (to be presented at LAC2006) I'm > > looking for a suitable file format. > > > > Each file should contain: > > > > - A number of short (+/- 10 seconds) chunks of PCM audio. The number > > of channels will be different in each chunk. The only sample format > > required is single precision floating point. For multi-channel > > chunks, non-interleaved is preferred. All chunks will normally use > > the same sample frequency. > > > > - Metadata, both numerical and textual. The format should allow to > > have several chunks of these, and to add new ones later without > > breaking compatibility (i.e. readers will ignore parts they do > > not understand). > > > > There is no need for the audio to be usable with normal players - > > it's not meant to be listened to directly. > > > > Is there any standard file/container format that would provide for > > this sort of thing ? I've been looking at ogg, but it's a bit over > > the top - I don't need any streaming features. > > Both WAVE and AIFF are (R)IFF based, so you can put any 'chunks' of > arbitrary data in them and they will still be valid WAVE or AIFF files. Which is why I suggested broadcast wav and cart chunk as those are simply standardised 'chunks'. -- Eric Dantan Rzewnicki | Systems Administrator 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 ce at christeck.de Tue Oct 11 12:43:52 2005 From: ce at christeck.de (Christoph Eckert) Date: Tue Oct 11 12:38:21 2005 Subject: [linux-audio-dev] file format In-Reply-To: <20051011091222.GB20721@login.ecs.soton.ac.uk> References: <20051010230259.GA4955@linux-1> <1128989302.12415.84.camel@dhin> <20051011091222.GB20721@login.ecs.soton.ac.uk> Message-ID: <200510111843.52554.ce@christeck.de> > Actually a zip file plus manifest (aka jar or mozilla xpi) is an ok > solution, they can be "mounted" by the application and have files > pulled out, whereas tar files have to be unpacked to /tmp or similar. What about Flac? Best regards ce From b0ef at esben-stien.name Tue Oct 11 20:15:51 2005 From: b0ef at esben-stien.name (Esben Stien) Date: Tue Oct 11 18:18:41 2005 Subject: [linux-audio-dev] file format In-Reply-To: <20051010230259.GA4955@linux-1> (fons adriaensen's message of "Tue, 11 Oct 2005 01:02:59 +0200") References: <20051010230259.GA4955@linux-1> Message-ID: <87psqboaiw.fsf@quasar.esben-stien.name> fons adriaensen writes: > Is there any standard file/container format that would provide for > this sort of thing Matroska;) -- 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 musound at jps.net Wed Oct 12 16:05:58 2005 From: musound at jps.net (Sean Bolton) Date: Wed Oct 12 16:04:31 2005 Subject: [linux-audio-dev] [ANN] DSSI 0.9.1 release Message-ID: Announcing the DSSI Soft Synth Interface version 0.9.1 release: http://dssi.sourceforge.net/ DSSI is an audio plugin API for software instruments and effects, based on LADSPA, the ALSA sequencer event types, and OSC (Open Sound Control) communications. This release does _not_ contain any changes to the DSSI API itself, which has been stable now since the 0.4 release fifteen months ago (with minor additions at 0.9). Instead, it contains numerous clarifications to the specification and documentation, and the included reference host and example programs have become significantly more robust. Specific changes in 0.9.1 include: - The distribution now has a full autoconf/automake/libtool build system. - FluidSynth-DSSI has been moved into its own package, and no longer depends upon the FluidSynth source. - The reference host, jack-dssi-host, now supports plugins with audio inputs, as well as LADSPA-only plugins (with or without custom DSSI GUIs.) Available hosts and plugins --------------------------- More exciting than the changes in this release, is the recent growth in DSSI implementations. Items marked with '*' are new since the DSSI 0.9 release. Available hosts are: - jack-dssi-host, included in the DSSI distribution - the Rosegarden 4 sequencer * Om, a modular synthesizer * ghostess, a lightweight GTK+ host * dssi~, a Pure Data external Efforts are underway to add DSSI hosting to: - the MusE sequencer * Csound5 * GNU Classpath Available plugins include: - the simple synths and sampler in the DSSI distribution - FluidSynth-DSSI, a soundfont-playing plugin - Xsynth-DSSI, an analog-style synth - dssi-vst, a wrapper plugin enabling the use of many Windows VST plugins - hexter, a Yamaha DX7 modeling plugin * ll-scope, an oscilliscope plugin * Sineshaper, a waveshaping soft synth * dssi_convolve, a DSSI wrapper around libconvolve * xy-controller-dssi, a GUI controller plugin which translates mouse input into X-Y control outputs * WhySynth, which offers a number of synthesis methods The Future ---------- In the year and a half since its initial introduction, DSSI has met a number of challenges to its adoption: the continued (perpetual?) forthcomingness of GMPI, apprehension about adopting a standard with 'Disposable' in its name, some "wait and see if takes off" attitude, and numerous gripes that it won't do this or can't do that. Even so, the creative potential available through DSSI today is great. In part due to this success, there has been a noticable commitment voiced in recent discussions on the DSSI email list to keeping any future enhancements backward-compatible with the existing DSSI API. In the author's opinion, this indicates DSSI will continue to be a stable API, at least until such time as a '2.0' version is considered. With regard to possible future enhancements, interest has been highest in two areas: providing plugins with transport position and tempo information, and allowing plugins to send MIDI data. If you're interested in helping shape these or other developments, please join us on the DSSI discussion list. From larsl at users.sourceforge.net Wed Oct 12 16:23:28 2005 From: larsl at users.sourceforge.net (Lars Luthman) Date: Wed Oct 12 16:22:45 2005 Subject: [linux-audio-dev] [ANN] DSSI 0.9.1 release In-Reply-To: References: Message-ID: <1129148608.8708.3.camel@c213-100-50-8.swipnet.se> On Wed, 2005-10-12 at 13:05 -0700, Sean Bolton wrote: > Announcing the DSSI Soft Synth Interface version 0.9.1 release: > > [...] > > Available plugins include: > [...] > * Sineshaper, a waveshaping soft synth I'd like to point out that this plugin is not officially released yet, it is still in development and may not be compatible with any future versions (number of ports, MIDI mappings, programs, anything can change). -- Lars Luthman PGP key: http://www.d.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- 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/20051012/b3c4e793/attachment.bin From xaero at inwind.it Thu Oct 13 17:27:39 2005 From: xaero at inwind.it (federico) Date: Thu Oct 13 17:29:07 2005 Subject: [linux-audio-dev] Re: [linux-audio-user] Smack 0.2 released. In-Reply-To: <434EC1EB.4040503@inwind.it> References: <434EC1EB.4040503@inwind.it> Message-ID: <434ED14B.7020108@inwind.it> federico ha scritto: > Loki Davison ha scritto: > >> Hi all, >> Smack 0.2 is now out. Smack is a drum synth, 100% sample free. It's >> built with LADSPA plugins and the Om modular synth. New in this >> release are Noise and resonate filter based metallic percussion, ring >> modulation based drums, velocity sensitivity, control ports for all >> drums and random other goodness. Get it at http://smack.berlios.de/ >> There are also some new sound demos on the site including a physical >> modeling based djembe. The gui is no longer included due to huge >> improvements with om_gtk, and lack of time for maintaining it. Please >> just use om_gtk or the emacs bindings. >> >> Cheers, >> Loki >> >> >> >> > i got this error trying to load some of your patches: > > ERROR: Unable to make connection > /808kit/808hihat/midi_trigger_in0/Gate -> > /808kit/808hihat/adenv_lvl_0/Reset Level > ERROR: Unable to make connection > /808kit/808hihat/midi_trigger_in1/Gate -> > /808kit/808hihat/adenv_lvl_1/Reset Level > ERROR: Unable to make connection /808kit/808hihat/OH gate/in -> > /808kit/808hihat/adenv_lvl_0/Reset Level > ERROR: Unable to make connection /808kit/808hihat/CH gate/in -> > /808kit/808hihat/adenv_lvl_1/Reset Level > ERROR: Unable to make connection /909bass/midi_trigger_in0/Trigger -> > /909bass/adenv_lvl_0/Reset Level > ok i solved the errors above by installing omins-cvs. but still hear no sound. i lift up all volume slider, twiddled with sliders, checked that all the output are connected to a soundcard output, and checked that for midi connections too. there aren't any error message in the om console and in the om_gtk console, except (om_gtk:21016): Gtk-CRITICAL **: gtk_range_set_range: assertion `min < max' failed, but everything seems to work fine, except for the audio :| > i see the audio outputs and the alsa input (triggers), i send midi > notes to them, but it doesn't output any sound. > > can you help me? > From cpolymeris at gmx.net Fri Oct 14 01:44:16 2005 From: cpolymeris at gmx.net (cpolymeris@gmx.net) Date: Fri Oct 14 01:44:26 2005 Subject: [linux-audio-dev] Fixed vs. floating point Message-ID: <9240.1129268656@www25.gmx.net> I am in the early planning stage of an audio processing application and I have come to the point of making the choice between floating point or fixed point (signed 2's complement) processing. What do you think is better, and why? Why does jack use floating point? Why does AES use fixed point in most of their standards? I understand the technical difference between the formats, but... I can't come to a conclussion. The adavantages of floating point I see are: - easier processing, specially amplification and mixing (multiplying by fractions) - more sse support, more packed array arithmetics - relationship to voltage and SPL easier to understand. (1.0f vs. 2^31-1 max. values) And its diadvantages compared to fixed point would be: - generally slower, specially things like addition - 30 bits of resolution for 32 bits of data in IEEE single-precision (exponents larger than 0 not used for audio, neither are denormalized numbers and redundant zeroes, infinities, etc), compared to the full 32 bits of resolution of fixed point. - non-linear saw-tooth-like precission (precission gets higher as mantissa gets larger and then falls abruptly at the point the exponent is increased) I am sure I fail to see the more important points and would be thankful for any comments. If it has been discussed on the list earlier, i am sorry to post it again. I couldn't find it. Greetigs, Dimitri -- NEU: Telefon-Flatrate fürs dt. Festnetz! GMX Phone_Flat: 9,99 Euro/Mon.* Für DSL-Nutzer. Ohne Providerwechsel! http://www.gmx.net/de/go/telefonie From iainduncan at telus.net Fri Oct 14 03:11:59 2005 From: iainduncan at telus.net (Iain Duncan) Date: Fri Oct 14 03:13:04 2005 Subject: [linux-audio-dev] Help on csound real time front end project? Message-ID: <434F5A3F.7020604@telus.net> Wondering if anyone on hear is interested in working with me on my c/c++ front end for real time improvisation using csound5 as the audio engine. The concept in a nutshell is like a cross between say Doepfer step sequencers ( or Softwerk ) and Ableton live, except multi user and designed for speed and improvisation and a more musician oriented way of thinking. Proof of concept has been done and used on gigs, now it is time to do it properly in C/C++. I think my c/c++/fltk/midi/csound api chops are up to the point now of making a usable framework that will be useable for a serious sequencer, but I am definitely more of a designer then experieced coder, so it would be great to collaborate. if there is interest I can start a list and site for this. Feel free to contact me here or off list. Thanks Iain From georg.holzmann at student.kug.ac.at Fri Oct 14 03:45:09 2005 From: georg.holzmann at student.kug.ac.at (Georg Holzmann) Date: Fri Oct 14 03:44:51 2005 Subject: [linux-audio-dev] Fixed vs. floating point In-Reply-To: <9240.1129268656@www25.gmx.net> References: <9240.1129268656@www25.gmx.net> Message-ID: <434F6205.2000500@student.kug.ac.at> Hallo! > I am in the early planning stage of an audio processing application and I > have come to the point of making the choice between floating point or fixed > point (signed 2's complement) processing. > What do you think is better, and why? Why does jack use floating point? Why it depends of course on the hardware: if you write e.g. your application for PDAs or Mobile Phones, then you will have to use fixed point (at least for now) ... LG Georg From hannu at opensound.com Fri Oct 14 04:37:30 2005 From: hannu at opensound.com (Hannu Savolainen) Date: Fri Oct 14 04:40:41 2005 Subject: [linux-audio-dev] Fixed vs. floating point In-Reply-To: <9240.1129268656@www25.gmx.net> References: <9240.1129268656@www25.gmx.net> Message-ID: On Fri, 14 Oct 2005 cpolymeris@gmx.net wrote: > I am in the early planning stage of an audio processing application and I > have come to the point of making the choice between floating point or fixed > point (signed 2's complement) processing. > What do you think is better, and why? Why does jack use floating point? Why > does AES use fixed point in most of their standards? Fixed point is ideal format for transferring audio data between devices/systems/applications (for many reasons). However there are some serious problems when using fixed point as the internal format inside the applications. For example if you divide a sample by a large enough value the result will be zero (total loss of precision). Equally well if you multiply it by a large number there will be an overflow. This means that a programmer using fixed point needs to keep thinking about precision and overflows all the time. This may require much more hacking energy than developing the algorithms. In particular debugging will be pain. Floating point in turn has 24 bits of precision which is enough for audio. The exponent part takes care of scaling while the mantissa stays always normalized to the full 24 bit precision. In fact 64 bit precision is used for computations and intermediate results inside the FPU (x86 at least). In this way the programmer doesn't need to think about the precision (in most cases). This is the main reason why many audio applications use floating point internally. However many (or most) applications do just simple computations which are easy to do in fixed point too. Hint: Scale the input samples to the -1.0..1.0 range regardless of the input precision (8/16/24). Scale samples to the desired output format just before writing them to the device or to a file. This will make your life much easier. Best regards, Hannu ----- Hannu Savolainen (hannu@opensound.com) http://www.opensound.com (Open Sound System (OSS)) http://www.compusonic.fi (Finnish OSS pages) OH2GLH QTH: Karkkila, Finland LOC: KP20CM From S.W.Harris at ecs.soton.ac.uk Fri Oct 14 05:34:30 2005 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Fri Oct 14 05:34:40 2005 Subject: [linux-audio-dev] Fixed vs. floating point In-Reply-To: References: <9240.1129268656@www25.gmx.net> Message-ID: <20051014093430.GE31389@login.ecs.soton.ac.uk> On Fri, Oct 14, 2005 at 11:37:30AM +0300, Hannu Savolainen wrote: > Floating point in turn has 24 bits of precision which is enough for audio. > The exponent part takes care of scaling while the mantissa stays always > normalized to the full 24 bit precision. In fact 64 bit precision is used > for computations and intermediate results inside the FPU (x86 at least). > In this way the programmer doesn't need to think about the precision (in > most cases). Pedantic geekiness warning Actually there are 25 fixed-point equivalent bits of precision, due to the implicit 1. Its not much difference, but sometimes it matters. - Steve From tim at quitte.de Fri Oct 14 06:26:09 2005 From: tim at quitte.de (Tim Goetze) Date: Fri Oct 14 06:26:42 2005 Subject: [linux-audio-dev] Fixed vs. floating point In-Reply-To: References: <9240.1129268656@www25.gmx.net> Message-ID: [Hannu Savolainen] >This is the main reason why many audio applications use floating point >internally. However many (or most) applications do just simple >computations which are easy to do in fixed point too. > >Hint: Scale the input samples to the -1.0..1.0 range regardless of the >input precision (8/16/24). Scale samples to the desired output format just >before writing them to the device or to a file. This >will make your life much easier. i'd like to add that due to quantization, signal quality can quickly suffer in fixed-point if you do a lot of consecutive calculations on it (not even considering you have to be darn careful not to clip the signal at overflow). a quiet signal, or any signal around zero-crossings, is represented in fixed-point by only a very small number of bits -- two simple multiplications can lead to end results varying greatly from the ideal (infinite precision) result. if the signal level is low and the end user raises the final gain to compensate, the results can be quite disastrous. for example, implementing an iir filter of only medium complexity (in fact, anything more complex than a biquad) in fixed-point requires jumping through a lot of hoops (decomposition into a chain of biquads, usually). in floating-point, simply implement the filter loop and history in doubles if the filter gets complex, and you're done -- without slowing down execution substantially (on x86 at least). as long as your target platforms support it with reasonable processing speed, choose floating point. cheers, tim From indigo at bitglue.com Fri Oct 14 07:29:16 2005 From: indigo at bitglue.com (Phil Frost) Date: Fri Oct 14 07:29:26 2005 Subject: [linux-audio-dev] Fixed vs. floating point In-Reply-To: <9240.1129268656@www25.gmx.net> References: <9240.1129268656@www25.gmx.net> Message-ID: <20051014112916.GA18892@unununium.org> On Fri, Oct 14, 2005 at 07:44:16AM +0200, cpolymeris@gmx.net wrote: > I am in the early planning stage of an audio processing application and I > have come to the point of making the choice between floating point or fixed > point (signed 2's complement) processing. > What do you think is better, and why? Why does jack use floating point? Why > does AES use fixed point in most of their standards? > > I understand the technical difference between the formats, but... > I can't come to a conclussion. > The adavantages of floating point I see are: > - easier processing, specially amplification and mixing (multiplying by > fractions) > - more sse support, more packed array arithmetics > - relationship to voltage and SPL easier to understand. (1.0f vs. 2^31-1 > max. values) > > And its diadvantages compared to fixed point would be: > - generally slower, specially things like addition > - 30 bits of resolution for 32 bits of data in IEEE single-precision > (exponents larger than 0 not used for audio, neither are denormalized > numbers and redundant zeroes, infinities, etc), compared to the full 32 bits > of resolution of fixed point. > - non-linear saw-tooth-like precission (precission gets higher as mantissa > gets larger and then falls abruptly at the point the exponent is increased) > > I am sure I fail to see the more important points and would be thankful for > any comments. > > If it has been discussed on the list earlier, i am sorry to post it again. I > couldn't find it. > > Greetigs, Dimitri Many people have reinforced floating point's advantage of dynamic range. However, there are some other things I think are worth mentioning: Although it used to be true that integer arithmetic was much faster than floating-point, this is hardly true anymore. This notion mostly comes from the first x86 cpus that had external x87 co-processors. It was a new thing at the time, and because it was an external unit, it was necessarily slower. Now that the x87 is part of every x86 chip, and everyone plays games and music, floating point performance on intel flavored hardware is quite fast. Beyond the x87, there are also SSE and 3DNow standards that add even better capabilities, although you will need a very good compiler (that is, not gcc) or some manual assembly to take full advantage of them. Also, while integer addition is somewhat simpler than float addition, float multiplication is simpler than integer multiplication, and *far* simpler than float division. The x87 uses an 80 bit floating point format internally, and truncates or rounds to 32 or 64 (80 can be done too, with non-standard C) bit formats when returning the result. However, it's likely one will be using SSE or 3DNow if speed is very important, which use double (64) or single (32) bit formats. The integer counterpart of SSE is MMX, which is included on pretty much everything since the pentium pro. Not only floats can benefit from vector operations. From mlang at delysid.org Fri Oct 14 11:01:42 2005 From: mlang at delysid.org (Mario Lang) Date: Fri Oct 14 11:01:45 2005 Subject: [linux-audio-dev] file format In-Reply-To: <20051010230259.GA4955@linux-1> (fons adriaensen's message of "Tue, 11 Oct 2005 01:02:59 +0200") References: <20051010230259.GA4955@linux-1> Message-ID: <8764s0uoq1.fsf@lexx.delysid.org> fons adriaensen writes: > The alternative is of course to have separate WAV files and some > text file for the metadata, and combine all of this into a directory > that would then be handled as a unit. But I'd prefer to have all > data in a single file. WHen I read that sentence, I had to think about Debian packages... Ever considered using ar? This way you have one file, no need to craft any really complicated file format, and your data can be manipulated using standard tools! Read man deb on a debian system for inspiration. An rfc822 style control file could contain your metadata and just reference the other files in the archive. Or you could use XML if you are of the bloaty type :-) -- CYa, Mario From mlang at delysid.org Fri Oct 14 11:08:06 2005 From: mlang at delysid.org (Mario Lang) Date: Fri Oct 14 11:08:21 2005 Subject: [linux-audio-dev] file format In-Reply-To: <20051011115117.GB1659@bth05w.ABSp.alcatel.be> (Alfons Adriaensen's message of "Tue, 11 Oct 2005 13:51:18 +0200") References: <20051010230259.GA4955@linux-1> <1128989302.12415.84.camel@dhin> <20051011091222.GB20721@login.ecs.soton.ac.uk> <20051011115117.GB1659@bth05w.ABSp.alcatel.be> Message-ID: <871x2ouofd.fsf@lexx.delysid.org> Alfons Adriaensen writes: > On Tue, Oct 11, 2005 at 10:12:22AM +0100, Steve Harris wrote: > >> On Mon, Oct 10, 2005 at 08:08:22 -0400, Paul Davis wrote: >> > On Tue, 2005-10-11 at 01:02 +0200, fons adriaensen wrote: >> > > The alternative is of course to have separate WAV files and some >> > > text file for the metadata, and combine all of this into a directory >> > > that would then be handled as a unit. But I'd prefer to have all >> > > data in a single file. >> > >> > tar? (paul runs for cover ...) >> >> Actually a zip file plus manifest (aka jar or mozilla xpi) is an ok >> solution, they can be "mounted" by the application and have files pulled >> out, whereas tar files have to be unpacked to /tmp or similar. > > Reading tar files directly is easy enough - emacs does it for example. > Any libs for jar / xpi ? My main objection to both would probably be that > it's just a bit too easy to create them using 'general' tools only. > I want to avoid incompatible parts being put together accidentally. > That's also the main reason for preferring a single file over a directory. I dont think you really need worry about accidental errors. Just make the actual format used obscure enough for the average user... I know that .deb packages can be built/extracted using ar since years, but I never really did it if not necessary since the tools available for doing it the proper way are sufficient :-) However, its just cool if you happen to end up in a situation where you need some bits of the data in one of your files, but for some reason or another dont have your application handy on the machine right now. -- CYa, Mario From cpolymeris at gmx.net Fri Oct 14 15:00:37 2005 From: cpolymeris at gmx.net (cpolymeris@gmx.net) Date: Fri Oct 14 14:57:47 2005 Subject: [linux-audio-dev] Fixed vs. floating point References: Message-ID: <2725.1129316437@www43.gmx.net> > For example if you divide a sample by a large enough value the result > will be zero (total loss of precision). Equally well if you multiply it by > a large number there will be an overflow. This means that a programmer > using fixed point needs to keep thinking about precision and overflows > all the time. This may require much more hacking energy than developing > the algorithms. In particular debugging will be pain. > > Floating point in turn has 24 bits of precision which is enough for audio. > The exponent part takes care of scaling while the mantissa stays always > normalized to the full 24 bit precision. In fact 64 bit precision is used > for computations and intermediate results inside the FPU (x86 at least). > In this way the programmer doesn't need to think about the precision (in > most cases). > First of all, thank you all very much for you comments, the picture is much clearer now. I just don't fully understand the floating-point precission part. If numbers from binary 0.1 to 1.0 are represented using 24 bits (sign bit + mantissa, I think the implicit 1 does not count), and the numbers from binary 0.01 to 0.1 also have 24 bits of precision, and so on for 0.001..0.01, etc. wouldn't that mean we have a higher resolution? We are using 7 of 8 exponent bits too. Just wasting the cases where the exponent is larger than 0, or has some special meaning.) That would give you 31 bits, minus a couple useless and redundant cases. (when the exponent is -128, and denormalizing ocurrs) Then I also fail to see why it's bad for overflows to ocurr in fixed point. Those signals (above 0dB FS) would clip on the hardware anyway, and are expected to do so, since they were either badly recorded or amplified. Greetings, Dimitri -- Highspeed-Freiheit. Bei GMX supergünstig, z.B. GMX DSL_Cityflat, DSL-Flatrate für nur 4,99 Euro/Monat* http://www.gmx.net/de/go/dsl From sjenkins at blueyonder.co.uk Fri Oct 14 15:45:30 2005 From: sjenkins at blueyonder.co.uk (Simon Jenkins) Date: Fri Oct 14 15:45:34 2005 Subject: [linux-audio-dev] Fixed vs. floating point In-Reply-To: <2725.1129316437@www43.gmx.net> References: <2725.1129316437@www43.gmx.net> Message-ID: <1129319130.7955.60.camel@localhost.localdomain> On Fri, 2005-10-14 at 21:00 +0200, cpolymeris@gmx.net wrote: > [...]If numbers > from binary 0.1 to 1.0 are represented using 24 bits (sign bit + mantissa, I > think the implicit 1 does not count) You could represent numbers to 1 bit of precision using a zero bit mantissa (ie exponent only) format. So the implicit 1 definitely does count. Simon. From indigo at bitglue.com Fri Oct 14 16:28:55 2005 From: indigo at bitglue.com (Phil Frost) Date: Fri Oct 14 16:29:03 2005 Subject: [linux-audio-dev] Fixed vs. floating point In-Reply-To: <2725.1129316437@www43.gmx.net> References: <2725.1129316437@www43.gmx.net> Message-ID: <20051014202855.GA7423@unununium.org> On Fri, Oct 14, 2005 at 09:00:37PM +0200, cpolymeris@gmx.net wrote: > First of all, thank you all very much for you comments, the picture is much > clearer now. > > I just don't fully understand the floating-point precission part. If numbers > from binary 0.1 to 1.0 are represented using 24 bits (sign bit + mantissa, I > think the implicit 1 does not count), and the numbers from binary 0.01 to > 0.1 also have 24 bits of precision, and so on for 0.001..0.01, etc. wouldn't > that mean we have a higher resolution? > We are using 7 of 8 exponent bits too. Just wasting the cases where the > exponent is larger than 0, or has some special meaning.) > That would give you 31 bits, minus a couple useless and redundant cases. > (when the exponent is -128, and denormalizing ocurrs) > > Then I also fail to see why it's bad for overflows to ocurr in fixed point. > Those signals (above 0dB FS) would clip on the hardware anyway, and are > expected to do so, since they were either badly recorded or amplified. > > Greetings, Dimitri Obviously, too strong a signal will clip. This of course requires calculations to check for overflow. More likely, such checks will be too slow, so overflow will result in the value "wrapping around", that is, maxint + 1 => minint. This of course sounds really, really bad. Less obviously, too weak a signal will also distort. If the signal is in the range [-6, 5] then there are only 10 discrete values a sample may have, and your signal will sound like it's being played through your PC beeper with a pencil stuck through the cone. Also, any DC offset will indirectly make fewer values available, resulting in either clipping, or lack of precision. These problems don't seem so bad if only the output is considered, but in any audio processing pipeline, there are many more signal paths that must be considered. Imagine all the different signal paths in a filter. It is possible to avoid the mentioned problems using fixed point arithmetic where the "point" is fixed at a different place depending on the expected signal level. However, it's not much fun, and I very much doubt it is significantly faster. By using floating point, you gaurantee that the biggest step between two consecutive values is somewhere between 1/2^23 and 1/2^24th of your signal range (provided you don't run up against the limits of floating point, which is hard to do). Of course there are smaller steps between consecutive values as values approach 0; this is what makes floating-point desirable. In other words, you do have more than 2^24 values available to you, but the worst case difference between consecutive values is never much worse than if you had exactly 2^24 values. From fons.adriaensen at skynet.be Fri Oct 14 16:57:50 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Fri Oct 14 16:53:06 2005 Subject: [linux-audio-dev] Fixed vs. floating point In-Reply-To: <2725.1129316437@www43.gmx.net> References: <2725.1129316437@www43.gmx.net> Message-ID: <20051014205750.GA5017@linux-1> On Fri, Oct 14, 2005 at 09:00:37PM +0200, cpolymeris@gmx.net wrote: > I just don't fully understand the floating-point precission part. If numbers > from binary 0.1 to 1.0 are represented using 24 bits (sign bit + mantissa, I > think the implicit 1 does not count), It does. > and the numbers from binary 0.01 to > 0.1 also have 24 bits of precision, and so on for 0.001..0.01, etc. wouldn't > that mean we have a higher resolution? Only for small signal values, so not really. Don't assume that small signals are centered around zero - they usually are not. Using floating point only means you have to worry less about absolute levels during the processing. > Then I also fail to see why it's bad for overflows to ocurr in fixed point. > Those signals (above 0dB FS) would clip on the hardware anyway, and are > expected to do so, since they were either badly recorded or amplified. They may be clipped on the hardware IFF you give the hardware more bits than it actually uses, otherwise the hardware just can't know if they have to be clipped or not. But normally you just can't do that, so don't count on automatic clipping. Worse, unless you are using some specialised DSP chips that can do clipping in the ALU, implementing clipping in fixed point software usually leads to an immense waste of processing power. And if you use fixed point and do not have any provision for clipping, then any overflows will result in very high amplitude spikes that are really excellent for destroying your speakers, in particar the HF parts. The bottom line is really quite simple: if your app is to run on a PC, use floats. There are some very good reasons why floats were chosen as JACK's default audio type. On the other hand, don't count on FP or even double precision to make for example marginally stable IIR filters stable. Sometimes it works. Sometimes it appears to work but your filter (or rather your speakers) may still explode for some inputs. -- FA From Dr.Graef at t-online.de Fri Oct 14 17:29:19 2005 From: Dr.Graef at t-online.de (Albert Graef) Date: Fri Oct 14 17:26:07 2005 Subject: [linux-audio-dev] Fixed vs. floating point In-Reply-To: <20051014205750.GA5017@linux-1> References: <2725.1129316437@www43.gmx.net> <20051014205750.GA5017@linux-1> Message-ID: <4350232F.2010600@t-online.de> fons adriaensen wrote: > The bottom line is really quite simple: if your app is to run on a PC, use floats. > There are some very good reasons why floats were chosen as JACK's default audio > type. I agree with that conclusion. Just don't forget about the denormals issue on Intel (has this been mentioned in this thread before?). However, it's easy to work around this by adding a small amount of noise where necessary. -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef@t-online.de, ag@muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikwissenschaft.uni-mainz.de/~ag From aidan at nicta.com.au Fri Oct 14 19:14:47 2005 From: aidan at nicta.com.au (Aidan Williams) Date: Fri Oct 14 19:14:53 2005 Subject: [linux-audio-dev] Fixed vs. floating point In-Reply-To: <20051014093430.GE31389@login.ecs.soton.ac.uk> References: <9240.1129268656@www25.gmx.net> <20051014093430.GE31389@login.ecs.soton.ac.uk> Message-ID: <43503BE7.20709@nicta.com.au> Steve Harris wrote: > Pedantic geekiness warning > :-) Nice to have a helpful pedant around.. Thanks, aidan ____ :wq! From mark at filigreemusic.com Fri Oct 14 22:11:40 2005 From: mark at filigreemusic.com (Mark Stewart) Date: Fri Oct 14 22:11:40 2005 Subject: [linux-audio-dev] Fixed vs. floating point In-Reply-To: <9240.1129268656@www25.gmx.net> References: <9240.1129268656@www25.gmx.net> Message-ID: <0279EB76-944A-47B2-8B5F-CFFA9C12DAFB@filigreemusic.com> On 14-Oct-05, at 1:44 AM, cpolymeris@gmx.net wrote: > I am in the early planning stage of an audio processing application > and I > have come to the point of making the choice between floating point > or fixed > point (signed 2's complement) processing. > What do you think is better, and why? Why does jack use floating > point? Why > does AES use fixed point in most of their standards? > Here's some papers specifically geared toward DSP processors that support the use of fixed point: Superior Audio Requires Fixed-Point DSP http://www.rane.com/note153.html 48-Bit Integer Processing Beats 32-Bit Floating-Point for Professional Audio Applications http://www.jamminpower.com/main/articles.jsp -Mark From jens.andreasen at chello.se Sat Oct 15 02:34:10 2005 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Sat Oct 15 02:34:13 2005 Subject: [linux-audio-dev] Fixed vs. floating point In-Reply-To: <2725.1129316437@www43.gmx.net> References: <2725.1129316437@www43.gmx.net> Message-ID: <1129358050.10201.285.camel@c80-216-125-193.cm-upc.chello.se> On Fri, 2005-10-14 at 21:00 +0200, cpolymeris@gmx.net wrote: > Then I also fail to see why it's bad for overflows to ocurr in fixed point. > Those signals (above 0dB FS) would clip on the hardware anyway, and are > expected to do so, since they were either badly recorded or amplified. > In a hardware scenario you would typically have a chain of; gain (16bit), channel-fader, group-fader, master-fader (16bit) Once sorted out, you will multiply all the virtual faders before applying the result to the signal. So far all is well. There is only a single fixed mutiply of the signal. In the hardware scenario we also have an "insert" jack for external fx. The fx-chain will have its own gain and out levels for each element in the chain, and this is where the problem arises. There is no way for us to know the internals of the arbitrary plug-ins. Floats to the rescue: By converting the signal from int to float, we will gain a seemingly *almost infinite dynamic range*. Is this important then? Yes, because the intermediate results in the chain can very easily be out of bounds, while the final result is well-behaved and within bounds. Practical examples? Oh yes, electric guitarists will chain just about as much as they can afford (only joking ...) But yes, I do quite a few "room in a room" simulations where one reverb is feeding the next reverb. It is surprising how the buildup of the first can resonate and distort the second. mvh // Jens M Andreasen > Greetings, Dimitri > -- From jens.andreasen at chello.se Sat Oct 15 03:34:25 2005 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Sat Oct 15 03:34:30 2005 Subject: [linux-audio-dev] Fixed vs. floating point In-Reply-To: <20051014093430.GE31389@login.ecs.soton.ac.uk> References: <9240.1129268656@www25.gmx.net> <20051014093430.GE31389@login.ecs.soton.ac.uk> Message-ID: <1129361665.10201.293.camel@c80-216-125-193.cm-upc.chello.se> On Fri, 2005-10-14 at 10:34 +0100, Steve Harris wrote: > On Fri, Oct 14, 2005 at 11:37:30AM +0300, Hannu Savolainen wrote: > > Floating point in turn has 24 bits of precision which is enough for audio. > > The exponent part takes care of scaling while the mantissa stays always > > normalized to the full 24 bit precision. In fact 64 bit precision is used > > for computations and intermediate results inside the FPU (x86 at least). > > In this way the programmer doesn't need to think about the precision (in > > most cases). > > Pedantic geekiness warning > > Actually there are 25 fixed-point equivalent bits of precision, due to the > implicit 1. Its not much difference, but sometimes it matters. > With so many experts around, it would be nice to have a small, effecient 16bit -> float, as well as a float -> 16bit (uhm, right, Intel hardware will do this for you, but say you are someahere else) > - Steve -- From jens.andreasen at chello.se Sat Oct 15 21:33:56 2005 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Sat Oct 15 21:34:03 2005 Subject: [linux-audio-dev] Fixed vs. floating point In-Reply-To: <20051014205750.GA5017@linux-1> References: <2725.1129316437@www43.gmx.net> <20051014205750.GA5017@linux-1> Message-ID: <1129426437.10201.325.camel@c80-216-125-193.cm-upc.chello.se> On Fri, 2005-10-14 at 22:57 +0200, fons adriaensen wrote: > ... ... Worse, unless you are using some specialised DSP chips that can do > clipping in the ALU, implementing clipping in fixed point software usually leads > to an immense waste of processing power. The hardware need not be that specialized. Both mmx and altivec implements 16bit saturating add and sub. Signed as well as unsigned. From jens.andreasen at chello.se Sat Oct 15 22:39:27 2005 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Sat Oct 15 22:39:38 2005 Subject: [linux-audio-dev] Fixed vs. floating point In-Reply-To: <4350232F.2010600@t-online.de> References: <2725.1129316437@www43.gmx.net> <20051014205750.GA5017@linux-1> <4350232F.2010600@t-online.de> Message-ID: <1129430367.10201.334.camel@c80-216-125-193.cm-upc.chello.se> On Fri, 2005-10-14 at 23:29 +0200, Albert Graef wrote: > fons adriaensen wrote: > > The bottom line is really quite simple: if your app is to run on a PC, use floats. > > There are some very good reasons why floats were chosen as JACK's default audio > > type. > > I agree with that conclusion. Just don't forget about the denormals > issue on Intel (has this been mentioned in this thread before?). > However, it's easy to work around this by adding a small amount of noise > where necessary. > As an alternative you could also turn denormal handling off and flush to zero. #include #define _MM_DENORM_ZERO_ON 0x0040 // Enable zeroing out denormal. _mm_setcsr(_MM_FLUSH_ZERO_ON | _MM_MASK_UNDERFLOW | _mm_getcsr()); // Now, enable treating denormal as zero. _mm_setcsr(_MM_DENORM_ZERO_ON | _mm_getcsr()); gcc -msse -mfpmath=sse From paulgfx at yahoo.com Sun Oct 16 07:47:21 2005 From: paulgfx at yahoo.com (Paul) Date: Sun Oct 16 07:47:24 2005 Subject: [linux-audio-dev] Documentation of the PADsynth synthesis algorithm Message-ID: <20051016114721.59007.qmail@web52211.mail.yahoo.com> Hi. I am Paul, the author of ZynAddSubFX software synthesizer. I wrote a complete documentation of how the PADsynth synthesis algorithm works. It includes the full description of the algorithm: overview, text description, diagrams, pseudocode; example C/C++ implementations and a ready-to-use C++ class. Also, I included some audio examples into the page. Please tell me your opinion about it. I tried to make it to be easy understood and ready to be implemented and/or used into your software synthesizers. Everything (the algorithm, the examples, the implementations, diagrams,etc) from this page are released under Public Domain. You are welcome to include and use this into your programs and I invite the companies/developers who write software synthesizers to use it. Also, I guess that the sound banks producers will be very interesed about this ;) I don't require anything for using it ;-) ; I just want this to be spread, to be used to make beautiful sounds. It's page is at: http://zynaddsubfx.sourceforge.net/doc/PADsynth/PADsynth.htm Enjoy! Paul __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From sonicx_ at gmx.net Sun Oct 16 11:05:30 2005 From: sonicx_ at gmx.net (sonicx) Date: Sun Oct 16 09:06:49 2005 Subject: [linux-audio-dev] making kjaaa outof jaaa,some help needed. In-Reply-To: <20051016114721.59007.qmail@web52211.mail.yahoo.com> References: <20051016114721.59007.qmail@web52211.mail.yahoo.com> Message-ID: <43526C3A.6060802@gmx.net> heyho! i am trying to recode an x-app , jaaa, a analyzation tool for alsa and jack, for kde. kjaaa so to say. but as this is my first windowed proggi i was wondering about the handling of events. it seems that my raw x-app has in its "importantwindow.cpp" all funktions needed to handle X-send events. but i want to use those that come with the q-designer ui`s-that would be soo cool =). so well i thought kde just has all this coded in,so i can just use all those widget funktions doing the eventhandling??? mfg sonicx From kjetil at ccrma.stanford.edu Sun Oct 16 12:59:46 2005 From: kjetil at ccrma.stanford.edu (Kjetil S. Matheussen) Date: Sun Oct 16 12:59:51 2005 Subject: [linux-audio-dev] Documentation of the PADsynth synthesis algorithm In-Reply-To: <200510161602.j9GG2Gsq000418@roar.music.columbia.edu> References: <200510161602.j9GG2Gsq000418@roar.music.columbia.edu> Message-ID: Paul: > Hi. > I am Paul, the author of ZynAddSubFX software > synthesizer. > I wrote a complete documentation of how the PADsynth > synthesis algorithm works. It includes the full > description of the algorithm: overview, text > description, diagrams, pseudocode; example C/C++ > implementations and a ready-to-use C++ class. > > Also, I included some audio examples into the page. > Please tell me your opinion about it. Wow, this is great work! Especially this one is so impressive: http://zynaddsubfx.sourceforge.net/doc/PADsynth/demos/0km.ogg -- From arnold.krille at gmail.com Sun Oct 16 15:13:59 2005 From: arnold.krille at gmail.com (Arnold Krille) Date: Sun Oct 16 15:14:03 2005 Subject: [linux-audio-dev] Re: making kjaaa outof jaaa,some help needed. In-Reply-To: <43526C3A.6060802@gmx.net> References: <20051016114721.59007.qmail@web52211.mail.yahoo.com> <43526C3A.6060802@gmx.net> Message-ID: <2def88b80510161213k1bb54551s@mail.gmail.com> On 10/16/05, sonicx wrote: > i am trying to recode an x-app , jaaa, a analyzation tool for alsa and > jack, for kde. kjaaa so to say. but as this is my first windowed proggi > i was wondering about the handling of events. it seems that my raw x-app > has in its "importantwindow.cpp" all funktions needed to handle X-send > events. but i want to use those that come with the q-designer ui`s-that > would be soo cool =). so well i thought kde just has all this coded > in,so i can just use all those widget funktions doing the eventhandling??? If it is your first Qt/KDE/graphical-programming experience, please don't start with an app like jaaa (*) where the author is not so well with speaking about other gui-systems (afaik). Arnold (*) I would like to see jaaa/japa/aeolus get an even nicer gui! But the current one works and doesn't look ugly, so... -- 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 fons.adriaensen at skynet.be Sun Oct 16 15:23:46 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Sun Oct 16 15:19:02 2005 Subject: [linux-audio-dev] making kjaaa outof jaaa,some help needed. In-Reply-To: <43526C3A.6060802@gmx.net> References: <20051016114721.59007.qmail@web52211.mail.yahoo.com> <43526C3A.6060802@gmx.net> Message-ID: <20051016192346.GA4743@linux-1> On Sun, Oct 16, 2005 at 03:05:30PM +0000, sonicx wrote: > i am trying to recode an x-app , jaaa, a analyzation tool for alsa and > jack, for kde. As the author of JAAA, I have two remarks. First, JAAA works perfectly well under KDE AFAIK, so I wonder what's the point. Anyway, applications designed for a particular desktop, be it KDE, Gnome or whatever, are IMHO just broken. Second, the version you are working with will be replaced by a completely new one in a month or two. -- FA From fons.adriaensen at skynet.be Sun Oct 16 15:53:11 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Sun Oct 16 15:48:29 2005 Subject: [linux-audio-dev] Re: making kjaaa outof jaaa,some help needed. In-Reply-To: <2def88b80510161213k1bb54551s@mail.gmail.com> References: <20051016114721.59007.qmail@web52211.mail.yahoo.com> <43526C3A.6060802@gmx.net> <2def88b80510161213k1bb54551s@mail.gmail.com> Message-ID: <20051016195311.GB4743@linux-1> On Sun, Oct 16, 2005 at 09:13:59PM +0200, Arnold Krille wrote: > If it is your first Qt/KDE/graphical-programming experience, please > don't start with an app like jaaa (*) where the author is not so well > with speaking about other gui-systems (afaik). Since it's GPLed, he can do this. I just will not support it :-) > (*) I would like to see jaaa/japa/aeolus get an even nicer gui! But > the current one works and doesn't look ugly, so... New versions of Jaaa and Aeolus are in the works. You can have a look at the new Aeolus look on my website - it hasn't changed very much, just a bit more color and anti-aliased fonts (but the code itself is almost a complete rewrite). The latest release of JAPA already uses Xft (with an early version of the widget lib, it still has some problems). -- FA From sonicx_ at gmx.net Sun Oct 16 17:51:53 2005 From: sonicx_ at gmx.net (sonicx) Date: Sun Oct 16 15:53:17 2005 Subject: [linux-audio-dev] making kjaaa outof jaaa,some help needed. In-Reply-To: <20051016192346.GA4743@linux-1> References: <20051016114721.59007.qmail@web52211.mail.yahoo.com> <43526C3A.6060802@gmx.net> <20051016192346.GA4743@linux-1> Message-ID: <4352CB79.2040401@gmx.net> hm...well,JAAA didnt work for me-which is quite obvious the reason why i started porting it.that simple. but if a new version is about to come out i ,of course,dont want to interferre with the plans of the maker of JAAA. maybe that new version will run... as mr. adriansen is around anyway maybe he could give me a hint what i might that JAAA wont show up any window,or error regarding this? jaaa could make a lot of things easy for me,so i am quite desperate getting it to work. ah... to bad that all the work was pointless-thought,looking at the last release date of jaaa,itll be sure dead. well,nevermind - maybe there is help needed for the "original" jaaa? mfg sonicx fons adriaensen wrote: >On Sun, Oct 16, 2005 at 03:05:30PM +0000, sonicx wrote: > > > >>i am trying to recode an x-app , jaaa, a analyzation tool for alsa and >>jack, for kde. >> >> > >As the author of JAAA, I have two remarks. First, JAAA works perfectly >well under KDE AFAIK, so I wonder what's the point. Anyway, applications >designed for a particular desktop, be it KDE, Gnome or whatever, are >IMHO just broken. Second, the version you are working with will be >replaced by a completely new one in a month or two. > > > > From larsl at users.sourceforge.net Sun Oct 16 15:56:52 2005 From: larsl at users.sourceforge.net (Lars Luthman) Date: Sun Oct 16 15:56:00 2005 Subject: [linux-audio-dev] making kjaaa outof jaaa,some help needed. In-Reply-To: <43526C3A.6060802@gmx.net> References: <20051016114721.59007.qmail@web52211.mail.yahoo.com> <43526C3A.6060802@gmx.net> Message-ID: <1129492612.8964.1.camel@c213-100-50-8.swipnet.se> Please don't create new threads by replying to other mails on the list (or if you do, make sure that your email client doesn't add the In-Reply-To or References tags). It's very confusing to see completely unrelated threads start in an existing thread, and it can also cause people to miss your messages. -- Lars Luthman PGP key: http://www.d.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- 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/20051016/8d6db69b/attachment.bin From fons.adriaensen at skynet.be Sun Oct 16 16:17:39 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Sun Oct 16 16:17:05 2005 Subject: [linux-audio-dev] making kjaaa outof jaaa,some help needed. In-Reply-To: <4352CB79.2040401@gmx.net> References: <20051016114721.59007.qmail@web52211.mail.yahoo.com> <43526C3A.6060802@gmx.net> <20051016192346.GA4743@linux-1> <4352CB79.2040401@gmx.net> Message-ID: <20051016201739.GC4743@linux-1> On Sun, Oct 16, 2005 at 09:51:53PM +0000, sonicx wrote: > hm...well,JAAA didnt work for me-which is quite obvious the reason why i > started porting it.that simple. but if a new version is about to come > out i ,of course,dont want to interferre with the plans of the maker of > JAAA. It does work here under KDE (and always has) - I keep a KDE login just to test things :-). Please tell me (by private email) which version you have, what distro you are running, how you try to start JAAA (ALSA or JACK), etc. -- FA From arnold.krille at gmail.com Sun Oct 16 16:31:48 2005 From: arnold.krille at gmail.com (Arnold Krille) Date: Sun Oct 16 16:31:52 2005 Subject: [linux-audio-dev] Re: making kjaaa outof jaaa,some help needed. In-Reply-To: <20051016201739.GC4743@linux-1> References: <20051016114721.59007.qmail@web52211.mail.yahoo.com> <43526C3A.6060802@gmx.net> <20051016192346.GA4743@linux-1> <4352CB79.2040401@gmx.net> <20051016201739.GC4743@linux-1> Message-ID: <2def88b80510161331u451b1c8cy@mail.gmail.com> On 10/16/05, fons adriaensen wrote: > On Sun, Oct 16, 2005 at 09:51:53PM +0000, sonicx wrote: > > hm...well,JAAA didnt work for me-which is quite obvious the reason why i > > started porting it.that simple. but if a new version is about to come > > out i ,of course,dont want to interferre with the plans of the maker of > > JAAA. > It does work here under KDE (and always has) - I keep a KDE login just to > test things :-). Please tell me (by private email) which version you have, > what distro you are running, how you try to start JAAA (ALSA or JACK), etc. Same success here: all of fons' apps work just normally in KDE and fluxbox. Since lesser( 'KDE3.2', 'fons' first apps' ); And I don't think its the best solution for a prob if you try to rewrite the app. At least that hasn't ever work for me... 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 mdeboer at iua.upf.es Mon Oct 17 11:34:53 2005 From: mdeboer at iua.upf.es (Maarten de Boer) Date: Mon Oct 17 11:38:49 2005 Subject: [linux-audio-dev] Fixed vs. floating point In-Reply-To: <0279EB76-944A-47B2-8B5F-CFFA9C12DAFB@filigreemusic.com> References: <9240.1129268656@www25.gmx.net> <0279EB76-944A-47B2-8B5F-CFFA9C12DAFB@filigreemusic.com> Message-ID: <20051017173453.1530b417.mdeboer@iua.upf.es> Very interesting reads. Thanks! > Here's some papers specifically geared toward DSP processors that > support the use of fixed point: > > Superior Audio Requires Fixed-Point DSP > http://www.rane.com/note153.html > > 48-Bit Integer Processing Beats 32-Bit Floating-Point for Professional > Audio Applications > http://www.jamminpower.com/main/articles.jsp > > -Mark > > From mrfisher_1 at yahoo.com Mon Oct 17 12:48:10 2005 From: mrfisher_1 at yahoo.com (Mike Fisher) Date: Mon Oct 17 12:48:14 2005 Subject: [linux-audio-dev] Re: [ardour-dev] Proposed editing mode, for users with heavy editing needs In-Reply-To: Message-ID: <20051017164810.6744.qmail@web61023.mail.yahoo.com> Like said before good ideas. One thing that I agree with is to have the playhead snap to the beginning of a region when it is clicked on. This really would speed up the editing process. Maybe something like this could be toggled on or off in the options window. Another thing is in range mode. I'd like to have it so when you select a range that it would play that range just by hitting spacebar or play from the transport. As this would elimiate two mouse clicks. Seems small but it really. Maybe have this in the options window as well. Also in range mode. Move the play head with a single click would save alot of editing time. I know that if you hit p this will happen whereever the mouse is, but just clicking would be alot quicker. I'm not complaining about the existing operations. Ardour is awesome. I just like to be able to make quick edits. And eliminating clicks and keystrokes may not seem like much. But when you make possible hundreds of edits a day, it makes a huge difference in time. --- AES_24_96 wrote: > edit mode > > I propose an edit mode or maybe its a mouse mode > that would > allow editing tasks to be performed with MUCH higher > speed > and quite a few less keystrokes. A similar scheme > has been used > before to create an app with exponentially less > clicks and > keystrokes to perform many editing tasks than any > other. > > In this mode, playback cursor and edit cursor would > be > one and the same, a VERY skinny line that drops, and > stays > wherever you left click the mouse in the edit > window, either > on the ruler or on a region itself. > > Windows type conventions would apply to the > selection process. > Click a region, then shift click another region, and > those two > regions plus any region in between would be > selected. click a > region and control click another region for > selecting non > contiguous regions, and keep control clicking till > you have > selected all the regions you want. Click a fader and > shift click > or control click another fader to move multiple > faders at once. > > Simple stuff, some of which Ardour already has, m to > drop a > marker, s to split, r after making a range selection > to define a > storable range. "g" groups all selected regions > together, > whether on the same track or not, u ungroups > selected regions. > > Let me flesh some of these out a bit. For grouping, > all grouped > tracks would be moved as one of them is, either in > time or > between tracks. As groups overlap each other they > would be > auto-crossfaded where relevant, according to the > already > excellent Ardour autocrossfade options. Very > importantly, > there would be a "overide group" button in the > Ardour menu > bar, to perform actions on regions without bothering > other > regions grouped with them. Turning the button off > would > restore the group action. > > Splits can be made in several ways. Clicking on a > region and > hitting s will split right where the cursor sits. > Clicking in a > trackspace without a region in it, or along the > ruler then hitting > s will split all regions under the cursor. Dragging > a range > along the ruler then hitting s will put a split at > the very > beginning and end of the selected range. Selected > regions, > selected by click shift click and/or click control > click as > described above would also be split by hitting the s > key. > > Region editing would be similar to the way ardour is > now. > Resize by clicking and dragging on edges (would > group with > groups and selections). Control-click and drag on > edges will > time stretch or time compress, also groupable with > groups and > selections. Click dragging on the top edges of > either side will > control the fade in or fade out handle, same as > now. Click > dragging on the very top middle area of a region > would control > a per region volume trim. Right clicking a region > will bring up > a menu including things like reverse region, and > open copy of > region in audio editor. > > Mouse wheel editing would be somewhat different. > With no > modifier, scrolling the wheel will zoom time in and > out, > keeping the zooming centered around the cursor. In > the event > that zooming goes too far to keep centered, it will > go back to > the cursor center upon zooming back in. > > Snapping: Right clicking the "snap to" button brings > up a speed > menu where you can select whether to snap to ruler > marks > ( as defined in the ruler speed menu), time, SMPTE, > measures, half notes, quarter notes, 8th notes, 16th > notes, > 32nd notes, 64th notes and 128th notes). Holding > shift while > dragging a region overrides snapping. The "show > grid" next to > the snapping button will show a grid *VISIBLE > THROUGH > REGIONS* with its points set according to the "snap > to" > speed menu. > > Time display: Somewhere on ardour will be a time > details > screen. Top bar will show the timestamp of the > beginning of a > range selection. In the event of no range selection, > this will > show the timestamp at the cursor. The middle bar > will show > the timestamp at the end of the range selection. The > bottom > bar will show the duration of the range selection. > The main > time display as Ardour has now can be right clicked. > In the > speed menu that pops up, you can select between > SMPTE, > MTC, time(hour, minutes, seconds, miliseconds), > samples, > and musical time( measures, quarter notes, 8th > notes, etc...). > Separately the ruler can also be right clicked to > display the > same options. > > More to come, but I think with these basics ardour > would be > more than workable for those of Linux Noobs us who > have > been abandoned by our parent software company. > > I know it sounds like a lot, but I think this would > certainly > result in many fewer commands to accomplish the same > actions we have now, and actually be simpler to work > with > and use. > > _______________________________________________ > ardour-dev mailing list > ardour-dev@lists.ardour.org > http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org > __________________________________ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/ From paul at linuxaudiosystems.com Mon Oct 17 14:18:52 2005 From: paul at linuxaudiosystems.com (Paul Davis) Date: Mon Oct 17 14:18:27 2005 Subject: [linux-audio-dev] Fixed vs. floating point In-Reply-To: <20051017173453.1530b417.mdeboer@iua.upf.es> References: <9240.1129268656@www25.gmx.net> <0279EB76-944A-47B2-8B5F-CFFA9C12DAFB@filigreemusic.com> <20051017173453.1530b417.mdeboer@iua.upf.es> Message-ID: <1129573132.17169.41.camel@dhin> On Mon, 2005-10-17 at 17:34 +0200, Maarten de Boer wrote: > Very interesting reads. Thanks! > > > > Here's some papers specifically geared toward DSP processors that > > support the use of fixed point: > > > > Superior Audio Requires Fixed-Point DSP > > http://www.rane.com/note153.html what a lame author! he writes near the end: "This is not to say that floating-point DSPs will never have their day in achieving superior audio -- it's just not today. What will it take? Here are some pretty nasty "ifs" necessary for floating-point to overtake fixed-point: if it is a 56-bit floating-point processor (i.e., 48-bit mantissa plus 8-bit exponent) or 32-bit with double-precision (requiring a large accumulator), if the parts run at the same speed as the equivalent fixed-point part, if they use the same power, and if they cost the same, then the choice is made." this was written in 2002, when any FP unit worth mentioning in this context could operate in double or single precision mode. double precision mode vastly exceeds the requirements he mentions here, although i will concede that they may use more power (miniscule amounts in the overall scheme of things). the fact that most audio apps today use single precision FP (32 bit) has as much to do with performance and laziness by authors as with anything else. the technology is there to do 80 bit FP if people want to use it, and some do (Ron Kuper at Cakewalk just did a presentation at AES on Sonar's new 64 bit mode which uses double precision FP IIUC). --p From fons.adriaensen at skynet.be Mon Oct 17 15:58:06 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Mon Oct 17 15:53:28 2005 Subject: [linux-audio-dev] Fixed vs. floating point In-Reply-To: <1129573132.17169.41.camel@dhin> References: <9240.1129268656@www25.gmx.net> <0279EB76-944A-47B2-8B5F-CFFA9C12DAFB@filigreemusic.com> <20051017173453.1530b417.mdeboer@iua.upf.es> <1129573132.17169.41.camel@dhin> Message-ID: <20051017195806.GA5070@linux-1> On Mon, Oct 17, 2005 at 02:18:52PM -0400, Paul Davis wrote: > > > Here's some papers specifically geared toward DSP processors that > > > support the use of fixed point: > > > > > > Superior Audio Requires Fixed-Point DSP > > > http://www.rane.com/note153.html > > what a lame author! I'd agree, but he has some valid points. Using floats may give you the impression that you don't have to care much about how a particular algo works, and that is a trap many a DSP programmer has fallen into. Problems arise when an algorithm systematically subtracts near equal quantities and presents the difference as a valid result, and this does indeed occur easily with low frequency filters. But AFAICS, it's nearly always possible to work around this if you understand the algorithm. The problem occurs mostly when textbook algorithms are implemented literally, and is not confined to audio or DSP. A classic example is the solution of a quadratic equation: a * x * x + b * x + c = 0 The textbook solution is: d = sqrt (b * b - 4 * a * c) x1 = (-b + d) / (2 * a) x2 = (-b - d) / (2 * a) When the magnitudes of d and b are nearly equal (and that occurs systematically in some applications), one of the two results can be very imprecise. (*) To return to the quoted text, I have the impression that the author compares badly implemented float routines with correctly written fixed points ones. It's easy to arrive at a predefined conclusion that way. -- FA (*) The solution is to compute the largest magnitude root first, and then obtain the second one from their product, c / a. From arnold.krille at gmail.com Tue Oct 18 07:12:30 2005 From: arnold.krille at gmail.com (Arnold Krille) Date: Tue Oct 18 07:12:33 2005 Subject: [linux-audio-dev] Re: snd-usb-usx2y on amd64? - Success (more or less) Message-ID: <2def88b80510180412k88fe1fh@mail.gmail.com> Hi all, just a note: A got it more or less working. This morning I installed the vanilla-2.6.14-rc4 and I could start jackd in realtime with -n6 -p256 and run ardour and qsampler/linuxsampler in parallel without an xrun during normal operation. It just crashed jackd when I used -n6 -p128 but even after that it didn't ruin the sounddriver so I could start jackd again. That really takes a big stone from my heart as I have to do some serious music with the laptop this weekend and I feared I had to mess around with my old one... So thanks for your patience, 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 t_w_ at freenet.de Thu Oct 20 05:36:05 2005 From: t_w_ at freenet.de (Thorsten Wilms) Date: Thu Oct 20 05:34:56 2005 Subject: [linux-audio-dev] Old tracks finaly recorded and mastered Message-ID: <20051020093604.GA8788@charly.SWORD> Hi! Finaly got around to record a number of old tracks that I created using nothing but a GEM S3 keyboard in 1997/98 (well, and my brother's PC for selecting samples and putting them on a floppy for importing). Previoulsy they only existed on floppy and tape and one floppy is corrupted already ... Still in the process of loading them up to archive.org, but some are there by now: In order of my own rating, best at the top: http://www.archive.org/download/s3_07_the_darkness_surrounding_me/thorwil_s3_07_the_darkness_surrounding_me.ogg http://www.archive.org/download/s3_06_multibeatmode/thorwil_s3_06_multibeatmode.ogg http://www.archive.org/download/s3_05_leaving_it_all_behind/thorwil_s3_05_leaving_it_all_behind.ogg http://www.archive.org/download/s3_04_red_sun/thorwil_s3_04_red_sun.ogg http://www.archive.org/download/s3_02_rave_scales/thorwil_s3_02_rave_scales.ogg http://www.archive.org/download/s3_03_blue_beat/thorwil_s3_03_blue_beat.ogg http://www.archive.org/download/s3_08_where_do_i_want_to_go_today/thorwil_s3_08_where_do_i_want_to_go_today.ogg The detail pages can be reached from here: http://www.archive.org/search.php?query=creator%3A%22Thorsten%20Wilms%22 I wouldn't mind people writing reviews there ;) All recorded using the focused Timemachine. Cutting and normalizing with the most enjoyable Sweep. Mastering with the amazing Jamin. Need to practice that some more :). I wasn't aware of how much details can be brought to light using compression. The only problem was having to convert the 32bit float WAVs to 16 bit for lame, as it doesn't recognize that format. I used sndfile-convert for that. Too bad it doesn't take a flag for the output format, but requires filenames for that. But thanks to the nice folks at #lad, it didn't take long to arrive at a bash oneliner for converting a whole directoy. --- Thorsten Wilms From mle+la at mega-nerd.com Thu Oct 20 06:09:30 2005 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Thu Oct 20 06:09:43 2005 Subject: [linux-audio-dev] Old tracks finaly recorded and mastered In-Reply-To: <20051020093604.GA8788@charly.SWORD> References: <20051020093604.GA8788@charly.SWORD> Message-ID: <20051020200930.59423d93.mle+la@mega-nerd.com> Thorsten Wilms wrote: > The only problem was having to convert the 32bit float WAVs to > 16 bit for lame, as it doesn't recognize that format. There was a version of LAME that used the 0.0.X series of libsndfile for file I/O. I don't know hat happened to that. Its pretty trivial to update that code to use 1.0.X libsndfile. > I used > sndfile-convert for that. Too bad it doesn't take a flag for > the output format, but requires filenames for that. sndfile-convert understands -pcm16, -pcm24 and others. It only uses the file extension to figure out the desination file's container type (AU, AIFF, WAV etc). Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of CommonLisp." -- Greenspuns Tenth Rule Of Programming From t_w_ at freenet.de Thu Oct 20 06:44:23 2005 From: t_w_ at freenet.de (Thorsten Wilms) Date: Thu Oct 20 06:42:55 2005 Subject: [linux-audio-dev] Old tracks finaly recorded and mastered In-Reply-To: <20051020200930.59423d93.mle+la@mega-nerd.com> References: <20051020093604.GA8788@charly.SWORD> <20051020200930.59423d93.mle+la@mega-nerd.com> Message-ID: <20051020104423.GC8788@charly.SWORD> On Thu, Oct 20, 2005 at 08:09:30PM +1000, Erik de Castro Lopo wrote: > > I used > > sndfile-convert for that. Too bad it doesn't take a flag for > > the output format, but requires filenames for that. > > sndfile-convert understands -pcm16, -pcm24 and others. > > It only uses the file extension to figure out the desination > file's container type (AU, AIFF, WAV etc). Sorry, that's what I meant, the container. Instead of: for a in *.wav; do sndfile-convert -pcm16 $a $a.wav;done mv *.wav some-folder/ rename .wav.wav .wav * (I know about basename and that I could have put a destination directory in there. Wouldn't make things actualy simpler, though) I would have liked to do something like: mkdir destination sndfile-convert -pcm16 -d destination -c wav *.wav When input and output files use different containers, the second version would become even simpler. Things like this are no big deal, once you know (and don't forget again!) bash's 'for' construct ... Erik: but I'm happy sndfile-convert exists and does its job, so thanks for that! :) --- Thorsten Wilms From dsb at eagle.ru Fri Oct 21 06:27:57 2005 From: dsb at eagle.ru (Dmitry Baikov) Date: Fri Oct 21 06:24:36 2005 Subject: [linux-audio-dev] Edirol FA-101 Message-ID: <4358C2AD.7040307@eagle.ru> Hello! Recently got FA-101. But can't get it to work. Jackd log is below. Thank you in advance. Regards, Dmitry. ---- JACK compiled with System V SHM support. loading driver .. IEC61883: Using FreeBobCtl lib version 0.0.1 (Build Oct 20 2005 - 01:33:14) Reading from OSC URL: osc.udp://localhost:31000 requesting channel info from osc.udp://localhost:31000 adding generic handler... adding /reponse handler... parsing address... sending request... waiting for response... ok freeing... done... ConnectionInfo contains 1 connection_specs IEC61883: Adding 1 capture connection(s)... IEC61883: capture connection 0: 0 streams, dim 0 from (0,11,11) IEC61883: adding stream 0: (1,1) 0x06 0x02 -> 0 (MicIn1 l) IEC61883: adding stream 1: (6,2) 0x06 0x02 -> 0 (MicIn1 right) IEC61883: adding stream 2: (2,1) 0x06 0x03 -> 0 (LineIn 3&4 l) IEC61883: adding stream 3: (7,2) 0x06 0x03 -> 0 (LineIn 3&4 right) IEC61883: adding stream 4: (3,1) 0x06 0x03 -> 0 (LineIn 5&6 l) IEC61883: adding stream 5: (8,2) 0x06 0x03 -> 0 (LineIn 5&6 right) IEC61883: adding stream 6: (4,1) 0x06 0x03 -> 0 (LineIn 7&8 l) IEC61883: adding stream 7: (9,2) 0x06 0x03 -> 0 (LineIn 7&8 right) IEC61883: adding stream 8: (0,1) 0x06 0x04 -> 0 (SpdifIn left) IEC61883: adding stream 9: (5,2) 0x06 0x04 -> 0 (SpdifIn righ) IEC61883: adding stream 10: (10,1) 0x0D 0x0A -> 0 (MidiPort) requesting channel info from osc.udp://localhost:31000 adding generic handler... adding /reponse handler... parsing address... sending request... waiting for response... ok freeing... done... ConnectionInfo contains 1 connection_specs IEC61883: Adding 1 playback connection(s)... IEC61883: playback connection 0: 0 streams, dim 0 to (0,11,11) IEC61883: adding stream 0: (1,1) 0x06 0x03 -> 0 (LineOut 1&2 left) IEC61883: adding stream 1: (6,2) 0x06 0x03 -> 0 (LineOut 1&2 righ) IEC61883: adding stream 2: (2,1) 0x06 0x03 -> 0 (LineOut 3&4 left) IEC61883: adding stream 3: (7,2) 0x06 0x03 -> 0 (LineOut 3&4 righ) IEC61883: adding stream 4: (3,1) 0x06 0x03 -> 0 (LineOut 5&6 left) IEC61883: adding stream 5: (8,2) 0x06 0x03 -> 0 (LineOut 5&6 righ) IEC61883: adding stream 6: (4,1) 0x06 0x03 -> 0 (LineOut 7&8 left) IEC61883: adding stream 7: (9,2) 0x06 0x03 -> 0 (LineOut 7&8 righ) IEC61883: adding stream 8: (0,1) 0x06 0x04 -> 0 (SpdifOut lef) IEC61883: adding stream 9: (5,2) 0x06 0x04 -> 0 (SpdifOut rig) IEC61883: adding stream 10: (10,1) 0x0D 0x0A -> 0 (MidiPort) IEC61883D: Creating driver (period_size=256, ringbuffer_size=8192) Creating IEC61883 client... 256/8192/48000 poll timeout = 5 ms Creating 11 buffers of 8192 quadlets... IEC61883C: Creating playback connection from node 65472, plug 0 prebuffers=0, buffers=300, irq_interval=100 Creating 11 buffers of 8192 quadlets... IEC61883 Client created... Initializing OSC debug & statistics server... port 31001 OK Starting OSC debug & statistics server... OK IEC61883CM: registered jack port cap_0_0_0_MicIn1 l IEC61883CM: registered jack port cap_0_0_0_MicIn1 right IEC61883CM: registered jack port cap_0_0_0_LineIn 3&4 l IEC61883CM: registered jack port cap_0_0_0_LineIn 3&4 right IEC61883CM: registered jack port cap_0_0_0_LineIn 5&6 l IEC61883CM: registered jack port cap_0_0_0_LineIn 5&6 right IEC61883CM: registered jack port cap_0_0_0_LineIn 7&8 l IEC61883CM: registered jack port cap_0_0_0_LineIn 7&8 right IEC61883CM: registered jack port cap_0_0_0_SpdifIn left IEC61883CM: registered jack port cap_0_0_0_SpdifIn righ IEC61883CM: registered midi port MidiIn_0_0_0_MidiPort_1 as 128:0 IEC61883CM: registered jack port pbk_0_0_0_LineOut 1&2 left IEC61883CM: registered jack port pbk_0_0_0_LineOut 1&2 righ IEC61883CM: registered jack port pbk_0_0_0_LineOut 3&4 left IEC61883CM: registered jack port pbk_0_0_0_LineOut 3&4 righ IEC61883CM: registered jack port pbk_0_0_0_LineOut 5&6 left IEC61883CM: registered jack port pbk_0_0_0_LineOut 5&6 righ IEC61883CM: registered jack port pbk_0_0_0_LineOut 7&8 left IEC61883CM: registered jack port pbk_0_0_0_LineOut 7&8 righ IEC61883CM: registered jack port pbk_0_0_0_SpdifOut lef IEC61883CM: registered jack port pbk_0_0_0_SpdifOut rig IEC61883CM: registered midi port MidiOut_0_0_0_MidiPort_1 as 128:1 Client start... creating capture connections... libiec61883 warning: iec61883_cmp_create_p2p_output: Failed to set the oPCR[0] plug f or node 0. Init ISO master receive handler on channel -1... (BUFFER=300,PACKET_MAX=2048 ,IRQ=100)... Start ISO master receive... IEC61883C: couldn't start receiving: Invalid argument DRIVER NT: could not start driver cannot start driver From rlrevell at joe-job.com Fri Oct 21 14:15:06 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Fri Oct 21 14:37:41 2005 Subject: [linux-audio-dev] Edirol FA-101 In-Reply-To: <4358C2AD.7040307@eagle.ru> References: <4358C2AD.7040307@eagle.ru> Message-ID: <1129918506.17483.6.camel@mindpipe> On Fri, 2005-10-21 at 14:27 +0400, Dmitry Baikov wrote: > Hello! > Recently got FA-101. > But can't get it to work. Jackd log is below. > Thank you in advance. Are you using a customized jackd? What version? What command line? Do you have any evidence that anyone has ever made this work? Lee From A.Kuckartz at ping.de Fri Oct 21 15:07:28 2005 From: A.Kuckartz at ping.de (Andreas Kuckartz) Date: Fri Oct 21 15:07:34 2005 Subject: [linux-audio-dev] Edirol FA-101 In-Reply-To: <1129918506.17483.6.camel@mindpipe> References: <4358C2AD.7040307@eagle.ru> <1129918506.17483.6.camel@mindpipe> Message-ID: <43593C70.3020606@ping.de> Lee Revell wrote:: > Do you have any evidence that anyone has ever made this work? This probably does not count as evidence but it is on the list of devices supported by FreeBoB: http://freebob.sourceforge.net/index.php/List_of_Supported_Devices Cheers, Andreas From c0ff at konstruktiv.org Fri Oct 21 15:27:54 2005 From: c0ff at konstruktiv.org (Dmitry S. Baikov) Date: Fri Oct 21 15:28:04 2005 Subject: [linux-audio-dev] Edirol FA-101 Message-ID: <4359413A.2010805@konstruktiv.org> > Are you using a customized jackd? What version? What command line? Do > you have any evidence that anyone has ever made this work? > Opps, sorry for skipping obviously needed details. Was really upset. I tried freebob + jackd from freebob.sf.net. libavc from svn, libiec61883 1.0, libraw1394 1.2 cmdline: jackd -d iec61883 -o osc.udp://localhost:31000 FreeBoB wiki's list of working setups contains FA-101 + gentoo (my distro). When run in the first time, jackd starts, but there's no sound, and seems processing callbacks aren't called (no interrupts?). Dmitry. From rlrevell at joe-job.com Fri Oct 21 15:50:23 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Fri Oct 21 15:51:30 2005 Subject: [linux-audio-dev] Edirol FA-101 In-Reply-To: <4359413A.2010805@konstruktiv.org> References: <4359413A.2010805@konstruktiv.org> Message-ID: <1129924223.17709.15.camel@mindpipe> On Fri, 2005-10-21 at 23:27 +0400, Dmitry S. Baikov wrote: > > Are you using a customized jackd? What version? What command line? Do > > you have any evidence that anyone has ever made this work? > > > Opps, sorry for skipping obviously needed details. Was really upset. > I tried freebob + jackd from freebob.sf.net. > libavc from svn, libiec61883 1.0, libraw1394 1.2 > cmdline: jackd -d iec61883 -o osc.udp://localhost:31000 > > FreeBoB wiki's list of working setups contains FA-101 + gentoo (my distro). > When run in the first time, jackd starts, but there's no sound, and > seems processing callbacks aren't called (no interrupts?). I think this would be a better question for the Freebob list, and cc: the jackit-devel list, as you're using a version of JACK that the Freebob people have customized. I've never heard anyone on LAD or LAU report that this works. First and foremost, we need to get the iec61883 driver into JACK CVS, so that Paul Davis and the other JACK experts can help you. Lee From rlrevell at joe-job.com Fri Oct 21 15:55:40 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Fri Oct 21 15:56:56 2005 Subject: [linux-audio-dev] Re: [linux-audio-user] Edirol FA-101 In-Reply-To: <4358C2AD.7040307@eagle.ru> References: <4358C2AD.7040307@eagle.ru> Message-ID: <1129924541.17709.20.camel@mindpipe> On Fri, 2005-10-21 at 14:27 +0400, Dmitry Baikov wrote: > IEC61883: Using FreeBobCtl lib version 0.0.1 (Build Oct 20 2005 - 01:33:14) Version 0.0.1? Somehow I am not surprised to find that it's buggy ;-) > libiec61883 warning: iec61883_cmp_create_p2p_output: Failed to set > the > oPCR[0] plug f > or node 0. You should ask the Freebob people (or whoever wrote libiec61883) whether this is a serious error. Lee From rlrevell at joe-job.com Fri Oct 21 19:54:07 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Fri Oct 21 20:00:34 2005 Subject: [linux-audio-user] Re: [linux-audio-dev] Edirol FA-101 In-Reply-To: <5bdc1c8b0510211448h73974d70x8cec1a39cc6f52e7@mail.gmail.com> References: <4359413A.2010805@konstruktiv.org> <1129924223.17709.15.camel@mindpipe> <5bdc1c8b0510211448h73974d70x8cec1a39cc6f52e7@mail.gmail.com> Message-ID: <1129938848.4724.20.camel@mindpipe> On Fri, 2005-10-21 at 14:48 -0700, Mark Knecht wrote: > > I think this would be a better question for the Freebob list, and cc: > > the jackit-devel list, as you're using a version of JACK that the > > Freebob people have customized. I've never heard anyone on LAD or LAU > > report that this works. > > > > First and foremost, we need to get the iec61883 driver into JACK CVS, so > > that Paul Davis and the other JACK experts can help you. > > > > Lee > > In case some folks don't know this stuff iec61883 is part of the 1394 > stack. Why would it go into Jack CVS? Sorry, I mean "the iec61883 backend". JACK used to call these "drivers" but as you can see it's confusing. JACK does not need to include the iec61883 stack but it does need to know how to talk to it, just like with ALSA, OSS, etc. Look at his command line: jackd -d iec61883 -o osc.udp://localhost:31000 If I run this I get: rlrevell@mindpipe:~/kernel-source/linux-2.6.13$ jackd -d iec61883 jackd: unknown driver 'iec61883' So he must be using a third party patch to jackd from the Freebob people that implements the 'iec61883' backend. Lee From wagi at monom.org Sat Oct 22 07:03:35 2005 From: wagi at monom.org (Daniel Wagner) Date: Sat Oct 22 07:03:39 2005 Subject: [linux-audio-dev] Re: [linux-audio-user] Edirol FA-101 In-Reply-To: <1129924541.17709.20.camel@mindpipe> References: <4358C2AD.7040307@eagle.ru> <1129924541.17709.20.camel@mindpipe> Message-ID: <435A1C87.3020000@monom.org> >>libiec61883 warning: iec61883_cmp_create_p2p_output: Failed to set >>the >>oPCR[0] plug f >>or node 0. > > > You should ask the Freebob people (or whoever wrote libiec61883) whether > this is a serious error. I remember that someone had the same problems (reported on the freebob-devel list). Unfortunatly, I can't remember what the solution was. You might have to look through the archive. cheers, daniel From rj at spamatica.se Sat Oct 22 07:17:10 2005 From: rj at spamatica.se (Robert Jonsson) Date: Sat Oct 22 07:17:18 2005 Subject: [linux-audio-dev] Edirol FA-101 In-Reply-To: <4359413A.2010805@konstruktiv.org> References: <4359413A.2010805@konstruktiv.org> Message-ID: <200510221317.11265.rj@spamatica.se> Hi, On Friday 21 Oct 2005 21:27, Dmitry S. Baikov wrote: > > Are you using a customized jackd? What version? What command line? Do > > you have any evidence that anyone has ever made this work? > > Opps, sorry for skipping obviously needed details. Was really upset. > I tried freebob + jackd from freebob.sf.net. > libavc from svn, libiec61883 1.0, libraw1394 1.2 > cmdline: jackd -d iec61883 -o osc.udp://localhost:31000 > > FreeBoB wiki's list of working setups contains FA-101 + gentoo (my distro). > When run in the first time, jackd starts, but there's no sound, and > seems processing callbacks aren't called (no interrupts?). > > Dmitry. I have one of those and I got it to work (just did a short test). I'm not familiar with your particular error though. But you must understand that the driver is still alpha quality and is undergoing a complete rewrite, if you are planning to use it for everyday work you need to wait! For more info I agree with others, take it to the freebob list. Regards, Robert -- http://spamatica.se/musicsite/ From t_w_ at freenet.de Sat Oct 22 08:12:24 2005 From: t_w_ at freenet.de (Thorsten Wilms) Date: Sat Oct 22 08:11:01 2005 Subject: [linux-audio-dev] Transport Regions Message-ID: <20051022121224.GB8975@charly.SWORD> Hi! I have been thinking about combining sequencing, (live) looping and sampling. I call the concept I arrived at Transport Regions for now (might call it Areas, Scopes, Frames ... a native speaker's take on this?). A Transport Regions groups n tracks, defining a common playback posistion and transport state (playing, paused, reverse ...). Loops can be defined with Markers. A 'classic' sequencer/daw project would use only 1 Region, but having several could allow sooperlooper like action, with the advantage of simple extension, moving on from jamming to production. Transport commands to specific Regions could be recorded and played back themselves. Instrument type samples could be treated the same, with the known markers, just for rather short loops, provided transport actions could be mapped to midi/notes. Multisampling would require means to map (midi) parameters to track level changes and/or soloing/muting. Patterns could actualy be Transport Regions triggered from a track, from which they would need to 'inherit' tempo for normal operation. Well ... just food for thought! --- Thorsten Wilms From pieterp at joow.be Sat Oct 22 10:57:41 2005 From: pieterp at joow.be (Pieter Palmers) Date: Sat Oct 22 10:57:51 2005 Subject: [linux-audio-dev] Edirol FA-101 In-Reply-To: <1129924223.17709.15.camel@mindpipe> References: <4359413A.2010805@konstruktiv.org> <1129924223.17709.15.camel@mindpipe> Message-ID: <435A5365.60404@joow.be> Lee Revell wrote: >On Fri, 2005-10-21 at 23:27 +0400, Dmitry S. Baikov wrote: > > >>>Are you using a customized jackd? What version? What command line? Do >>>you have any evidence that anyone has ever made this work? >>> >>> >>> >>Opps, sorry for skipping obviously needed details. Was really upset. >>I tried freebob + jackd from freebob.sf.net. >>libavc from svn, libiec61883 1.0, libraw1394 1.2 >>cmdline: jackd -d iec61883 -o osc.udp://localhost:31000 >> >>FreeBoB wiki's list of working setups contains FA-101 + gentoo (my distro). >>When run in the first time, jackd starts, but there's no sound, and >>seems processing callbacks aren't called (no interrupts?). >> >> > >I think this would be a better question for the Freebob list, and cc: >the jackit-devel list, as you're using a version of JACK that the >Freebob people have customized. I've never heard anyone on LAD or LAU >report that this works. > > It is indeed a jackd version we customized in order to develop our streaming layer. So you'd better not hassle the jackit-devel list with problems regarding the freebob/iec61883 backend (yet). It is not supported by them, direct any questions to the freebob-devel mailing list. >First and foremost, we need to get the iec61883 driver into JACK CVS, so >that Paul Davis and the other JACK experts can help you. > > > I think that still remains a topic of discussion... do we want another (specific) backend or do we use the ALSA backend with the ALSA driver that we're also developing. At this point jackd is just a development tool, and the releases we make are pre-alpha (0.0.1 versions indeed). Expect problems with them. WRT the problem you experience: First of all read the README file and make sure you have the EXACT versions of the required libraries installed. There are some changes in library releases that are required in order for freebob to work. OTOH there are some bugfixes in the newest library versions that break the freebob software included in the pre-alpha's. I suspect that you are still using an old libiec61883 version. Greets, Pieter Palmers guilty @ freebob jackd backend mess From ross at stationplaylist.com Sun Oct 23 05:55:49 2005 From: ross at stationplaylist.com (Ross Levis) Date: Sun Oct 23 05:58:16 2005 Subject: [linux-audio-dev] 22050hz mono volume fading Message-ID: <010101c5d7b7$f2308420$dc00a8c0@stationplaylist.com> It's my first post here. I'm developing an audio player which has a fading up/down facility. This is working fine except for 22050 mono samples. I'm getting patchy loud noises (intermittent white noise?) while fading the audio data up and down. The original audio can also be heard between the noise. The basic equation I'm doing is (Excuse the Pascal syntax): Data := Data * CurrVol / 32767; Data is always 2 bytes of audio data (16 bit data). CurrVol goes from 0 to 32767 or vice versa over several bytes. If I remove this line, there is no noise generated, but obviously no volume change either. The problem only occurs when it's mono 22050 samples. Stereo 22050 samples are fine, and mono 44100 samples are fine. I don't understand why this is happening. Any ideas? Thanks, Ross. From fons.adriaensen at skynet.be Sun Oct 23 07:14:57 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Sun Oct 23 07:10:08 2005 Subject: [linux-audio-dev] 22050hz mono volume fading In-Reply-To: <010101c5d7b7$f2308420$dc00a8c0@stationplaylist.com> References: <010101c5d7b7$f2308420$dc00a8c0@stationplaylist.com> Message-ID: <20051023111457.GA4740@linux-1> On Sun, Oct 23, 2005 at 10:55:49PM +1300, Ross Levis wrote: > The basic equation I'm doing is (Excuse the Pascal syntax): > > Data := Data * CurrVol / 32767; > > Data is always 2 bytes of audio data (16 bit data). CurrVol goes from 0 > to 32767 or vice > versa over several bytes. If I remove this line, there is no noise > generated, but > obviously no volume change either. > > The problem only occurs when it's mono 22050 samples. Stereo 22050 > samples are fine, and mono 44100 samples are fine. The problem is clearly not with the line you posted, but with how it is used, i.e. in the code that loops over the samples. Or the sample format of your mono 22k05 source is not what you think it is. For example if its just 8 bits instead of 16 you could get an effect similar to what you describe. -- FA From v2 at iki.fi Sun Oct 23 07:42:07 2005 From: v2 at iki.fi (Sampo Savolainen) Date: Sun Oct 23 07:42:11 2005 Subject: [linux-audio-dev] 22050hz mono volume fading In-Reply-To: <010101c5d7b7$f2308420$dc00a8c0@stationplaylist.com> References: <010101c5d7b7$f2308420$dc00a8c0@stationplaylist.com> Message-ID: <1130067727.4240.6.camel@puppeli> On Sun, 2005-10-23 at 22:55 +1300, Ross Levis wrote: > It's my first post here. I'm developing an audio player which has a > fading > up/down facility. This is working fine except for 22050 mono samples. > I'm getting patchy loud noises (intermittent white noise?) while fading > the audio data up and down. The original audio can also be heard > between the noise. > > The basic equation I'm doing is (Excuse the Pascal syntax): > > Data := Data * CurrVol / 32767; Does CurrVol move gradually from one gain to another gain? If you do a fast gain change, say from 1.0 => 2.0 without gradually moving the gain from the start value to the next value, you will get an horrible transient. Doing a fast gradual change from the first value to the next one is called declicking. Consider two samples, first at 0.5 and the next one at 0.51. If the gain is changed from 1.0 to 2.0 between these samples without declicking, the first sample will be 0.5 and the next one will be 1.02. You can just imagine what this non-continuity will sound like when it gets through your DAC. This will be even worse if you change the gain from 0.0 (-inf) to 1.0. -- Sampo Savolainen From larsl at users.sourceforge.net Sun Oct 23 15:40:37 2005 From: larsl at users.sourceforge.net (Lars Luthman) Date: Sun Oct 23 15:39:35 2005 Subject: [linux-audio-dev] [ANN] Sineshaper 0.4.0 Message-ID: <1130096438.7258.16.camel@c213-100-50-8.swipnet.se> The Sineshaper is a monophonic DSSI synth. This is the first release. Source tarball, screenshot and Vorbis demo are available here: http://ll-plugins.sf.net. The knob graphics are created by Thorsten Wilms and Peter Shorthose. The Sineshaper synth has two sine oscillators and two waveshapers. The sound from the two oscillators is mixed and passed through the waveshapers, first through the first waveshaper and then the second. You can control the tuning of both oscillators as well as their relative loudness, and the total amount of shaping and the fraction of that amount that each shaper applies. Both waveshapers use a sine function for shaping the sound, but for the second shaper you can shift the sine function (with maximal shift it becomes a cosine function) to produce a different sound. You can also add vibrato and tremolo, and change the ADSR envelope that controls the amplitude and shape amount (as well as setting the envelope sensitivity for both the amplifier and the shapers). There is also a "Drive" control that adds distorsion, and a feedback delay with controllable delay time and feedback amount. All control parameters can be changed using MIDI. The Sineshaper synth comes with some presets that you can play or use as starting points for your own synth settings. You can not change these "factory presets", but you can create and save your own presets. They are written to the file .sineshaperpresets in your home directory. If you make any nice presets I would really like to hear them. -- Lars Luthman PGP key: http://www.d.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- 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/20051023/0fe5dc9d/attachment.bin From ce at christeck.de Sun Oct 23 16:12:22 2005 From: ce at christeck.de (Christoph Eckert) Date: Sun Oct 23 16:06:20 2005 Subject: [linux-audio-dev] [ANN] Sineshaper 0.4.0 In-Reply-To: <1130096438.7258.16.camel@c213-100-50-8.swipnet.se> References: <1130096438.7258.16.camel@c213-100-50-8.swipnet.se> Message-ID: <200510232212.22616.ce@christeck.de> Hi, looks promising. Unfortunately I get a build error (aqttached). Any hint which library I need to update? Thanks & Best regards ce sineshapergui.cpp: In constructor `SineShaperGUI::SineShaperGUI(GtkWindow*, const Glib::RefPtr&)': sineshapergui.cpp:179: error: `AboutDialog' undeclared (first use this function) sineshapergui.cpp:179: error: (Each undeclared identifier is reported only once for each function it appears in.) sineshapergui.cpp:179: error: `dlg_about' undeclared (first use this function) sineshapergui.cpp:179: error: template argument 1 is invalid sineshapergui.cpp:179: error: no matching function for call to `SineShaperGUI:: w(const char[10])' From larsl at users.sourceforge.net Sun Oct 23 16:21:39 2005 From: larsl at users.sourceforge.net (Lars Luthman) Date: Sun Oct 23 16:20:36 2005 Subject: [linux-audio-dev] [ANN] Sineshaper 0.4.0 In-Reply-To: <200510232212.22616.ce@christeck.de> References: <1130096438.7258.16.camel@c213-100-50-8.swipnet.se> <200510232212.22616.ce@christeck.de> Message-ID: <1130098899.7258.21.camel@c213-100-50-8.swipnet.se> On Sun, 2005-10-23 at 22:12 +0200, Christoph Eckert wrote: > looks promising. Unfortunately I get a build error (aqttached). > > Any hint which library I need to update? > > [...] > > sineshapergui.cpp:179: error: `AboutDialog' undeclared (first use this > function) That is the Gtk::AboutDialog class. It looks like it was added in gtkmm 2.5.1, so any recent version of libgtkmm (2.6.* or 2.8.*) should probably work. My fault for not checking the gtkmm version in the configure script. -- Lars Luthman PGP key: http://www.d.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- 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/20051023/8d63da7b/attachment.bin From ross at stationplaylist.com Sun Oct 23 19:06:54 2005 From: ross at stationplaylist.com (Ross Levis) Date: Sun Oct 23 19:09:13 2005 Subject: [linux-audio-dev] 22050hz mono volume fading References: <010101c5d7b7$f2308420$dc00a8c0@stationplaylist.com> <20051023111457.GA4740@linux-1> Message-ID: <008601c5d826$75925b90$dc00a8c0@stationplaylist.com> The code looping over the samples appears to be fine. As I mentioned, there is no problems with stereo or 44100 samples. The file format is correct since I created the file myself. It is definately 16-bit, mono, 22050, and only this format has the noise. This is basically the code for fading up (in Pascal). FadeSpeed := 2000; // milliseconds FadeBytes := Round(SampleRate * Channels / 1000 * FadeSpeed); ByteCount := 0; for i := 0 to (BufferSize shr 1) -1 do begin Inc(ByteCount); if ByteCount >= FadeBytes then CurrVol := 32767 else CurrVol := ByteCount / FadeBytes; Buffer16[i] := Buffer16[i] * CurrVol / 32767; end; Buffer16 is an array of 16-bit integer (ShortInt in Pascal). BufferSize is the size in bytes of the audio buffer containing raw audio. To answer Sampo's question, the fades are gradule over periods like 2 seconds. However, I've also tested ith a constant faded volume. eg CurrVol stays constant at one value. The problem still occurs. It's got me stumped, considering that stereo samples work fine and yet the only difference is that it works over double the number of bytes. Ross. ----- Original Message ----- From: "fons adriaensen" To: "The Linux Audio Developers' Mailing List" Sent: Monday, October 24, 2005 12:14 AM Subject: Re: [linux-audio-dev] 22050hz mono volume fading On Sun, Oct 23, 2005 at 10:55:49PM +1300, Ross Levis wrote: > The basic equation I'm doing is (Excuse the Pascal syntax): > > Data := Data * CurrVol / 32767; > > Data is always 2 bytes of audio data (16 bit data). CurrVol goes from > 0 > to 32767 or vice > versa over several bytes. If I remove this line, there is no noise > generated, but > obviously no volume change either. > > The problem only occurs when it's mono 22050 samples. Stereo 22050 > samples are fine, and mono 44100 samples are fine. The problem is clearly not with the line you posted, but with how it is used, i.e. in the code that loops over the samples. Or the sample format of your mono 22k05 source is not what you think it is. For example if its just 8 bits instead of 16 you could get an effect similar to what you describe. -- FA From fons.adriaensen at skynet.be Sun Oct 23 19:55:08 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Sun Oct 23 19:50:16 2005 Subject: [linux-audio-dev] 22050hz mono volume fading In-Reply-To: <008601c5d826$75925b90$dc00a8c0@stationplaylist.com> References: <010101c5d7b7$f2308420$dc00a8c0@stationplaylist.com> <20051023111457.GA4740@linux-1> <008601c5d826$75925b90$dc00a8c0@stationplaylist.com> Message-ID: <20051023235508.GC5045@linux-1> On Mon, Oct 24, 2005 at 12:06:54PM +1300, Ross Levis wrote: > The code looping over the samples appears to be fine. As I mentioned, > there is no problems with stereo or 44100 samples. The file format is > correct since I created the file myself. It is definately 16-bit, mono, > 22050, and only this format has the noise. > ... > However, I've also tested ith a constant faded volume. eg CurrVol stays > constant at one value. The problem still occurs. It's got me stumped, > considering that stereo samples work fine and yet the only difference is > that it works over double the number of bytes. Very strange... The only thing I can suggest ATM is to use some fixed faded volume, and print out a number of corresponding in/out samples to see what exactly is happening. -- FA From ross at stationplaylist.com Sun Oct 23 21:57:06 2005 From: ross at stationplaylist.com (Ross Levis) Date: Sun Oct 23 21:59:21 2005 Subject: [linux-audio-dev] 22050hz mono volume fading References: <010101c5d7b7$f2308420$dc00a8c0@stationplaylist.com><20051023111457.GA4740@linux-1><008601c5d826$75925b90$dc00a8c0@stationplaylist.com> <20051023235508.GC5045@linux-1> Message-ID: <003c01c5d83e$3ceb6940$dc00a8c0@stationplaylist.com> fons adriaensen wrote: > Very strange... The only thing I can suggest ATM is to use some fixed > faded volume, and print out a number of corresponding in/out samples > to see what exactly is happening. That's a good idea. I'll do that when I can get back to it tomorrow. Regards, Ross. From bhare at verizon.net Mon Oct 24 13:07:18 2005 From: bhare at verizon.net (Bradley A. Hare) Date: Mon Oct 24 13:14:01 2005 Subject: [linux-audio-dev] Re: [linux-audio-user] Edirol FA-66 Working Setup Message-ID: <435D14C6.3010206@verizon.net> ce wrote: >there was a talk at LAC 2005; AFAIR the latency was 50msecs this time. >I don't know if it is less these days. I believe I am at 10 msec. now - have not pushed it further yet. >are they already working on a true ALSA driver? I believe they are. There is a dev. road map on the sourceforge page. Regards, Brad Hare From smithbone at gmail.com Tue Oct 25 09:38:18 2005 From: smithbone at gmail.com (Richard Smith) Date: Tue Oct 25 09:38:28 2005 Subject: [linux-audio-dev] applying RIAA curves in software Message-ID: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> I'm going to convert my fathers record collection over to CD. Doing some google research. According to http://www.tracertek.com/newway.htm they claim the "new" and best way to do LP to CD is to use a flat preamp, record at 24bit, 96kHz and then apply the RIAA curve in software after the fact. Either before or after the DeNoise, De-Click, etc depending. I've also seen a few other sites that say the same type things. tracertek sells doze software to do the whole ball of wax but I'd like to use Linux. I haven't found any RIAA filters yet so I guess I'm looking at writeing one. So does anyone have any information on where to find the official RIAA curve to make a plugin from? They also recommend using a pink-noise record to calibrate your setup and then adjust the curve so it matches your system. -- Richard A. Smith From smithbone at gmail.com Tue Oct 25 09:48:47 2005 From: smithbone at gmail.com (Richard Smith) Date: Tue Oct 25 09:48:50 2005 Subject: [linux-audio-dev] Re: applying RIAA curves in software In-Reply-To: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> Message-ID: <8a0c36780510250648q1a61e7c9q1c3eb9b521279f15@mail.gmail.com> > I haven't found any RIAA filters yet so I guess I'm looking at > writeing one. So does anyone have any information on where to find > the official RIAA curve to make a plugin from? Ok. So my orginal google was too tight. "RIAA cuve" yeilds this http://www.bonavolta.ch/hobby/en/audio/riaa.htm So now I just need to stick this in a plugin filter. Any suggestions on the "best" way for this? LADSPA, or perhaps a filter for a different app? Considering that I'm going to want to automate this so I can just sic it on a directory full of LP recordings what would be the groups suggestions. -- Richard A. Smith From fons.adriaensen at alcatel.be Tue Oct 25 09:55:39 2005 From: fons.adriaensen at alcatel.be (Alfons Adriaensen) Date: Tue Oct 25 09:56:06 2005 Subject: [linux-audio-dev] applying RIAA curves in software In-Reply-To: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> Message-ID: <20051025135539.GB8827@bth05w.ABSp.alcatel.be> On Tue, Oct 25, 2005 at 08:38:18AM -0500, Richard Smith wrote: > I haven't found any RIAA filters yet so I guess I'm looking at > writeing one. So does anyone have any information on where to find > the official RIAA curve to make a plugin from? The curve as used in most preamps is the combination of two filtering operations: - a -6dB / octave filter (i.e. integrator) to compensate for the velocity response of a magnetic pickup, - the real RIAA curve. Combining the two gives a filter like this: (use a monospaced font to view this) ______ \ \ \__________ \ \ \ \ The corners are at 50, 500, and 2120 Hz IIRC. Slope is -6dB / octave, so the weighted sum of two first order lowpass filters is all you need. -- FA From smithbone at gmail.com Tue Oct 25 09:58:25 2005 From: smithbone at gmail.com (Richard Smith) Date: Tue Oct 25 09:58:34 2005 Subject: [linux-audio-dev] Re: applying RIAA curves in software In-Reply-To: <8a0c36780510250648q1a61e7c9q1c3eb9b521279f15@mail.gmail.com> References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> <8a0c36780510250648q1a61e7c9q1c3eb9b521279f15@mail.gmail.com> Message-ID: <8a0c36780510250658u44ffe947tc50a027963a4b577@mail.gmail.com> > different app? Considering that I'm going to want to automate this so > I can just sic it on a directory full of LP recordings what would be > the groups suggestions. I really should learn how to use google better I guess. So it looks like JAM already does what I want. Sweet. I'm still takeing suggestions if anyone has any experience with this type stuff. Perhaps some suggestions on using a pink noise LP and "adjusting" the curve. -- Richard A. Smith From S.W.Harris at ecs.soton.ac.uk Tue Oct 25 10:21:26 2005 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Tue Oct 25 10:21:49 2005 Subject: [linux-audio-dev] applying RIAA curves in software In-Reply-To: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> Message-ID: <20051025142126.GE29037@login.ecs.soton.ac.uk> On Tue, Oct 25, 2005 at 08:38:18 -0500, Richard Smith wrote: > I'm going to convert my fathers record collection over to CD. Doing > some google research. > > According to http://www.tracertek.com/newway.htm they claim the "new" > and best way to do LP to CD is to use a flat preamp, record at 24bit, > 96kHz and then apply the RIAA curve in software after the fact. > Either before or after the DeNoise, De-Click, etc depending. I've > also seen a few other sites that say the same type things. I think Jan Depner made a jamin preset to do that. - Steve From smithbone at gmail.com Tue Oct 25 10:21:44 2005 From: smithbone at gmail.com (Richard Smith) Date: Tue Oct 25 10:21:52 2005 Subject: [linux-audio-dev] applying RIAA curves in software In-Reply-To: <20051025135539.GB8827@bth05w.ABSp.alcatel.be> References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> <20051025135539.GB8827@bth05w.ABSp.alcatel.be> Message-ID: <8a0c36780510250721y4bded95cu5af66f0a74453a25@mail.gmail.com> > > The corners are at 50, 500, and 2120 Hz IIRC. > Slope is -6dB / octave, so the weighted sum of two > first order lowpass filters is all you need. > Do you know if the RIAA_EQ in JAM includes this? -- Richard A. Smith From RAudette at OrganWorks.com Tue Oct 25 11:06:49 2005 From: RAudette at OrganWorks.com (Richard Audette) Date: Tue Oct 25 11:06:37 2005 Subject: [linux-audio-dev] applying RIAA curves in software In-Reply-To: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.co m> References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> Message-ID: <6.2.1.2.0.20051025110435.01d44758@mail.the-wire.com> Not sure if it's scriptable, but I believe Audacity has this built in: Effects -> Equalization -> RIAA Richard At 09:38 AM 10/25/2005, you wrote: >I'm going to convert my fathers record collection over to CD. Doing >some google research. > >According to http://www.tracertek.com/newway.htm they claim the "new" >and best way to do LP to CD is to use a flat preamp, record at 24bit, >96kHz and then apply the RIAA curve in software after the fact. >Either before or after the DeNoise, De-Click, etc depending. I've >also seen a few other sites that say the same type things. > >tracertek sells doze software to do the whole ball of wax but I'd like >to use Linux. > >I haven't found any RIAA filters yet so I guess I'm looking at >writeing one. So does anyone have any information on where to find >the official RIAA curve to make a plugin from? > >They also recommend using a pink-noise record to calibrate your setup >and then adjust the curve so it matches your system. > >-- >Richard A. Smith From loki.davison at gmail.com Tue Oct 25 11:07:33 2005 From: loki.davison at gmail.com (Loki Davison) Date: Tue Oct 25 11:07:40 2005 Subject: [linux-audio-dev] Re: applying RIAA curves in software In-Reply-To: <8a0c36780510250721y4bded95cu5af66f0a74453a25@mail.gmail.com> References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> <20051025135539.GB8827@bth05w.ABSp.alcatel.be> <8a0c36780510250721y4bded95cu5af66f0a74453a25@mail.gmail.com> Message-ID: On 10/26/05, Richard Smith wrote: > > > > The corners are at 50, 500, and 2120 Hz IIRC. > > Slope is -6dB / octave, so the weighted sum of two > > first order lowpass filters is all you need. > > > > Do you know if the RIAA_EQ in JAM includes this? > > -- > Richard A. Smith > > Is there some sane reason for not just using a turntable preamp? The phono signal level is quite low and i'm assuming recording it as line level and amping in software isn't the nicest or easiest way to do it. I really fail to see the positives. I record stuff from vinyl on a regular basis, so i can hear my mistakes, as i'm a dj. All professionally produced cd's mastered from vinyl (i.e any dj mix cd like global underground) are done through normal phono preamps. Easiest and best solution i think. Loki From smithbone at gmail.com Tue Oct 25 11:21:37 2005 From: smithbone at gmail.com (Richard Smith) Date: Tue Oct 25 11:21:44 2005 Subject: [linux-audio-dev] Re: applying RIAA curves in software In-Reply-To: References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> <20051025135539.GB8827@bth05w.ABSp.alcatel.be> <8a0c36780510250721y4bded95cu5af66f0a74453a25@mail.gmail.com> Message-ID: <8a0c36780510250821n2102eb5m871a408bfe95d9e4@mail.gmail.com> > > Is there some sane reason for not just using a turntable preamp? The > phono signal level is quite low and i'm assuming recording it as line http://www.tracertek.com/newway.htm You use a preamp but its flat rather than RIAA. Then you de-noise, and de-click and then apply your pink noise "corrected" RIAA filter to the end result. -- Richard A. Smith From klaus.kosten at gmx.de Tue Oct 25 11:48:10 2005 From: klaus.kosten at gmx.de (Klaus Kosten) Date: Tue Oct 25 11:48:32 2005 Subject: [linux-audio-dev] Re: applying RIAA curves in software In-Reply-To: <8a0c36780510250821n2102eb5m871a408bfe95d9e4@mail.gmail.com> References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> <20051025135539.GB8827@bth05w.ABSp.alcatel.be> <8a0c36780510250721y4bded95cu5af66f0a74453a25@mail.gmail.com> <8a0c36780510250821n2102eb5m871a408bfe95d9e4@mail.gmail.com> Message-ID: <435E53BA.8080905@gmx.de> Richard Smith wrote: >>Is there some sane reason for not just using a turntable preamp? The >>phono signal level is quite low and i'm assuming recording it as line > > > http://www.tracertek.com/newway.htm > Quite a lot of words. I?m impressed. And convinced ... ... of the fact, that these guys just want to sell their stuff. If you have a decent phono preamp, use it and forget all about that tracertek advertising hype. -- Klaus Kosten From fons.adriaensen at alcatel.be Tue Oct 25 12:19:39 2005 From: fons.adriaensen at alcatel.be (Alfons Adriaensen) Date: Tue Oct 25 12:19:44 2005 Subject: [linux-audio-dev] Re: applying RIAA curves in software In-Reply-To: References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> <20051025135539.GB8827@bth05w.ABSp.alcatel.be> <8a0c36780510250721y4bded95cu5af66f0a74453a25@mail.gmail.com> Message-ID: <20051025161939.GE8827@bth05w.ABSp.alcatel.be> On Wed, Oct 26, 2005 at 01:07:33AM +1000, Loki Davison wrote: > Is there some sane reason for not just using a turntable preamp? The > phono signal level is quite low and i'm assuming recording it as line > level and amping in software isn't the nicest or easiest way to do it. > I really fail to see the positives. I record stuff from vinyl on a > regular basis, so i can hear my mistakes, as i'm a dj. All > professionally produced cd's mastered from vinyl (i.e any dj mix cd > like global underground) are done through normal phono preamps. > Easiest and best solution i think. Recording without a preamp into line or mic input seems a bad idea. A preamp is still needed to 1. get normal levels, 2. present the correct impedance to the pickup. Mic input have relative low impedance and will give horrible results, and line in will not be sensitive enough. But moving the EQ to after the 'restoration' may be a good idea. -- FA From smithbone at gmail.com Tue Oct 25 14:35:50 2005 From: smithbone at gmail.com (Richard Smith) Date: Tue Oct 25 14:35:54 2005 Subject: [linux-audio-dev] Re: applying RIAA curves in software In-Reply-To: <435E53BA.8080905@gmx.de> References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> <20051025135539.GB8827@bth05w.ABSp.alcatel.be> <8a0c36780510250721y4bded95cu5af66f0a74453a25@mail.gmail.com> <8a0c36780510250821n2102eb5m871a408bfe95d9e4@mail.gmail.com> <435E53BA.8080905@gmx.de> Message-ID: <8a0c36780510251135h1b65a694sd8a16896b211e99f@mail.gmail.com> > Quite a lot of words. I?m impressed. And convinced ... > > ... of the fact, that these guys just want to sell their stuff. > You really think its just all hype? Sort of made sense to me. If you do click and pop removal prior to the un-RIAA. Then that will go that much further to reduce the noise since its all high-frequency. > If you have a decent phono preamp, use it and forget all about that > tracertek advertising hype. > I don't have a preamp at all. Thats part of what led me to that page. Recommendations? -- Richard A. Smith From howard.m.cornell.iii at lmco.com Tue Oct 25 14:51:43 2005 From: howard.m.cornell.iii at lmco.com (Cornell III, Howard M) Date: Tue Oct 25 15:16:43 2005 Subject: [linux-audio-dev] Re: applying RIAA curves in software Message-ID: <140F0E67720B194BB90FE31F40D6704404C4A19C@emss02m19.us.lmco.com> Maybe use a crystal cartridge that puts out approximately one volt instead of a magnetic cartridge that puts out tens of millivolts. That attacks the signal to noise problem from the signal side. The RIAA record curve reduces bass and increases treble, and the reverse RIAA curve for playback does the opposite. If most of the objectionable noise is high frequency and you only filter it once wouldn't you just have to do it when the noise was accentuated, before the reverse RIAA filter? -----Original Message----- From: linux-audio-dev-bounces@music.columbia.edu [mailto:linux-audio-dev-bounces@music.columbia.edu] On Behalf Of Richard Smith Sent: Tuesday, October 25, 2005 1:36 PM To: The Linux Audio Developers' Mailing List Subject: Re: [linux-audio-dev] Re: applying RIAA curves in software > Quite a lot of words. I?m impressed. And convinced ... > > ... of the fact, that these guys just want to sell their stuff. > You really think its just all hype? Sort of made sense to me. If you do click and pop removal prior to the un-RIAA. Then that will go that much further to reduce the noise since its all high-frequency. > If you have a decent phono preamp, use it and forget all about that > tracertek advertising hype. > I don't have a preamp at all. Thats part of what led me to that page. Recommendations? -- Richard A. Smith From fredg at salemradiolabs.com Tue Oct 25 15:18:48 2005 From: fredg at salemradiolabs.com (Fred Gleason) Date: Tue Oct 25 15:18:59 2005 Subject: [linux-audio-dev] Re: applying RIAA curves in software In-Reply-To: <8a0c36780510251135h1b65a694sd8a16896b211e99f@mail.gmail.com> References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> <435E53BA.8080905@gmx.de> <8a0c36780510251135h1b65a694sd8a16896b211e99f@mail.gmail.com> Message-ID: <200510251518.48819.fredg@salemradiolabs.com> On Tuesday 25 October 2005 14:35, Richard Smith wrote: > I don't have a preamp at all. ?Thats part of what led me to that page. > ?Recommendations? Well, you're going to want *some* sort of preamp. One with selectable/defeatable EQ curves would presumably be best. This will also be dependent upon the age of the specific recordings being transferred. Early on in the industry, each record company had their own 'proprietary' curve, and high-end players had the ability to select which curve to use. That was why the RIAA eventually stepped in (late 40s?) and developed a standard that all the companies could agree on. Cheers! |-------------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Director of Broadcast Software Development | | | Salem Radio Labs | |-------------------------------------------------------------------------| | The nice thing about standards is that there are so many of them to | | choose from. | | -- Andrew S. Tanenbaum | |-------------------------------------------------------------------------| From smithbone at gmail.com Tue Oct 25 15:36:28 2005 From: smithbone at gmail.com (Richard Smith) Date: Tue Oct 25 15:36:33 2005 Subject: [linux-audio-dev] Re: applying RIAA curves in software In-Reply-To: <200510251518.48819.fredg@salemradiolabs.com> References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> <435E53BA.8080905@gmx.de> <8a0c36780510251135h1b65a694sd8a16896b211e99f@mail.gmail.com> <200510251518.48819.fredg@salemradiolabs.com> Message-ID: <8a0c36780510251236i7109f0dm278702be5d3e03e@mail.gmail.com> On 10/25/05, Fred Gleason wrote: > On Tuesday 25 October 2005 14:35, Richard Smith wrote: > > I don't have a preamp at all. Thats part of what led me to that page. > > Recommendations? > > Well, you're going to want *some* sort of preamp. One with > selectable/defeatable EQ curves would presumably be best. > > This will also be dependent upon the age of the specific recordings being > transferred. Early on in the industry, each record company had their own > 'proprietary' curve, and high-end players had the ability to select which > curve to use. That was why the RIAA eventually stepped in (late 40s?) and > developed a standard that all the companies could agree on. That seems to be exactly what the tracertek page was saying. There is no one "right" way to un-RIAA a record. So why not do it in software where you can tweak with it. I *know* I need a preamp. The question is just which one? Oh yeah I forgot to mention that I also have some 78's that mix and not just 33's -- Richard A. Smith From smithbone at gmail.com Tue Oct 25 15:40:20 2005 From: smithbone at gmail.com (Richard Smith) Date: Tue Oct 25 15:40:23 2005 Subject: [linux-audio-dev] Re: applying RIAA curves in software In-Reply-To: <140F0E67720B194BB90FE31F40D6704404C4A19C@emss02m19.us.lmco.com> References: <140F0E67720B194BB90FE31F40D6704404C4A19C@emss02m19.us.lmco.com> Message-ID: <8a0c36780510251240m6bcbb00clcdc7ae78255fa2d7@mail.gmail.com> >signal side. The RIAA record curve reduces bass and increases treble, and the reverse RIAA >curve for playback does the opposite. If most of the objectionable noise is high frequency >and you only filter it once wouldn't you just have to do it when the noise was accentuated, >before the reverse RIAA filter? Exactly. Denoise and it before the the reverse RIAA and your efforts will be that much better. At least thats I what get out of it. -- Richard A. Smith From fons.adriaensen at skynet.be Tue Oct 25 16:54:18 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Tue Oct 25 16:49:33 2005 Subject: [linux-audio-dev] Re: applying RIAA curves in software In-Reply-To: <140F0E67720B194BB90FE31F40D6704404C4A19C@emss02m19.us.lmco.com> References: <140F0E67720B194BB90FE31F40D6704404C4A19C@emss02m19.us.lmco.com> Message-ID: <20051025205417.GA4959@linux-1> On Tue, Oct 25, 2005 at 01:51:43PM -0500, Cornell III, Howard M wrote: > Maybe use a crystal cartridge that puts out approximately one volt instead > of a magnetic cartridge that puts out tens of millivolts. That attacks the > signal to noise problem from the signal side. A crystal pickup requires a very high-impedance, low-capacitance input. Wiring this, or a magnetic one directly to an input that is not designed for the purpose will just generate trouble. > The RIAA record curve reduces bass and increases treble, and the reverse > RIAA curve for playback does the opposite. Sorry, but this is plain wrong. The RIAA filter used when cutting a disk master will boost bass (below 50 Hz), and reduce high frequencies. This actually leads to a worse S/N ratio on playback. It looks like this: \ \______ (1) \ \________ The high frequency shelving is (was) required to adapt to the limitations of disk cutting technology, and the bass boost allows to reduce rumble (mecahnical VLF noise) on playback. The inverse (playback) filter is of course: ________ / _______/ (2) / / Combine this with the -6dB / octave required for a magnetic transducer, (and which has nothing to do with RIAA equalisation) and you get the familiar curve: ___ \ \_____ (3) \ \ \ For a crystal transducer (assuming it has a flat frequency response), you would actually need (2). -- FA From smithbone at gmail.com Tue Oct 25 17:10:12 2005 From: smithbone at gmail.com (Richard Smith) Date: Tue Oct 25 17:10:17 2005 Subject: [linux-audio-dev] Re: applying RIAA curves in software In-Reply-To: <20051025205417.GA4959@linux-1> References: <140F0E67720B194BB90FE31F40D6704404C4A19C@emss02m19.us.lmco.com> <20051025205417.GA4959@linux-1> Message-ID: <8a0c36780510251410g6a866071t2b4042b7cedb39b0@mail.gmail.com> > > > The RIAA record curve reduces bass and increases treble, and the reverse > > RIAA curve for playback does the opposite. > > Sorry, but this is plain wrong. The RIAA filter used when cutting a disk > master will boost bass (below 50 Hz), and reduce high frequencies. This > actually leads to a worse S/N ratio on playback. It looks like this: I'm confused then. This page: http://www.bonavolta.ch/hobby/en/audio/riaa.htm Has a spread sheet that runs the math on the equation presented. Unless I'm just backwards for RIAA reproduction it yeilds roughly 20dB of gain for 20Hz and -21dB for 21kHz. Which seems backward from what you are saying. -- Richard A. Smith From eviltwin69 at cableone.net Tue Oct 25 13:06:29 2005 From: eviltwin69 at cableone.net (Jan Depner) Date: Tue Oct 25 17:51:21 2005 Subject: [linux-audio-dev] applying RIAA curves in software In-Reply-To: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> Message-ID: <1130259989.830.1.camel@eviltwin> On Tue, 2005-10-25 at 08:38, Richard Smith wrote: > I'm going to convert my fathers record collection over to CD. Doing > some google research. > > According to http://www.tracertek.com/newway.htm they claim the "new" > and best way to do LP to CD is to use a flat preamp, record at 24bit, > 96kHz and then apply the RIAA curve in software after the fact. > Either before or after the DeNoise, De-Click, etc depending. I've > also seen a few other sites that say the same type things. > > tracertek sells doze software to do the whole ball of wax but I'd like > to use Linux. > > I haven't found any RIAA filters yet so I guess I'm looking at > writeing one. So does anyone have any information on where to find > the official RIAA curve to make a plugin from? > > They also recommend using a pink-noise record to calibrate your setup > and then adjust the curve so it matches your system. > If you download JAMin you'll find that I've already put the RIAA curve in the sample .jam files. I've used this to record directly from album to 24/96 with no preamp. It works fine. -- Jan "Evil Twin" Depner The Fuzzy Dice http://www.thefuzzydice.com "As we enjoy great advantages from the invention of others, we should be glad of an opportunity to serve others by any invention of ours, and this we should do freely and generously." Benjamin Franklin, on declining patents offered by the governor of Pennsylvania for his "Pennsylvania Fireplace", c. 1744 From fons.adriaensen at skynet.be Tue Oct 25 18:00:17 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Tue Oct 25 17:55:22 2005 Subject: [linux-audio-dev] Re: applying RIAA curves in software In-Reply-To: <8a0c36780510251410g6a866071t2b4042b7cedb39b0@mail.gmail.com> References: <140F0E67720B194BB90FE31F40D6704404C4A19C@emss02m19.us.lmco.com> <20051025205417.GA4959@linux-1> <8a0c36780510251410g6a866071t2b4042b7cedb39b0@mail.gmail.com> Message-ID: <20051025220017.GB4959@linux-1> On Tue, Oct 25, 2005 at 04:10:12PM -0500, Richard Smith wrote: > > > > > The RIAA record curve reduces bass and increases treble, and the reverse > > > RIAA curve for playback does the opposite. > > > > Sorry, but this is plain wrong. The RIAA filter used when cutting a disk > > master will boost bass (below 50 Hz), and reduce high frequencies. This > > actually leads to a worse S/N ratio on playback. It looks like this: > > I'm confused then. > > This page: > > http://www.bonavolta.ch/hobby/en/audio/riaa.htm > > Has a spread sheet that runs the math on the equation presented. > Unless I'm just backwards for RIAA reproduction it yeilds roughly 20dB > of gain for 20Hz and -21dB for 21kHz. Which seems backward from what > you are saying. That curve, the same as (3) in my previous post, is often called 'the RIAA curve' but it isn't. It is the combination two things: * a 1/F (or -6dB/oct) filter that is required to compensate for the +6dB/oct response of a magnetic cartridge, * and the real RIAA playback curve, (2) in my previous post, which boosts high frequencies. In other words, the general downward slope of the filter you refer to has nothing to do with RIAA equalisation, it's there only because that filter is designed for use in a preamp for a magnetic cartridge. If you would have a flat frequency response from the cartridge, then the filtering required needs to boost high frequencies, as in (2). If you take (2), and turn it 45 degrees clockwise (that adds the -6dB/oct slope for the transducer), you get the curve you refer to. So the idea that the RIAA curve was introduced to improve the S/N ratio at high frequencies is just wrong, it does the opposite. -- FA From smithbone at gmail.com Tue Oct 25 18:04:46 2005 From: smithbone at gmail.com (Richard Smith) Date: Tue Oct 25 18:04:51 2005 Subject: [linux-audio-dev] applying RIAA curves in software In-Reply-To: <1130259989.830.1.camel@eviltwin> References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> <1130259989.830.1.camel@eviltwin> Message-ID: <8a0c36780510251504x73acf621qbffdf24e83bc54a6@mail.gmail.com> > If you download JAMin you'll find that I've already put the RIAA > curve in the sample .jam files. I've used this to record directly from > album to 24/96 with no preamp. It works fine. Sweet. What input did you use on your soundcard? Can I yak with you off list? This is getting kinda OT for LAD. -- Richard A. Smith From eviltwin69 at cableone.net Tue Oct 25 13:24:39 2005 From: eviltwin69 at cableone.net (Jan Depner) Date: Tue Oct 25 18:09:40 2005 Subject: [linux-audio-dev] applying RIAA curves in software In-Reply-To: <1130259989.830.1.camel@eviltwin> References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> <1130259989.830.1.camel@eviltwin> Message-ID: <1130261079.830.9.camel@eviltwin> On Tue, 2005-10-25 at 12:06, Jan Depner wrote: > On Tue, 2005-10-25 at 08:38, Richard Smith wrote: > > I'm going to convert my fathers record collection over to CD. Doing > > some google research. > > > > According to http://www.tracertek.com/newway.htm they claim the "new" > > and best way to do LP to CD is to use a flat preamp, record at 24bit, > > 96kHz and then apply the RIAA curve in software after the fact. > > Either before or after the DeNoise, De-Click, etc depending. I've > > also seen a few other sites that say the same type things. > > > > tracertek sells doze software to do the whole ball of wax but I'd like > > to use Linux. > > > > I haven't found any RIAA filters yet so I guess I'm looking at > > writeing one. So does anyone have any information on where to find > > the official RIAA curve to make a plugin from? > > > > They also recommend using a pink-noise record to calibrate your setup > > and then adjust the curve so it matches your system. > > > > If you download JAMin you'll find that I've already put the RIAA > curve in the sample .jam files. I've used this to record directly from > album to 24/96 with no preamp. It works fine. Wait, let me rephrase that - with no RIAA preamp. I do use a preamp for the signal. -- Jan "Evil Twin" Depner The Fuzzy Dice http://www.thefuzzydice.com "As we enjoy great advantages from the invention of others, we should be glad of an opportunity to serve others by any invention of ours, and this we should do freely and generously." Benjamin Franklin, on declining patents offered by the governor of Pennsylvania for his "Pennsylvania Fireplace", c. 1744 From howard.m.cornell.iii at lmco.com Tue Oct 25 19:12:41 2005 From: howard.m.cornell.iii at lmco.com (Cornell III, Howard M) Date: Tue Oct 25 19:12:48 2005 Subject: [linux-audio-dev] Re: applying RIAA curves in software Message-ID: <140F0E67720B194BB90FE31F40D67044098C6492@emss02m19.us.lmco.com> I stand by my assertion that the RIAA record curve attenuates the low frequencies and amplifies the high frequencies. The physical effects on the record are such that the attenuated low frequencies do not cause the cutting head trace to take up so much room on the master, and by the same reasoning, the normally low amplitudes at high frequencies are given more (physical) headroom. Of course the reverse filter would flatten the frequency response and the use of the record filter optimizes the use of the master "real estate". -----Original Message----- From: linux-audio-dev-bounces@music.columbia.edu [mailto:linux-audio-dev-bounces@music.columbia.edu] On Behalf Of fons adriaensen Sent: Tuesday, October 25, 2005 5:00 PM To: The Linux Audio Developers' Mailing List Subject: Re: [linux-audio-dev] Re: applying RIAA curves in software On Tue, Oct 25, 2005 at 04:10:12PM -0500, Richard Smith wrote: > > > > > The RIAA record curve reduces bass and increases treble, and the > > > reverse RIAA curve for playback does the opposite. > > > > Sorry, but this is plain wrong. The RIAA filter used when cutting a > > disk master will boost bass (below 50 Hz), and reduce high > > frequencies. This actually leads to a worse S/N ratio on playback. It looks like this: > > I'm confused then. > > This page: > > http://www.bonavolta.ch/hobby/en/audio/riaa.htm > > Has a spread sheet that runs the math on the equation presented. > Unless I'm just backwards for RIAA reproduction it yeilds roughly 20dB > of gain for 20Hz and -21dB for 21kHz. Which seems backward from what > you are saying. That curve, the same as (3) in my previous post, is often called 'the RIAA curve' but it isn't. It is the combination two things: * a 1/F (or -6dB/oct) filter that is required to compensate for the +6dB/oct response of a magnetic cartridge, * and the real RIAA playback curve, (2) in my previous post, which boosts high frequencies. In other words, the general downward slope of the filter you refer to has nothing to do with RIAA equalisation, it's there only because that filter is designed for use in a preamp for a magnetic cartridge. If you would have a flat frequency response from the cartridge, then the filtering required needs to boost high frequencies, as in (2). If you take (2), and turn it 45 degrees clockwise (that adds the -6dB/oct slope for the transducer), you get the curve you refer to. So the idea that the RIAA curve was introduced to improve the S/N ratio at high frequencies is just wrong, it does the opposite. -- FA From fons.adriaensen at skynet.be Tue Oct 25 19:28:01 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Tue Oct 25 19:23:11 2005 Subject: [linux-audio-dev] applying RIAA curves in software In-Reply-To: <1130261079.830.9.camel@eviltwin> References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> <1130259989.830.1.camel@eviltwin> <1130261079.830.9.camel@eviltwin> Message-ID: <20051025232801.GC4959@linux-1> On Tue, Oct 25, 2005 at 12:24:39PM -0500, Jan Depner wrote: > > If you download JAMin you'll find that I've already put the RIAA > > curve in the sample .jam files. I've used this to record directly from > > album to 24/96 with no preamp. It works fine. > > Wait, let me rephrase that - with no RIAA preamp. I do use a preamp > for the signal. I don't want to bring down the great work done by Jamin's authors, but if fidelity is among you goals then using Jamin for RIAA equalisation would be a bad idea. First, Jamin's FFT based filtering can be quite inaccurate at low frequencies. For example, push up the 31 Hz slider and measure the result. This is because of the limited resolution of the FFT at LF, and you can probably get around this problem by trial and error. Second, the general 1/F slope of the RIAA curve when combined with cartridge equalisation should produce a -90 degrees phase shift over most of the audio band. When you synthesize such a curve with a multiband EQ, you will not have that phase shift, and any percussive or transient sounds will be affected. You can easily hear this on some instruments. It's quite simple to make an RIAA filter with for example two first order lowpass LADSPA plugins. Put them in parallel, set one to 50 Hz and the second to 2120 Hz. Mix the outputs in the ratio 9 to 1, and the result will be a *perfect* RIAA filter. -- FA From smithbone at gmail.com Tue Oct 25 19:47:51 2005 From: smithbone at gmail.com (Richard Smith) Date: Tue Oct 25 19:47:58 2005 Subject: [linux-audio-dev] applying RIAA curves in software In-Reply-To: <20051025232801.GC4959@linux-1> References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> <1130259989.830.1.camel@eviltwin> <1130261079.830.9.camel@eviltwin> <20051025232801.GC4959@linux-1> Message-ID: <8a0c36780510251647i76b9e879v5097fe9c32c9731e@mail.gmail.com> > I don't want to bring down the great work done by Jamin's authors, but > if fidelity is among you goals then using Jamin for RIAA equalisation > would be a bad idea. Fidelity is in fact the primary goal. > > It's quite simple to make an RIAA filter with for example two > first order lowpass LADSPA plugins. Put them in parallel, set > one to 50 Hz and the second to 2120 Hz. Mix the outputs in the > ratio 9 to 1, and the result will be a *perfect* RIAA filter. Which one is 9 the 50 or the 2120? Any suggestions on what program I can use to run these? Audacity will do LADSPA plugings but I rather something I can script. -- Richard A. Smith From smithbone at gmail.com Tue Oct 25 19:52:05 2005 From: smithbone at gmail.com (Richard Smith) Date: Tue Oct 25 19:52:11 2005 Subject: [linux-audio-dev] applying RIAA curves in software In-Reply-To: <20051025232801.GC4959@linux-1> References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> <1130259989.830.1.camel@eviltwin> <1130261079.830.9.camel@eviltwin> <20051025232801.GC4959@linux-1> Message-ID: <8a0c36780510251652g50017675m9b46aeb353e1494e@mail.gmail.com> > one to 50 Hz and the second to 2120 Hz. Mix the outputs in the > ratio 9 to 1, and the result will be a *perfect* RIAA filter. What's your take on the pink noise calibration? I'm not sure yet if I'm going to go to that much trouble but if I did how easy is it to convert that to a LADSPA filter? -- Richard A. Smith From fons.adriaensen at skynet.be Tue Oct 25 20:32:17 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Tue Oct 25 20:27:27 2005 Subject: [linux-audio-dev] Re: applying RIAA curves in software In-Reply-To: <140F0E67720B194BB90FE31F40D67044098C6492@emss02m19.us.lmco.com> References: <140F0E67720B194BB90FE31F40D67044098C6492@emss02m19.us.lmco.com> Message-ID: <20051026003217.GD4959@linux-1> On Tue, Oct 25, 2005 at 06:12:41PM -0500, Cornell III, Howard M wrote: > I stand by my assertion that the RIAA record curve attenuates the low > frequencies and amplifies the high frequencies. The physical effects on > the record are such that the attenuated low frequencies do not cause the > cutting head trace to take up so much room on the master, and by the > same reasoning, the normally low amplitudes at high frequencies are > given more (physical) headroom. Of course the reverse filter would > flatten the frequency response and the use of the record filter > optimizes the use of the master "real estate". It depends on how you look at it. Suppose you want the same amplitude on the disc (i.e. the same mechanical displacement of the spiral track) for all frequencies. Then you need to feed a typical disc cutter head with a signal that rises 6db per octave. This is because the driving voltage controls its velocity (in the same way really as with a DC motor), and not its amplitude. If you play such a disc with a magnetic cartridge without any equaliser, you willl get a response that again rises 6dB per octave, not because of the EQ applied in the cutter, but because the cartride delivers a voltage that is again proportional to velocity rather than amplitude. To compensate for this, you apply -6dB/oct in the preamp. So to have a flat frequency response _on disc_, we need to amplify the HF when recording and attenuate it when playing back. That equalisation is there purely because of the transducers used at either end. Compared to such a flat system, the RIAA curve attenuates HF when recording and amplifies them on playback. The correction applied is small compared to the filtering that was already required to have a flat 'on disc' response, so the net result is still boosting HF on record, and attenuating it at playback. But relative to the flat response, it's not preemphasis, but rather the opposite. The confusion arises because the 'official' RIAA curves include the transducer equalisation, or in other words, they are defined in terms of voltages required to drive the cutter or obtained from the playback cartridge, and not in terms of mechanical signal amplitude on the disc. Hope this clears up the matter. -- FA From fons.adriaensen at skynet.be Tue Oct 25 20:53:29 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Tue Oct 25 20:48:43 2005 Subject: [linux-audio-dev] applying RIAA curves in software In-Reply-To: <8a0c36780510251652g50017675m9b46aeb353e1494e@mail.gmail.com> References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> <1130259989.830.1.camel@eviltwin> <1130261079.830.9.camel@eviltwin> <20051025232801.GC4959@linux-1> <8a0c36780510251652g50017675m9b46aeb353e1494e@mail.gmail.com> Message-ID: <20051026005329.GF4959@linux-1> On Tue, Oct 25, 2005 at 06:52:05PM -0500, Richard Smith wrote: > What's your take on the pink noise calibration? I'm not sure yet if > I'm going to go to that much trouble but if I did how easy is it to > convert that to a LADSPA filter? The calibration only makes sense if you have a disc with pink noise recorded on it - the filter itself (being numerical) will be exact. To measure the pink noise, you could use JAPA, using the slowest mode and the 'Proportional' frequency response. To get the correct response at HF, you really need a preamp with the correct input impedance (50 kOhm for most cartridges, usually less for 'moving coil' types). But the final adjustments probably will be arrived at by listening, and making some gentle response changes. For this, JAMIN is excellent. -- FA From fons.adriaensen at skynet.be Tue Oct 25 20:41:25 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Tue Oct 25 20:48:53 2005 Subject: [linux-audio-dev] applying RIAA curves in software In-Reply-To: <8a0c36780510251647i76b9e879v5097fe9c32c9731e@mail.gmail.com> References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> <1130259989.830.1.camel@eviltwin> <1130261079.830.9.camel@eviltwin> <20051025232801.GC4959@linux-1> <8a0c36780510251647i76b9e879v5097fe9c32c9731e@mail.gmail.com> Message-ID: <20051026004125.GE4959@linux-1> On Tue, Oct 25, 2005 at 06:47:51PM -0500, Richard Smith wrote: > Which one is 9 the 50 or the 2120? > Any suggestions on what program I can use to run these? Audacity will > do LADSPA plugings but I rather something I can script. Filter 1: F = 50 Hz, A = 9 Filter 2: F = 2120 Hz, A = 1 and add the two outputs. The first one produces the first downward 'corner' at 50 Hz, and the second one the downward corner at 2120 Hz. The combination of the two gives the 'upward' corner at 50 * (1 + 9) / 1 = 500 Hz. -- FA From smithbone at gmail.com Tue Oct 25 22:16:55 2005 From: smithbone at gmail.com (Richard Smith) Date: Tue Oct 25 22:17:05 2005 Subject: [linux-audio-dev] applying RIAA curves in software In-Reply-To: <20051026004125.GE4959@linux-1> References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> <1130259989.830.1.camel@eviltwin> <1130261079.830.9.camel@eviltwin> <20051025232801.GC4959@linux-1> <8a0c36780510251647i76b9e879v5097fe9c32c9731e@mail.gmail.com> <20051026004125.GE4959@linux-1> Message-ID: <8a0c36780510251916q64ead847pa28e22e7484e7ddb@mail.gmail.com> > > Which one is 9 the 50 or the 2120? > > Any suggestions on what program I can use to run these? Audacity will > > do LADSPA plugings but I rather something I can script. > > Filter 1: F = 50 Hz, A = 9 > Filter 2: F = 2120 Hz, A = 1 > > and add the two outputs. In light of your last post this is finally starting to make sense... Thanks. >The calibration only makes sense if you have a disc with pink noise >recorded on it - the filter itself (being numerical) will be exact. tracertek sells such a lp. Or at least they claim to. If nothing else such a lp would let me see how various cartridges perform on the player. So do you think there is merit in the whole scheme or is it all just hype? 1. Sample with a flat preamp at 24/96k. 2. fix all the snap and pop. 3. Apply your dual filters with pink correction. Salted to taste. -- Richard A. Smith From loki.davison at gmail.com Tue Oct 25 22:21:15 2005 From: loki.davison at gmail.com (Loki Davison) Date: Tue Oct 25 22:21:18 2005 Subject: [linux-audio-dev] Re: applying RIAA curves in software In-Reply-To: <20051026004125.GE4959@linux-1> References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> <1130259989.830.1.camel@eviltwin> <1130261079.830.9.camel@eviltwin> <20051025232801.GC4959@linux-1> <8a0c36780510251647i76b9e879v5097fe9c32c9731e@mail.gmail.com> <20051026004125.GE4959@linux-1> Message-ID: On 10/26/05, fons adriaensen wrote: > On Tue, Oct 25, 2005 at 06:47:51PM -0500, Richard Smith wrote: > > > Which one is 9 the 50 or the 2120? > > Any suggestions on what program I can use to run these? Audacity will > > do LADSPA plugings but I rather something I can script. > > Filter 1: F = 50 Hz, A = 9 > Filter 2: F = 2120 Hz, A = 1 > > and add the two outputs. > > The first one produces the first downward 'corner' at 50 Hz, and > the second one the downward corner at 2120 Hz. The combination of > the two gives the 'upward' corner at 50 * (1 + 9) / 1 = 500 Hz. > > -- > FA > In response to the noise remove and restoration, are you using decent needles btw? Though i still recommend a real preamp much more important are decent needles. Ortofon makes great stuff and it's what i use. I recommend any of the OM E series, they are (relatively) cheap and really nice. The OM 5 E works really well if it's just for recording use. I use the concord Elektro for normal use. Loki From smithbone at gmail.com Wed Oct 26 01:02:50 2005 From: smithbone at gmail.com (Richard Smith) Date: Wed Oct 26 01:02:53 2005 Subject: [linux-audio-dev] Re: applying RIAA curves in software In-Reply-To: References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> <1130259989.830.1.camel@eviltwin> <1130261079.830.9.camel@eviltwin> <20051025232801.GC4959@linux-1> <8a0c36780510251647i76b9e879v5097fe9c32c9731e@mail.gmail.com> <20051026004125.GE4959@linux-1> Message-ID: <8a0c36780510252202r1f5e4066odc82720b30aea71e@mail.gmail.com> > > In response to the noise remove and restoration, are you using decent > needles btw? Though i still recommend a real preamp much more Perhpas I need to find a pre-amp that can do both? Then I can do an A-B comparison. Using a RIAA pre-amp certainly makes it easier. > important are decent needles. Ortofon makes great stuff and it's what > i use. I recommend any of the OM E series, they are (relatively) cheap > and really nice. The OM 5 E works really well if it's just for > recording use. I use the concord Elektro for normal use. The turntable is an AIWA D60 but it hasn't been fired up in many years. I hope it still works. I found an old Realistic pre-amp and a JVC stereo unit that has phono inputs so I will check it in the near future. I have no idea what kind of needle is on the player. But thanks for the tip. Where are you buying these from? And do they also have needles for a 78? I read a page that said you can sample a 78 lp at a lower RPM and sample rate and then change the sample rate to make it sound right. Basically I cleared all this stuff out for my Dad and though it would be cool to put all his records on CD's. Most of it are 33s but theres one or 2 78s that belonged to my grandfather. -- Richard A. Smith From S.W.Harris at ecs.soton.ac.uk Wed Oct 26 06:04:22 2005 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed Oct 26 06:04:33 2005 Subject: [linux-audio-dev] applying RIAA curves in software In-Reply-To: <8a0c36780510251647i76b9e879v5097fe9c32c9731e@mail.gmail.com> References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> <1130259989.830.1.camel@eviltwin> <1130261079.830.9.camel@eviltwin> <20051025232801.GC4959@linux-1> <8a0c36780510251647i76b9e879v5097fe9c32c9731e@mail.gmail.com> Message-ID: <20051026100422.GD21073@login.ecs.soton.ac.uk> On Tue, Oct 25, 2005 at 06:47:51PM -0500, Richard Smith wrote: > > I don't want to bring down the great work done by Jamin's authors, but > > if fidelity is among you goals then using Jamin for RIAA equalisation > > would be a bad idea. > > Fidelity is in fact the primary goal. > > > > > It's quite simple to make an RIAA filter with for example two > > first order lowpass LADSPA plugins. Put them in parallel, set > > one to 50 Hz and the second to 2120 Hz. Mix the outputs in the > > ratio 9 to 1, and the result will be a *perfect* RIAA filter. > > Which one is 9 the 50 or the 2120? > Any suggestions on what program I can use to run these? Audacity will > do LADSPA plugings but I rather something I can script. ecasound? The option format is a bit obtuse, but youve only got to figure it out once, right :) - Steve From smithbone at gmail.com Wed Oct 26 09:06:05 2005 From: smithbone at gmail.com (Richard Smith) Date: Wed Oct 26 09:06:08 2005 Subject: [linux-audio-dev] applying RIAA curves in software In-Reply-To: <20051026100422.GD21073@login.ecs.soton.ac.uk> References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> <1130259989.830.1.camel@eviltwin> <1130261079.830.9.camel@eviltwin> <20051025232801.GC4959@linux-1> <8a0c36780510251647i76b9e879v5097fe9c32c9731e@mail.gmail.com> <20051026100422.GD21073@login.ecs.soton.ac.uk> Message-ID: <8a0c36780510260606h3822c672m66fcd9bc268e46f0@mail.gmail.com> > > ecasound? The option format is a bit obtuse, but youve only got to figure > it out once, right :) Looks like exactly what I need. The option stuff seems fairly intuitive so far. It has the -efl option which is a low pass filter built in but there isn't a gain setting. So I'm not quite sure on the best way to do the gains. I'm not sure that using the amplify -ea option will do the same thing. Is there are particular LADSPA low pass filter that would be best suited for this? -- Richard A. Smith From pcoccoli at gmail.com Wed Oct 26 13:35:56 2005 From: pcoccoli at gmail.com (Paul Coccoli) Date: Wed Oct 26 13:36:11 2005 Subject: [linux-audio-dev] Re: applying RIAA curves in software In-Reply-To: <8a0c36780510252202r1f5e4066odc82720b30aea71e@mail.gmail.com> References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> <1130259989.830.1.camel@eviltwin> <1130261079.830.9.camel@eviltwin> <20051025232801.GC4959@linux-1> <8a0c36780510251647i76b9e879v5097fe9c32c9731e@mail.gmail.com> <20051026004125.GE4959@linux-1> <8a0c36780510252202r1f5e4066odc82720b30aea71e@mail.gmail.com> Message-ID: <8d27a0610510261035x6e74330cy7631da163e6ebca6@mail.gmail.com> On 10/26/05, Richard Smith wrote: > The turntable is an AIWA D60 but it hasn't been fired up in many > years. I hope it still works. I found an old Realistic pre-amp and a > JVC stereo unit that has phono inputs so I will check it in the near > future. Fidelity is important, but you're not sure if the turntable you plan on using even works, let alone sounds good? Have you considered obtaining a good turntable? From smithbone at gmail.com Wed Oct 26 14:12:44 2005 From: smithbone at gmail.com (Richard Smith) Date: Wed Oct 26 14:12:49 2005 Subject: [linux-audio-dev] Re: applying RIAA curves in software In-Reply-To: <8d27a0610510261035x6e74330cy7631da163e6ebca6@mail.gmail.com> References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> <1130259989.830.1.camel@eviltwin> <1130261079.830.9.camel@eviltwin> <20051025232801.GC4959@linux-1> <8a0c36780510251647i76b9e879v5097fe9c32c9731e@mail.gmail.com> <20051026004125.GE4959@linux-1> <8a0c36780510252202r1f5e4066odc82720b30aea71e@mail.gmail.com> <8d27a0610510261035x6e74330cy7631da163e6ebca6@mail.gmail.com> Message-ID: <8a0c36780510261112j59d46513mdefb002654c24e13@mail.gmail.com> > > years. I hope it still works. I found an old Realistic pre-amp and a > > JVC stereo unit that has phono inputs so I will check it in the near > > future. > > Fidelity is important, but you're not sure if the turntable you plan > on using even works, let alone sounds good? Have you considered > obtaining a good turntable? Well when we bought it and through my high school years it was an excellent sounding turntable. My father normally buys good stuff. I was more refering to whatever mechanical drive system is in there. I don't remember if its belt driven or not. It's been stored nicely though so I don't suspect there will be any issues. I just haven't got that far yet. And yes if it dosen't seem up to the task then I'll have to start looking. -- Richard A. Smith From James at superbug.co.uk Thu Oct 27 17:23:33 2005 From: James at superbug.co.uk (James Courtier-Dutton) Date: Thu Oct 27 16:12:57 2005 Subject: [linux-audio-dev] Radio receiver. Message-ID: <43614555.7090302@superbug.co.uk> Hi, I want to plug a ham radio receiver into the sound card of my PC, and use the CPU of the PC to tidy up the signal, to hopefully make it more readable. One form of communications is called Morse Code, where a single tone is switched on and then off to pass a signal over the radio. I know it is easy to do band pass filters in Linux so that only the tone gets through, but the other really useful thing would be a noise filter. I was hoping that someone had already written a open source noise filter that I could use. If so, can someone point me to it, because I can't seem to find it on google. The noise filter needs to happen in real time, so ideally a plugin for ardour of something like that. James From fons.adriaensen at skynet.be Thu Oct 27 17:36:02 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Thu Oct 27 17:48:53 2005 Subject: [linux-audio-dev] Radio receiver. In-Reply-To: <43614555.7090302@superbug.co.uk> References: <43614555.7090302@superbug.co.uk> Message-ID: <20051027213602.GD4957@linux-1> On Thu, Oct 27, 2005 at 10:23:33PM +0100, James Courtier-Dutton wrote: > I want to plug a ham radio receiver into the sound card of my PC, and > use the CPU of the PC to tidy up the signal, to hopefully make it more > readable. > One form of communications is called Morse Code, where a single tone is > switched on and then off to pass a signal over the radio. > > I know it is easy to do band pass filters in Linux so that only the tone > gets through, but the other really useful thing would be a noise filter. There really is no such thing as a 'noise filter' - noise usually occupies the whole band, so a noise filter would remove all of the signal ! The only thing you can do is remove the noise in those parts of the spectrum you don't want to hear. For Morse, a bandpass will let through the tone you want and attenuate all the rest, so only the noise very close (in frequency) to the tone remains. This will improve the S/N ratio if there is wideband noise. There will be a tradeoff for the bandwidth of the filter you need. If you make it too narrow, the clear on/off edges will be smeared out and less clear, and it will also be difficult to track the signal if its frequency is not very stable. If you make it wider, more noise will get through. Also, human hearing is quite good at detecting a single frequency in a noisy background, so filtering will help only if there are other forms of interference (and that's of course quite likely on the SW bands). That's one of the reasons why Morse works quite well even with very primitive equipment. There must be a number of LADSPA plugins that do exactly what you need. Have a look at http://www.ladspa.org. As a host, you can use jackrack, AMS, ecasound, and many others. -- FA From ix at replic.net Thu Oct 27 18:20:06 2005 From: ix at replic.net (carmen) Date: Thu Oct 27 18:20:05 2005 Subject: [linux-audio-dev] Radio receiver. In-Reply-To: <20051027213602.GD4957@linux-1> References: <43614555.7090302@superbug.co.uk> <20051027213602.GD4957@linux-1> Message-ID: <20051027222006.GA4373@replic.net> > > There really is no such thing as a 'noise filter' - noise usually > occupies the whole band, so a noise filter would remove all of the > signal ! there is definitely such thing as a noise filter. i know i had a couple dozen VSTs in my 'filter/noise' folder on windows... whether they were noise-reduction filters (like you might see in photoshop, or FFT based (take a snapshot of a quiet portion and use as a convolution mask) depended on the plugin > The only thing you can do is remove the noise in those parts > of the spectrum you don't want to hear. > > For Morse, a bandpass will let through the tone you want and attenuate for morse, theres plenty of ham-radio utils on linux.. for morse, you could easily resynthesize it as a pure sine-tone with a simple pd patch, getting rid of all the noise..although a combination narrow-bandpass and gate would work wonders (and be done w/ pure LADSPA) you also might want to check out GNURadio. which allows you much more control by not limiting yourself to the 'decoded' RF data as audio.. c From taybin at earthlink.net Thu Oct 27 18:44:30 2005 From: taybin at earthlink.net (Taybin Rutkin) Date: Thu Oct 27 18:44:34 2005 Subject: [linux-audio-dev] ladspa problem on OSX 10.4 figured out Message-ID: <222C20BB-54D4-462B-89B5-A2BD1680F971@earthlink.net> On 10.4, Apple removed the deprecated dlopen() mechanism of using _init() and _fini(). Instead, function attributes should be used. These have been supported in gcc since at least 2.9x. So instead of: void _init() {} void _fini() {} you should use: __attribute__((constructor)) void init() {} __attribute__((destructor)) void fini() {} Thanks, Taybin From taybin at earthlink.net Thu Oct 27 18:44:30 2005 From: taybin at earthlink.net (Taybin Rutkin) Date: Thu Oct 27 18:46:24 2005 Subject: [linux-audio-dev] [ardour-dev] ladspa problem on OSX 10.4 figured out Message-ID: <222C20BB-54D4-462B-89B5-A2BD1680F971@earthlink.net> On 10.4, Apple removed the deprecated dlopen() mechanism of using _init() and _fini(). Instead, function attributes should be used. These have been supported in gcc since at least 2.9x. So instead of: void _init() {} void _fini() {} you should use: __attribute__((constructor)) void init() {} __attribute__((destructor)) void fini() {} Thanks, Taybin _______________________________________________ ardour-dev mailing list ardour-dev@lists.ardour.org http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. From taybin at earthlink.net Thu Oct 27 18:44:30 2005 From: taybin at earthlink.net (Taybin Rutkin) Date: Thu Oct 27 18:46:35 2005 Subject: [linux-audio-dev] [ardour-users] ladspa problem on OSX 10.4 figured out Message-ID: <222C20BB-54D4-462B-89B5-A2BD1680F971@earthlink.net> On 10.4, Apple removed the deprecated dlopen() mechanism of using _init() and _fini(). Instead, function attributes should be used. These have been supported in gcc since at least 2.9x. So instead of: void _init() {} void _fini() {} you should use: __attribute__((constructor)) void init() {} __attribute__((destructor)) void fini() {} Thanks, Taybin _______________________________________________ ardour-users mailing list ardour-users@lists.ardour.org http://lists.ardour.org/listinfo.cgi/ardour-users-ardour.org This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. From taybin at earthlink.net Thu Oct 27 18:44:30 2005 From: taybin at earthlink.net (Taybin Rutkin) Date: Thu Oct 27 19:01:03 2005 Subject: [linux-audio-dev] [ardour-users] [ardour-dev] ladspa problem on OSX 10.4 figured out Message-ID: <222C20BB-54D4-462B-89B5-A2BD1680F971@earthlink.net> On 10.4, Apple removed the deprecated dlopen() mechanism of using _init() and _fini(). Instead, function attributes should be used. These have been supported in gcc since at least 2.9x. So instead of: void _init() {} void _fini() {} you should use: __attribute__((constructor)) void init() {} __attribute__((destructor)) void fini() {} Thanks, Taybin _______________________________________________ ardour-dev mailing list ardour-dev@lists.ardour.org http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. _______________________________________________ ardour-users mailing list ardour-users@lists.ardour.org http://lists.ardour.org/listinfo.cgi/ardour-users-ardour.org This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. From taybin at earthlink.net Thu Oct 27 18:44:30 2005 From: taybin at earthlink.net (Taybin Rutkin) Date: Thu Oct 27 19:01:08 2005 Subject: [linux-audio-dev] [ardour-dev] [ardour-users] ladspa problem on OSX 10.4 figured out Message-ID: <222C20BB-54D4-462B-89B5-A2BD1680F971@earthlink.net> On 10.4, Apple removed the deprecated dlopen() mechanism of using _init() and _fini(). Instead, function attributes should be used. These have been supported in gcc since at least 2.9x. So instead of: void _init() {} void _fini() {} you should use: __attribute__((constructor)) void init() {} __attribute__((destructor)) void fini() {} Thanks, Taybin _______________________________________________ ardour-users mailing list ardour-users@lists.ardour.org http://lists.ardour.org/listinfo.cgi/ardour-users-ardour.org This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. _______________________________________________ ardour-dev mailing list ardour-dev@lists.ardour.org http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. From fons.adriaensen at skynet.be Thu Oct 27 20:16:16 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Thu Oct 27 20:12:24 2005 Subject: [linux-audio-dev] Radio receiver. In-Reply-To: <20051027222006.GA4373@replic.net> References: <43614555.7090302@superbug.co.uk> <20051027213602.GD4957@linux-1> <20051027222006.GA4373@replic.net> Message-ID: <20051028001616.GE4957@linux-1> On Thu, Oct 27, 2005 at 10:20:06PM +0000, carmen wrote: > > There really is no such thing as a 'noise filter' - noise usually > > occupies the whole band, so a noise filter would remove all of the > > signal ! > > there is definitely such thing as a noise filter. i know i had a > couple dozen VSTs in my 'filter/noise' folder on windows... A filter in the usual (audio) sense is a linear process that has a frequency dependent gain. It will have the same effect on any signal, be it noise or discrete tones. In that sense, a 'noise filter', supposedly acting only on a continuous spectrum (noise) does not exist. There may of course exists things called 'noise filter', and having the effect of reducing unwanted noise in some application. These could be just linear filters attenuating what their designer considered to be the unwanted part of the spectrum. But that is application specific - one (wo)man's noise is another one's signal. If you are recording an interview at the seaside, the waves are noise. If I'm trying to capture the sound of sea, people's voices are 'noise'. There is no filter that can know what either of us wants. So we will both use some filter adapted to our needs, and call that a 'noise filter'. There are also processors that analyse a signal and remove those parts of the spectrum that have little energy, or the parts that correlate with a reference signal. The removed part would be noise in many cases. But these are not filters in the usual sense. >From my experience on the short waves, it's not noise in the normal sense (i.e. a continuous hiss) that makes reading Morse difficult - we can quite easily 'remove' that mentally. It's other forms of interference, and filtering can help to reduce these. You could indeed make some processor that would regenerate a Morse signal (and also decode it on the fly). But you would have a difficult time trying to outperform human hearing in that application. For example, our hearing mechanisms are not limited by the usual 'uncertainty principle' that limits the product of resolution in time and in frequency, they can do much better. -- FA From mista.tapas at gmx.net Thu Oct 27 21:19:04 2005 From: mista.tapas at gmx.net (Florian Schmidt) Date: Thu Oct 27 21:19:09 2005 Subject: [linux-audio-dev] Radio receiver. In-Reply-To: <20051028001616.GE4957@linux-1> References: <43614555.7090302@superbug.co.uk> <20051027213602.GD4957@linux-1> <20051027222006.GA4373@replic.net> <20051028001616.GE4957@linux-1> Message-ID: <20051028031904.57b5fa8e@mango.fruits.de> On Fri, 28 Oct 2005 02:16:16 +0200 fons adriaensen wrote: > You could indeed make some processor that would regenerate > a Morse signal (and also decode it on the fly). But you would > have a difficult time trying to outperform human hearing in > that application. For example, our hearing mechanisms are not > limited by the usual 'uncertainty principle' that limits the > product of resolution in time and in frequency, they can do > much better. Interesting subject. Got any pointers on the subject. I suppose that the ear, especially in composite signals might be able to determine relative timing differences with a very high precision (even for very low freq signals). Flo -- Palimm Palimm! http://tapas.affenbande.org From loki.davison at gmail.com Thu Oct 27 22:01:04 2005 From: loki.davison at gmail.com (Loki Davison) Date: Thu Oct 27 22:01:06 2005 Subject: [linux-audio-dev] Re: applying RIAA curves in software In-Reply-To: <8a0c36780510252202r1f5e4066odc82720b30aea71e@mail.gmail.com> References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> <1130259989.830.1.camel@eviltwin> <1130261079.830.9.camel@eviltwin> <20051025232801.GC4959@linux-1> <8a0c36780510251647i76b9e879v5097fe9c32c9731e@mail.gmail.com> <20051026004125.GE4959@linux-1> <8a0c36780510252202r1f5e4066odc82720b30aea71e@mail.gmail.com> Message-ID: On 10/26/05, Richard Smith wrote: > > > > In response to the noise remove and restoration, are you using decent > > needles btw? Though i still recommend a real preamp much more > > Perhpas I need to find a pre-amp that can do both? Then I can do an > A-B comparison. Using a RIAA pre-amp certainly makes it easier. > > > important are decent needles. Ortofon makes great stuff and it's what > > i use. I recommend any of the OM E series, they are (relatively) cheap > > and really nice. The OM 5 E works really well if it's just for > > recording use. I use the concord Elektro for normal use. > > The turntable is an AIWA D60 but it hasn't been fired up in many > years. I hope it still works. I found an old Realistic pre-amp and a > JVC stereo unit that has phono inputs so I will check it in the near > future. > I have no idea what kind of needle is on the player. But thanks for > the tip. Where are you buying these from? And do they also have > needles for a 78? > > I read a page that said you can sample a 78 lp at a lower RPM and > sample rate and then change the sample rate to make it sound right. > > Basically I cleared all this stuff out for my Dad and though it would > be cool to put all his records on CD's. Most of it are 33s but theres > one or 2 78s that belonged to my grandfather. > > -- > Richard A. Smith > > ohh... AIWA D60 mmm. Well, it's not really what i'd call a famously decent brand. Not that i no anything about hi-fi turntables but my technics sl1200's are quite nice ;-) though probably not the price range or style your interested in. A decent turntable will help a lot, especially if that one is an arse to mount standard needles/headshells on. Ortofon have specific 78 needles though it means extra cost, as you have to buy a 78 and a normal needle. Changing the speed in software seems like it would be horrible to me. Buy or borrow a decent turntable. A few modern ones can play all three, for instance stuff from stanton. Though don't touch there needles, they are crap. To the question where am i buying these from, my local record shop or online. Though if you're not in AU it might not be handy ;-) Loki From sbenno at gardena.net Fri Oct 28 07:26:07 2005 From: sbenno at gardena.net (Benno Senoner) Date: Fri Oct 28 07:22:24 2005 Subject: [linux-audio-dev] Latency and feedback problems: soundcard with live microphone pass-thru, optimal solution ? Message-ID: <43620ACF.9070004@gardena.net> Hi all, I would like to route a microphone through a sound card and back to powerful amplified speakers. As we know in analog PA gear you have the microphone feedback problem (usually it comes in form of high pitched whistle sounds). But if I route a mic from into the soundcard and out to the speakers, there will be a small delay due to the audio card buffers. Even if it's only a few msecs it makes the problem much worse than in the case of analogue gear because the feedback sound will come in chunks that's one audio card buffer at time. For example if I use 64 samples per buffer which gives me acceptable latency for a live singer, the feedback noise could possibly generate a much lower pitched signal/interference (I assume something like 44100/64 Hz) which is I think not easy to filter out compared to the high pitched feedback (is in the latter case sufficient to cut some high frequencies using an EQ ?). How can one solve the feedback problem in case of mic to speaker delays of let's say 5-10msecs ? Is an echo canceller algorithm needed ? If yes does this compromise the quality of the input signal (the singer). I think this is a very interesting topic and it would be cool if knowledgable people could come up with topics and ideas. (for example people that are good at DSP, room correction etc, like Fons A. etc). PS: I know that cards like DELTA 1010 and others (RME) can do zero latency monitoring (hardware pass-thru) but I'd prefer a software based routing since you can apply effects and stuff before forwarding the output. thanks for infos and toughts Benno http://www.linuxsampler.org From james at dis-dot-dat.net Fri Oct 28 08:49:25 2005 From: james at dis-dot-dat.net (james@dis-dot-dat.net) Date: Fri Oct 28 08:38:24 2005 Subject: [linux-audio-dev] Cheesetracker patch Message-ID: <20051028124925.GF10207@phlunky.Belkin> I've written a simple patch to add info on the real-time capabilities of LADSPA plugins in CheeseTracker. I know I seem to be the only CheeseTracker user on the lists, but just in case... http://blog.dis-dot-dat.net/2005/10/cheesetracker-patch.html -- "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 dmills at spamblock.demon.co.uk Fri Oct 28 14:07:55 2005 From: dmills at spamblock.demon.co.uk (Dan Mills) Date: Fri Oct 28 14:08:05 2005 Subject: [linux-audio-dev] Latency and feedback problems: soundcard with live microphone pass-thru, optimal solution ? In-Reply-To: <43620ACF.9070004@gardena.net> References: <43620ACF.9070004@gardena.net> Message-ID: <200510281907.55370.dmills@spamblock.demon.co.uk> On Friday 28 October 2005 12:26, Benno Senoner wrote: > Hi all, > I would like to route a microphone through a sound card and back to > powerful amplified speakers. > > As we know in analog PA gear you have the microphone feedback problem > (usually it comes in form > of high pitched whistle sounds). > > But if I route a mic from into the soundcard and out to the speakers, > there will be a small delay > due to the audio card buffers. Even if it's only a few msecs it makes > the problem much worse > than in the case of analogue gear because the feedback sound will come > in chunks that's one audio card buffer at time. > For example if I use 64 samples per buffer which gives me acceptable > latency for a live singer, the feedback noise > could possibly generate a much lower pitched signal/interference (I > assume something like 44100/64 Hz) which is I think > not easy to filter out compared to the high pitched feedback (is in the > latter case sufficient to cut some high frequencies using an EQ ?). > > How can one solve the feedback problem in case of mic to speaker delays > of let's say 5-10msecs ? > Is an echo canceller algorithm needed ? If yes does this compromise the > quality of the input signal (the singer). Actually applying a little delay is fairly standard in conventional PA as well. Consider that 10ms is roughly 10 feet of acoustic delay, and that you usually want the direct sound to arrive at the audience a little (10 - 30ms) before the sound from the PA as this really helps localisation. Thus even on a small stage you may be delaying the FOH by 40ms or so to help localise the singer. Monitors are a little different obviously, but even there, it just is not a problem at these levels. As for feedback, you notch it out with a graphic (or better a parametric), the same as always. In fact it turns out that a constant delay makes the feedback slower to build, and may alter the exact frequency slightly (by adding a constant phase shift at any given frequency), but does not radically change the overall system response in the way you think. Just about every modern PA system has at least one stage of AD-DA conversion (Think things like the digital crossovers so common in modern systems) which probably introduces 5ms or so right there. Regards, Dan. From smithbone at gmail.com Fri Oct 28 14:58:19 2005 From: smithbone at gmail.com (Richard Smith) Date: Fri Oct 28 14:58:22 2005 Subject: [linux-audio-dev] Re: applying RIAA curves in software In-Reply-To: References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> <1130259989.830.1.camel@eviltwin> <1130261079.830.9.camel@eviltwin> <20051025232801.GC4959@linux-1> <8a0c36780510251647i76b9e879v5097fe9c32c9731e@mail.gmail.com> <20051026004125.GE4959@linux-1> <8a0c36780510252202r1f5e4066odc82720b30aea71e@mail.gmail.com> Message-ID: <8a0c36780510281158h60d2a364v745fad76e0a03b26@mail.gmail.com> On 10/27/05, Loki Davison wrote: > ohh... AIWA D60 mmm. Well, it's not really what i'd call a famously > decent brand. Ok well maybe my fathers choice wan't so great then. :) I guess if my source isn't so good then all this other stuff my just be overkill. I'll just have to get it all setup and let my ear decide. Which brings me to my next post... -- Richard A. Smith From smithbone at gmail.com Fri Oct 28 14:58:28 2005 From: smithbone at gmail.com (Richard Smith) Date: Fri Oct 28 14:58:29 2005 Subject: [linux-audio-dev] jack and S24_3BE Message-ID: <8a0c36780510281158v20818ba6h4424772005f63d07@mail.gmail.com> Apparently my soundcard selecting skills are poor. I thought that a USB card would be nice so that I could use it on different machines. The M-Audio Audiophile USB had good specs and usb audio was supposed to work ok. After much googleing I seem to have the device recording 24/96k audio but its only with arecord. Trying to start jack (V 0.99) it whines that my format is not supported. And if I choose plughw I get XRUNS. How much work will it be to get jack to work with S24_3BE? -- Richard A. Smith From paul at linuxaudiosystems.com Fri Oct 28 15:54:20 2005 From: paul at linuxaudiosystems.com (Paul Davis) Date: Fri Oct 28 15:53:54 2005 Subject: [linux-audio-dev] jack and S24_3BE In-Reply-To: <8a0c36780510281158v20818ba6h4424772005f63d07@mail.gmail.com> References: <8a0c36780510281158v20818ba6h4424772005f63d07@mail.gmail.com> Message-ID: <1130529260.16535.34.camel@localhost.localdomain> On Fri, 2005-10-28 at 13:58 -0500, Richard Smith wrote: > Apparently my soundcard selecting skills are poor. > > I thought that a USB card would be nice so that I could use it on > different machines. The M-Audio Audiophile USB had good specs and usb > audio was supposed to work ok. > > After much googleing I seem to have the device recording 24/96k audio > but its only with arecord. > > Trying to start jack (V 0.99) it whines that my format is not > supported. And if I choose plughw I get XRUNS. > > How much work will it be to get jack to work with S24_3BE? i believe that the patch already exists. From smithbone at gmail.com Fri Oct 28 16:09:43 2005 From: smithbone at gmail.com (Richard Smith) Date: Fri Oct 28 16:09:46 2005 Subject: [linux-audio-dev] jack and S24_3BE In-Reply-To: <1130529260.16535.34.camel@localhost.localdomain> References: <8a0c36780510281158v20818ba6h4424772005f63d07@mail.gmail.com> <1130529260.16535.34.camel@localhost.localdomain> Message-ID: <8a0c36780510281309m2ce6a258mff18c52a78c06a1@mail.gmail.com> > > i believe that the patch already exists. Sweet. Where? I googled for jack & S24_3BE but nothing showed up. -- Richard A. Smith From paul at linuxaudiosystems.com Fri Oct 28 16:24:13 2005 From: paul at linuxaudiosystems.com (Paul Davis) Date: Fri Oct 28 16:22:22 2005 Subject: [linux-audio-dev] jack and S24_3BE In-Reply-To: <8a0c36780510281309m2ce6a258mff18c52a78c06a1@mail.gmail.com> References: <8a0c36780510281158v20818ba6h4424772005f63d07@mail.gmail.com> <1130529260.16535.34.camel@localhost.localdomain> <8a0c36780510281309m2ce6a258mff18c52a78c06a1@mail.gmail.com> Message-ID: <1130531053.16535.36.camel@localhost.localdomain> On Fri, 2005-10-28 at 15:09 -0500, Richard Smith wrote: > > > > i believe that the patch already exists. > > Sweet. Where? I googled for jack & S24_3BE but nothing showed up. > http://sourceforge.net/tracker/?group_id=39687&atid=425939 From rlrevell at joe-job.com Fri Oct 28 16:53:35 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Fri Oct 28 16:54:53 2005 Subject: [linux-audio-dev] jack and S24_3BE In-Reply-To: <1130531053.16535.36.camel@localhost.localdomain> References: <8a0c36780510281158v20818ba6h4424772005f63d07@mail.gmail.com> <1130529260.16535.34.camel@localhost.localdomain> <8a0c36780510281309m2ce6a258mff18c52a78c06a1@mail.gmail.com> <1130531053.16535.36.camel@localhost.localdomain> Message-ID: <1130532816.4363.133.camel@mindpipe> On Fri, 2005-10-28 at 16:24 -0400, Paul Davis wrote: > On Fri, 2005-10-28 at 15:09 -0500, Richard Smith wrote: > > > > > > i believe that the patch already exists. > > > > Sweet. Where? I googled for jack & S24_3BE but nothing showed up. > > > > http://sourceforge.net/tracker/?group_id=39687&atid=425939 > What happened to the old Mantis bug tracker? Lee From paul at linuxaudiosystems.com Fri Oct 28 17:00:54 2005 From: paul at linuxaudiosystems.com (Paul Davis) Date: Fri Oct 28 16:59:19 2005 Subject: [linux-audio-dev] jack and S24_3BE In-Reply-To: <1130532816.4363.133.camel@mindpipe> References: <8a0c36780510281158v20818ba6h4424772005f63d07@mail.gmail.com> <1130529260.16535.34.camel@localhost.localdomain> <8a0c36780510281309m2ce6a258mff18c52a78c06a1@mail.gmail.com> <1130531053.16535.36.camel@localhost.localdomain> <1130532816.4363.133.camel@mindpipe> Message-ID: <1130533254.16535.40.camel@localhost.localdomain> On Fri, 2005-10-28 at 16:53 -0400, Lee Revell wrote: > On Fri, 2005-10-28 at 16:24 -0400, Paul Davis wrote: > > On Fri, 2005-10-28 at 15:09 -0500, Richard Smith wrote: > > > > > > > > i believe that the patch already exists. > > > > > > Sweet. Where? I googled for jack & S24_3BE but nothing showed up. > > > > > > > http://sourceforge.net/tracker/?group_id=39687&atid=425939 > > > > What happened to the old Mantis bug tracker? its not a bug, i guess :) From rlrevell at joe-job.com Fri Oct 28 17:00:31 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Fri Oct 28 17:01:49 2005 Subject: [linux-audio-dev] jack and S24_3BE In-Reply-To: <1130531053.16535.36.camel@localhost.localdomain> References: <8a0c36780510281158v20818ba6h4424772005f63d07@mail.gmail.com> <1130529260.16535.34.camel@localhost.localdomain> <8a0c36780510281309m2ce6a258mff18c52a78c06a1@mail.gmail.com> <1130531053.16535.36.camel@localhost.localdomain> Message-ID: <1130533231.4363.139.camel@mindpipe> On Fri, 2005-10-28 at 16:24 -0400, Paul Davis wrote: > On Fri, 2005-10-28 at 15:09 -0500, Richard Smith wrote: > > > > > > i believe that the patch already exists. > > > > Sweet. Where? I googled for jack & S24_3BE but nothing showed up. > > > > http://sourceforge.net/tracker/?group_id=39687&atid=425939 > > > "hw:1,0 is iec958 for capture and analogue/headphone for playback hw:1,1 is analogue for capture and iec958 for playback" Now this is just silly. We should probably seize the opportunity to fix this in the ALSA driver (or alsa-lib) now, as there seem to be very few working setups to break. I don't want to repeat the emu10k1 multichannel device numbering snafu. Lee From shulmang at colorado.edu Fri Oct 28 20:35:11 2005 From: shulmang at colorado.edu (Garett Shulman) Date: Fri Oct 28 20:36:45 2005 Subject: [linux-audio-dev] [ANN] WhySynth DSSI softsynth In-Reply-To: <5e7023ac61a6a4a7e22a2b2d55e6d473@jps.net> References: <5fde3b6f7456e5db1800b13c7d35671e@jps.net> <1128835809.26780.9.camel@c80-216-125-193.cm-upc.chello.se> <1128868841.9616.90.camel@c80-216-125-193.cm-upc.chello.se> <1128869959.8801.23.camel@c213-100-50-8.swipnet.se> <1128877274.10201.4.camel@c80-216-125-193.cm-upc.chello.se> <1128878570.12415.62.camel@dhin> <1128881889.10201.15.camel@c80-216-125-193.cm-upc.chello.se> <5e7023ac61a6a4a7e22a2b2d55e6d473@jps.net> Message-ID: <4362C3BF.7070303@colorado.edu> WOW. Whysynth is very cool. For subtractive synthesis on linux it seems very frugal on cpu cycles. Nice. I haven't fooled much with the other osciliator types but look forward to. I followed the suggestion (I think :) ) at the bottum of this email regarding assigning various midi controllers to various synthesis parameters. I added case Y_PORT_VCF1_FREQUENCY: return DSSI_CC(0x00); to y_get_midi_controller at line 633 of dssp_synth.c in an attempt to connect a continous controller that alsa sequencer shows as parameter 0. However I get no varience of cutoff frequency. I'm quite certain that param 0 cc messages are getting at least to jack-dssi-host. Can you think of something I might be missing, here? Thanks! -Garett Sean Bolton wrote: > On Oct 9, 2005, at 11:18 AM, Jens M Andreasen wrote: > >> Let Bolton speak for himself, please. Gentlemen please ... > > > Bolton speaks for himself, thusly: > > On Oct 8, 2005, at 10:30 PM, Jens M Andreasen wrote: > >> Whoaa! >> >> Some really impressive specs. Are you trying to corner the market as in >> "the only soffsynth you'll ever, ever need!!" :) > > > Right-o, as in Guinness is the only beer you'll ever, ever need, > and Gentoo is the only distro you'll ever, ever need!! > >> Do you have some rough statistics on number of voices/gigahertz? > > > That depends on the patch. With a simple two-oscillator, single filter > patch playing 16 voices, my 933MHz Pentium 3 barely breaks a sweat > (17% CPU according to top, 22% according to qjackctl). One the other > hand, with the most expensive patch I can think of, it maxes out at > only two voices. > > On Oct 9, 2005, at 3:33 AM, Jens M Andreasen wrote: > >>> WhySynth, as in (I sometimes ask), "_why_ am I working on another >>> softsynth instead of on paying gigs?" (Following my bliss? >>> Addiction? One last shot at misspent youth?) >> >> >> Heh :) Once you have done one, you are addicted. >> >> This is not nescessarily a bad thing. Laying out a synthesizer requires >> as much consideration as laying out say; the main theme for film-score. >> A few cycles of scrapping and reinventing is expected, perhaps even >> required. > > > Yeah, addicted is right. I code in a very experimental, improvisational > way. If I could manage only a _few_ cycles of scrapping and reinventing, > I would be much more efficient! > > On Oct 9, 2005, at 8:45 AM, derek holzer wrote: > >> Very nice, hours of fun in there to be sure. But how can you handle >> MIDI bindings? For example, to control one of the filter resonance >> knobs rather than just the MIDI note/pitchwheel in? > > > That's one of the things I haven't done yet, and one of the awkward > parts of DSSI. Several people (two?) have pointed out that DSSI > provides for binding MIDI CCs/NRPNs to ports ('knobs'), but the plugin > must declare these bindings to the host before the GUI gets a chance > to run. So you either have to make them hard-coded, or require > the user to exit-and-restart in order to implement custom bindings. > If you wanna hard-code your own bindings, I'll tell you how.... > (Just look in src/dssp_synth.c for the Y_PORT_GLIDE_TIME binding > to the MIDI portamento time CC, follow the example, and recompile :-/) > > Thanks, everyone, for your comments and questions, > > -Sean From larsl at users.sourceforge.net Fri Oct 28 20:56:34 2005 From: larsl at users.sourceforge.net (Lars Luthman) Date: Fri Oct 28 20:55:22 2005 Subject: [linux-audio-dev] [ANN] WhySynth DSSI softsynth In-Reply-To: <4362C3BF.7070303@colorado.edu> References: <5fde3b6f7456e5db1800b13c7d35671e@jps.net> <1128835809.26780.9.camel@c80-216-125-193.cm-upc.chello.se> <1128868841.9616.90.camel@c80-216-125-193.cm-upc.chello.se> <1128869959.8801.23.camel@c213-100-50-8.swipnet.se> <1128877274.10201.4.camel@c80-216-125-193.cm-upc.chello.se> <1128878570.12415.62.camel@dhin> <1128881889.10201.15.camel@c80-216-125-193.cm-upc.chello.se> <5e7023ac61a6a4a7e22a2b2d55e6d473@jps.net> <4362C3BF.7070303@colorado.edu> Message-ID: <1130547394.8173.12.camel@c213-100-50-8.swipnet.se> On Fri, 2005-10-28 at 18:35 -0600, Garett Shulman wrote: > WOW. Whysynth is very cool. For subtractive synthesis on linux it seems > very frugal on cpu cycles. Nice. I haven't fooled much with the other > osciliator types but look forward to. I followed the suggestion (I think > :) ) at the bottum of this email regarding assigning various midi > controllers to various synthesis parameters. I added > case Y_PORT_VCF1_FREQUENCY: > return DSSI_CC(0x00); > to y_get_midi_controller at line 633 of dssp_synth.c in an attempt to > connect a continous controller that alsa sequencer shows as parameter 0. > However I get no varience of cutoff frequency. I'm quite certain that > param 0 cc messages are getting at least to jack-dssi-host. Can you > think of something I might be missing, here? You managed to hit one of the two CC numbers that DSSI plugins are not allowed to use to control parameters. CC 0 and 32 (Bank select MSB and Bank select LSB) are interpreted by a DSSI host as "change program bank", and instead of sending the CC events directly to the plugin it should use select_program() to select a new program bank in the plugin. If you use any other CC number it should work. -- Lars Luthman PGP key: http://www.d.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- 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/20051029/0dd2d673/attachment.bin From jussi.laako at pp.inet.fi Sat Oct 29 08:10:50 2005 From: jussi.laako at pp.inet.fi (Jussi Laako) Date: Sat Oct 29 08:10:55 2005 Subject: [linux-audio-dev] applying RIAA curves in software In-Reply-To: <20051026004125.GE4959@linux-1> References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> <1130259989.830.1.camel@eviltwin> <1130261079.830.9.camel@eviltwin> <20051025232801.GC4959@linux-1> <8a0c36780510251647i76b9e879v5097fe9c32c9731e@mail.gmail.com> <20051026004125.GE4959@linux-1> Message-ID: <1130587850.8551.1.camel@vaarlahti.uworld> On Wed, 2005-10-26 at 02:41 +0200, fons adriaensen wrote: > On Tue, Oct 25, 2005 at 06:47:51PM -0500, Richard Smith wrote: > > > Which one is 9 the 50 or the 2120? > > Any suggestions on what program I can use to run these? Audacity will > > do LADSPA plugings but I rather something I can script. > > Filter 1: F = 50 Hz, A = 9 > Filter 2: F = 2120 Hz, A = 1 > > and add the two outputs. >From quality point of view, at least I would recommend using IIR filters for this... Unless digital'ish sound is preferred... ;) -- Jussi Laako From smithbone at gmail.com Sat Oct 29 10:24:11 2005 From: smithbone at gmail.com (Richard Smith) Date: Sat Oct 29 10:24:14 2005 Subject: [linux-audio-dev] applying RIAA curves in software In-Reply-To: <1130587850.8551.1.camel@vaarlahti.uworld> References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> <1130259989.830.1.camel@eviltwin> <1130261079.830.9.camel@eviltwin> <20051025232801.GC4959@linux-1> <8a0c36780510251647i76b9e879v5097fe9c32c9731e@mail.gmail.com> <20051026004125.GE4959@linux-1> <1130587850.8551.1.camel@vaarlahti.uworld> Message-ID: <8a0c36780510290724o480db2b5i15d2a66a4cf233af@mail.gmail.com> > >From quality point of view, at least I would recommend using IIR filters > for this... > > Unless digital'ish sound is preferred... ;) Fons sent me a LADSPA and native jack filter that he wrote that will do this. I haven't tested it yet. When I finally get jack up and running on my system I'll try it out. -- Richard A. Smith From fons.adriaensen at skynet.be Sat Oct 29 10:41:28 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Sat Oct 29 10:36:31 2005 Subject: [linux-audio-dev] applying RIAA curves in software In-Reply-To: <1130587850.8551.1.camel@vaarlahti.uworld> References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> <1130259989.830.1.camel@eviltwin> <1130261079.830.9.camel@eviltwin> <20051025232801.GC4959@linux-1> <8a0c36780510251647i76b9e879v5097fe9c32c9731e@mail.gmail.com> <20051026004125.GE4959@linux-1> <1130587850.8551.1.camel@vaarlahti.uworld> Message-ID: <20051029144128.GA4956@linux-1> On Sat, Oct 29, 2005 at 03:10:50PM +0300, Jussi Laako wrote: > On Wed, 2005-10-26 at 02:41 +0200, fons adriaensen wrote: > > > Filter 1: F = 50 Hz, A = 9 > > Filter 2: F = 2120 Hz, A = 1 > > > > and add the two outputs. > > >From quality point of view, at least I would recommend using IIR filters > for this... Could you explain ? The (trivially simple) first order lowpass sections will have the correct amplitude _and_ phase response. > Unless digital'ish sound is preferred... ;) What the **** is "digital'ish" sound, and how is it relevant here ? -- FA From smithbone at gmail.com Sat Oct 29 11:10:40 2005 From: smithbone at gmail.com (Richard Smith) Date: Sat Oct 29 11:10:48 2005 Subject: [linux-audio-dev] Re: applying RIAA curves in software In-Reply-To: References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> <1130259989.830.1.camel@eviltwin> <1130261079.830.9.camel@eviltwin> <20051025232801.GC4959@linux-1> <8a0c36780510251647i76b9e879v5097fe9c32c9731e@mail.gmail.com> <20051026004125.GE4959@linux-1> <8a0c36780510252202r1f5e4066odc82720b30aea71e@mail.gmail.com> Message-ID: <8a0c36780510290810p2b801b2n67a653eefe7cd80f@mail.gmail.com> > software seems like it would be horrible to me. Buy or borrow a decent > turntable. A few modern ones can play all three, for instance stuff > from stanton. Though don't touch there needles, they are crap. To This may be getting too OT so let me know if I need go off-list. I've been looking at some turntables from Stanton. How do the DJ tables fair? Fex. The stanton STR8-100 looks sweet. It has S-PDIF, phono, and line outputs and it will play 78's. I can get a used one off of ebay for $100 bucks or so. Most of the other decks I saw are just a bit out of my range. That lets me do a flat preamp if I choose to mess with all that, but I can also just use the S-PDIF or Line with the built in RIAA. And 78's without resorting to software correction. I didn't realize the S/N ratio on turntables was so low. What would those who on have messed with this before consider acceptable? -- Richard A. Smith From jens.andreasen at chello.se Sat Oct 29 11:16:53 2005 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Sat Oct 29 11:17:03 2005 Subject: [linux-audio-dev] Latency and feedback problems: soundcard with live microphone pass-thru, optimal solution ? In-Reply-To: <43620ACF.9070004@gardena.net> References: <43620ACF.9070004@gardena.net> Message-ID: <1130599013.18315.9.camel@c80-216-125-193.cm-upc.chello.se> Benno! There are some missing parameters in your description, but I will assumme your problem arises out of the monitor-mix rather than the house-mix. Suggestion: Invert the phase of the offending microphone. This should kill dead feadback in the frequency-band currently annoying you. The downside is that it will also emphasize other frequency-bands that did not pose a problem before. The theory is that those resonanses will be minor relative to your current major problem. mvh // Jens M Andreasen On Fri, 2005-10-28 at 13:26 +0200, Benno Senoner wrote: > Hi all, > I would like to route a microphone through a sound card and back to > powerful amplified speakers. > > As we know in analog PA gear you have the microphone feedback problem > (usually it comes in form > of high pitched whistle sounds). > > But if I route a mic from into the soundcard and out to the speakers, > there will be a small delay > due to the audio card buffers. Even if it's only a few msecs it makes > the problem much worse > than in the case of analogue gear because the feedback sound will come > in chunks that's one audio card buffer at time. > For example if I use 64 samples per buffer which gives me acceptable > latency for a live singer, the feedback noise > could possibly generate a much lower pitched signal/interference (I > assume something like 44100/64 Hz) which is I think > not easy to filter out compared to the high pitched feedback (is in the > latter case sufficient to cut some high frequencies using an EQ ?). > > How can one solve the feedback problem in case of mic to speaker delays > of let's say 5-10msecs ? > Is an echo canceller algorithm needed ? If yes does this compromise the > quality of the input signal (the singer). > > I think this is a very interesting topic and it would be cool if > knowledgable people could come up with topics and ideas. > (for example people that are good at DSP, room correction etc, like Fons > A. etc). > > > PS: I know that cards like DELTA 1010 and others (RME) can do zero > latency monitoring (hardware pass-thru) but > I'd prefer a software based routing since you can apply effects and > stuff before forwarding the output. > > thanks for infos and toughts > Benno > > http://www.linuxsampler.org > -- From fons.adriaensen at skynet.be Sat Oct 29 12:02:42 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Sat Oct 29 11:57:46 2005 Subject: [linux-audio-dev] applying RIAA curves in software In-Reply-To: <1130587850.8551.1.camel@vaarlahti.uworld> References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> <1130259989.830.1.camel@eviltwin> <1130261079.830.9.camel@eviltwin> <20051025232801.GC4959@linux-1> <8a0c36780510251647i76b9e879v5097fe9c32c9731e@mail.gmail.com> <20051026004125.GE4959@linux-1> <1130587850.8551.1.camel@vaarlahti.uworld> Message-ID: <20051029160242.GB4956@linux-1> On Sat, Oct 29, 2005 at 03:10:50PM +0300, Jussi Laako wrote: > >From quality point of view, at least I would recommend using IIR filters > for this... Please ignore my previous post - I misread 'FIR' where you wrote 'IIR', and that explains it all... -- FA From fons.adriaensen at skynet.be Sat Oct 29 12:22:58 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Sat Oct 29 12:18:00 2005 Subject: [linux-audio-dev] Latency and feedback problems: soundcard with live microphone pass-thru, optimal solution ? In-Reply-To: <1130599013.18315.9.camel@c80-216-125-193.cm-upc.chello.se> References: <43620ACF.9070004@gardena.net> <1130599013.18315.9.camel@c80-216-125-193.cm-upc.chello.se> Message-ID: <20051029162258.GC4956@linux-1> On Sat, Oct 29, 2005 at 05:16:53PM +0200, Jens M Andreasen wrote: > Suggestion: Invert the phase of the offending microphone. This should > kill dead feadback in the frequency-band currently annoying you. The > downside is that it will also emphasize other frequency-bands that did > not pose a problem before. The theory is that those resonanses will be > minor relative to your current major problem. (Somehow I missed Benno's original post) Good suggestion. > Benno Senoner wrote: > > > For example if I use 64 samples per buffer which gives me acceptable > > latency for a live singer, the feedback noise > > could possibly generate a much lower pitched signal/interference (I > > assume something like 44100/64 Hz) which is I think > > not easy to filter out compared to the high pitched feedback (is in the > > latter case sufficient to cut some high frequencies using an EQ ?). There should be no difference: the processing delay has just the same effect as any delay, for example the one introduced by speaker to mic distance. It's in a different place in the loop, but loops being what they are, that doesn't matter. One thing I learned is that effect processors can make the situation much worse. So if your problem is with the monitor mix as Jens assumed, I'd suggest to leave out the effects there. And in that case you could equally well use zero delay monitoring either from you card or directly from the mixing desk. -- FA From James at superbug.co.uk Sat Oct 29 13:43:05 2005 From: James at superbug.co.uk (James Courtier-Dutton) Date: Sat Oct 29 13:43:13 2005 Subject: [linux-audio-dev] Latency and feedback problems: soundcard with live microphone pass-thru, optimal solution ? In-Reply-To: <43620ACF.9070004@gardena.net> References: <43620ACF.9070004@gardena.net> Message-ID: <4363B4A9.5040103@superbug.co.uk> Benno Senoner wrote: > Hi all, > I would like to route a microphone through a sound card and back to > powerful amplified speakers. > > As we know in analog PA gear you have the microphone feedback problem > (usually it comes in form > of high pitched whistle sounds). > This problem is common as you know, and it has been solved a long time ago. The solution is to do a slight frequency shift to the audio. Small frequency shifts are not noticeable to the listener, and that it what is used at all those loud pop concerts. So, use ardour and do a simple real time sound capture, add a frequency shifter plugin, and then play it out all in real time. Another application of feedback suppression is satellites where the forward uplink frequency is slightly different from the forward downlink frequency. James From paul at linuxaudiosystems.com Sat Oct 29 14:11:35 2005 From: paul at linuxaudiosystems.com (Paul Davis) Date: Sat Oct 29 14:09:45 2005 Subject: [linux-audio-dev] Re: applying RIAA curves in software In-Reply-To: <8a0c36780510290810p2b801b2n67a653eefe7cd80f@mail.gmail.com> References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> <1130259989.830.1.camel@eviltwin> <1130261079.830.9.camel@eviltwin> <20051025232801.GC4959@linux-1> <8a0c36780510251647i76b9e879v5097fe9c32c9731e@mail.gmail.com> <20051026004125.GE4959@linux-1> <8a0c36780510252202r1f5e4066odc82720b30aea71e@mail.gmail.com> <8a0c36780510290810p2b801b2n67a653eefe7cd80f@mail.gmail.com> Message-ID: <1130609495.16535.59.camel@localhost.localdomain> On Sat, 2005-10-29 at 10:10 -0500, Richard Smith wrote: > > software seems like it would be horrible to me. Buy or borrow a decent > > turntable. A few modern ones can play all three, for instance stuff > > from stanton. Though don't touch there needles, they are crap. To > > This may be getting too OT so let me know if I need go off-list. > > I've been looking at some turntables from Stanton. How do the DJ tables fair? i have a music hall turntable, and it is the paragon of great design (glass platter!), reasonable cost and sweet sound. i have the mmf-5 with a goldring cartridge, feeding a NAD phono preamp. i am not sure what the availability is in europe, but they are made in the czech republic so ... --p From cannam at all-day-breakfast.com Sat Oct 29 14:52:10 2005 From: cannam at all-day-breakfast.com (Chris Cannam) Date: Sat Oct 29 14:50:08 2005 Subject: [linux-audio-dev] Re: applying RIAA curves in software In-Reply-To: <1130609495.16535.59.camel@localhost.localdomain> References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> <8a0c36780510290810p2b801b2n67a653eefe7cd80f@mail.gmail.com> <1130609495.16535.59.camel@localhost.localdomain> Message-ID: <200510291952.10266.cannam@all-day-breakfast.com> On Saturday 29 Oct 2005 19:11, Paul Davis wrote: > i have a music hall turntable, and it is the paragon of great design > (glass platter!), reasonable cost and sweet sound. i have the mmf-5 > with a goldring cartridge, feeding a NAD phono preamp. > > i am not sure what the availability is in europe, but they are made > in the czech republic so ... I think these are basically the same thing as the Pro-ject turntables, highly regarded, nice to look at, and widely available in Europe (and also relatively cheap and made in the Czech republic). http://www.project-audio.com/en/turntables.html I use an ancient Thorens TD-150 I picked up on eBay. It's a bit battered, but a lovely turntable. Also a Goldring cartridge (a 1042). I do still buy records, mostly second-hand classical recordings. Chris From jussi.laako at pp.inet.fi Sat Oct 29 17:04:40 2005 From: jussi.laako at pp.inet.fi (Jussi Laako) Date: Sat Oct 29 17:04:44 2005 Subject: [linux-audio-dev] Re: applying RIAA curves in software In-Reply-To: <1130609495.16535.59.camel@localhost.localdomain> References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> <1130259989.830.1.camel@eviltwin> <1130261079.830.9.camel@eviltwin> <20051025232801.GC4959@linux-1> <8a0c36780510251647i76b9e879v5097fe9c32c9731e@mail.gmail.com> <20051026004125.GE4959@linux-1> <8a0c36780510252202r1f5e4066odc82720b30aea71e@mail.gmail.com> <8a0c36780510290810p2b801b2n67a653eefe7cd80f@mail.gmail.com> <1130609495.16535.59.camel@localhost.localdomain> Message-ID: <1130619880.8551.13.camel@vaarlahti.uworld> On Sat, 2005-10-29 at 14:11 -0400, Paul Davis wrote: > i have a music hall turntable, and it is the paragon of great design > (glass platter!), reasonable cost and sweet sound. i have the mmf-5 with > a goldring cartridge, feeding a NAD phono preamp. In europe there's good availability of Pro-Ject turntables (http://www.project-audio.com). I have a Pro-Ject RPM-4 turntable with Grado Labs' (http://www.gradolabs.com) Gold MI cartridge which goes up to 50 kHz in frequency response. Very good for playing direct-cut vinyls. They also have cartridges for 78 rpm. Pro-Ject also makes phono preamps, but I have a Creek audio's preamp (http://www.creekaudio.co.uk/main_content.asp? catlook=obh&content=obhseries). I've transferred number of vinyls to CD using this equipment with very good results. Wish there were open source or even Linux software for authoring DVD-Audio discs to take full advantage of capabilities of vinyl hardware... -- Jussi Laako From fons.adriaensen at skynet.be Sat Oct 29 17:25:35 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Sat Oct 29 17:20:34 2005 Subject: [linux-audio-dev] Latency and feedback problems: soundcard with live microphone pass-thru, optimal solution ? In-Reply-To: <4363B4A9.5040103@superbug.co.uk> References: <43620ACF.9070004@gardena.net> <4363B4A9.5040103@superbug.co.uk> Message-ID: <20051029212535.GD4956@linux-1> On Sat, Oct 29, 2005 at 06:43:05PM +0100, James Courtier-Dutton wrote: > Benno Senoner wrote: > > >As we know in analog PA gear you have the microphone feedback problem > >(usually it comes in form of high pitched whistle sounds). > > > This problem is common as you know, and it has been solved a long time > ago. The solution is to do a slight frequency shift to the audio. > Small frequency shifts are not noticeable to the listener, and that it > what is used at all those loud pop concerts. Frequency shifting will give a few dB extra, not more. It's based on the fact that a typical room response will have many very narrow peaks only a few Hz or less apart, and shifting the frequencies will smooth out the response as the sound circulates around the loop. It's less useful for stage monitoring for two reasons: first, there is usually a dominant direct path from the monitor to the artist and the mic (otherwise the monitor isn't very useful), and the room response has less impact on the loop gain, and second, the combination of the direct sound and the shifted one can be very confusing for the artist. > Another application of feedback suppression is satellites where the > forward uplink frequency is slightly different from the forward downlink > frequency. Slightly different in this case usually means at least several tens of MHz, and often up and downlink will be in different microwave bands. There'is only one application where up and downlink frequencies are linked to each other, and in that case they have a constant ratio, not difference. This makes the downlink frequency coherent to an on-ground reference, and thus allows for Doppler measurements. -- FA From cannam at all-day-breakfast.com Sat Oct 29 17:41:38 2005 From: cannam at all-day-breakfast.com (Chris Cannam) Date: Sat Oct 29 17:39:24 2005 Subject: [linux-audio-dev] Re: applying RIAA curves in software In-Reply-To: <1130619880.8551.13.camel@vaarlahti.uworld> References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> <1130609495.16535.59.camel@localhost.localdomain> <1130619880.8551.13.camel@vaarlahti.uworld> Message-ID: <200510292241.38996.cannam@all-day-breakfast.com> On Saturday 29 Oct 2005 22:04, Jussi Laako wrote: > I've transferred number of vinyls to > CD using this equipment with very good results. Wish there were open > source or even Linux software for authoring DVD-Audio discs to take > full advantage of capabilities of vinyl hardware... Do you really think you can tell the difference between an LP and the same LP transferred to CD? (Assuming a decent CD player, and decent hardware used to do the transfer.) I have some pretty good equipment to hand, but much as I love the sound of LPs, I honestly can't tell the difference between LP originals and CDs burned from them. (I mix and match the two fairly freely, so I'm quite confident about that.) As far as I'm concerned, the attractive sound of LPs is a fortuitous accident of distortion rather than any particular enhanced capability of the hardware. Chris From dmills at spamblock.demon.co.uk Sat Oct 29 18:41:02 2005 From: dmills at spamblock.demon.co.uk (Dan Mills) Date: Sat Oct 29 18:41:07 2005 Subject: [linux-audio-dev] Latency and feedback problems: soundcard with live microphone pass-thru, optimal solution ? In-Reply-To: <20051029212535.GD4956@linux-1> References: <43620ACF.9070004@gardena.net> <4363B4A9.5040103@superbug.co.uk> <20051029212535.GD4956@linux-1> Message-ID: <200510292341.02861.dmills@spamblock.demon.co.uk> On Saturday 29 October 2005 22:25, fons adriaensen wrote: > Frequency shifting will give a few dB extra, not more. It's based on the > fact that a typical room response will have many very narrow peaks only > a few Hz or less apart, and shifting the frequencies will smooth out the > response as the sound circulates around the loop. Actually it also causes the phase shift around the loop to be variable and thus tends to remove the required phasing conditions in fairly short order. Very helpful for conference work where the suits just will not speak into the damn mic. > It's less useful for stage monitoring for two reasons: first, there is > usually a dominant direct path from the monitor to the artist and the mic > (otherwise the monitor isn't very useful), and the room response has less > impact on the loop gain, and second, the combination of the direct sound > and the shifted one can be very confusing for the artist. The second is the real kicker here, the difference between the direct sound (mostly bone conduction), and the frequency shifted one can make it almost impossible for a vocalist to work. However monitors can almost always be tamed by correct placement and mic choice, for example, when using hypercardoid vocal mics, two monitors placed 30 degrees off axis will be FAR better then one, look at the mic polar diagram for why! Ohh yea, putting the guitar cab on a flightcase so it is at ear level can really help reduce overall stage volume! I want to find out where they teach guitar players that they have ears in their knees, then nuke from orbit! Regards, Dan. From richard.spindler at gmail.com Sat Oct 29 18:42:47 2005 From: richard.spindler at gmail.com (Richard Spindler) Date: Sat Oct 29 18:42:50 2005 Subject: [linux-audio-dev] jack_callback <-> rest of the world Message-ID: <4af8d6ff0510291542n29a79db3p@mail.gmail.com> Hi, I have two questions concerning the jack callback, 1. what is the preferred way of feeding data from disk to the callback? Is there a general design pattern agreed upon? Best Practices? 2. What is the preferred way to notify the non-realtime thread that something happened in the jack-callback? A condition variable? How to avoid blocking? How do you do it? I read the tutorial at http://userpages.umbc.edu/~berman3/ , it uses mutex+condition, is it okay to do this? Are there better ways? thx -Richard From jussi.laako at pp.inet.fi Sat Oct 29 19:31:06 2005 From: jussi.laako at pp.inet.fi (Jussi Laako) Date: Sat Oct 29 19:31:12 2005 Subject: [linux-audio-dev] Re: applying RIAA curves in software In-Reply-To: <200510292241.38996.cannam@all-day-breakfast.com> References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> <1130609495.16535.59.camel@localhost.localdomain> <1130619880.8551.13.camel@vaarlahti.uworld> <200510292241.38996.cannam@all-day-breakfast.com> Message-ID: <1130628666.8551.23.camel@vaarlahti.uworld> On Sat, 2005-10-29 at 22:41 +0100, Chris Cannam wrote: > Do you really think you can tell the difference between an LP and the > same LP transferred to CD? (Assuming a decent CD player, and decent > hardware used to do the transfer.) > > I have some pretty good equipment to hand, but much as I love the sound > of LPs, I honestly can't tell the difference between LP originals and > CDs burned from them. Depends on equipment and especially on material. There's huge variation on quality of vinyls available. Yes, with all-analog recorded direct cut LP's and equipment capable of going up to 50 kHz. Or even better with equipment with nice phase response capabilities, like full range loudspeakers (electrostatics or magnetostatics). With 24-bit, 96 or 192 kHz recording it's way much harder. With digital recording/playback, most of the quality "problems" comes out of digital and analog filtering involved. -- Jussi Laako From larsl at users.sourceforge.net Sat Oct 29 20:03:04 2005 From: larsl at users.sourceforge.net (Lars Luthman) Date: Sat Oct 29 20:01:52 2005 Subject: [linux-audio-dev] jack_callback <-> rest of the world In-Reply-To: <4af8d6ff0510291542n29a79db3p@mail.gmail.com> References: <4af8d6ff0510291542n29a79db3p@mail.gmail.com> Message-ID: <1130630585.6740.34.camel@c213-100-50-8.swipnet.se> On Sun, 2005-10-30 at 00:42 +0200, Richard Spindler wrote: > I have two questions concerning the jack callback, > > 1. what is the preferred way of feeding data from disk to the callback? > > Is there a general design pattern agreed upon? Best Practices? The most common way is to use some variant of a non-blocking ringbuffer. The JACK library has a ringbuffer that you can use for this, see http://jackit.sourceforge.net/docs/reference/html/ringbuffer_8h.html > 2. What is the preferred way to notify the non-realtime thread that > something happened in the jack-callback? It depends on how detailed information you want in the non-RT thread. If you just want to say "something happened!" you can use a counter of a datatype that you know is read and written atomically (int usually works) and increase it every time something happens. The non-RT thread can then compare the counter's value to the value it had last time it looked at it, and if it's different it knows that something has happened. If you need to more detailed information you can define a message struct or enum and use a ringbuffer of the same type as above to send those messages to the non-RT thread. > I read the tutorial at http://userpages.umbc.edu/~berman3/ , it uses > mutex+condition, is it okay to do this? Are there better ways? Locking a mutex in the process callback is usually not considered OK for a JACK program that is meant to run in realtime, because it can yield the CPU to some other process or thread while waiting for the mutex, which can cause unneccessary xruns. -- Lars Luthman PGP key: http://www.d.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- 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/20051030/280f40fc/attachment.bin From loki.davison at gmail.com Sat Oct 29 20:08:28 2005 From: loki.davison at gmail.com (Loki Davison) Date: Sat Oct 29 20:08:31 2005 Subject: [linux-audio-dev] Re: applying RIAA curves in software In-Reply-To: <8a0c36780510290810p2b801b2n67a653eefe7cd80f@mail.gmail.com> References: <8a0c36780510250638v41dd3865t1216c047f4863f66@mail.gmail.com> <1130259989.830.1.camel@eviltwin> <1130261079.830.9.camel@eviltwin> <20051025232801.GC4959@linux-1> <8a0c36780510251647i76b9e879v5097fe9c32c9731e@mail.gmail.com> <20051026004125.GE4959@linux-1> <8a0c36780510252202r1f5e4066odc82720b30aea71e@mail.gmail.com> <8a0c36780510290810p2b801b2n67a653eefe7cd80f@mail.gmail.com> Message-ID: On 10/30/05, Richard Smith wrote: > > software seems like it would be horrible to me. Buy or borrow a decent > > turntable. A few modern ones can play all three, for instance stuff > > from stanton. Though don't touch there needles, they are crap. To > > This may be getting too OT so let me know if I need go off-list. > > I've been looking at some turntables from Stanton. How do the DJ tables > fair? > > Fex. The stanton STR8-100 looks sweet. It has S-PDIF, phono, and line > outputs and it will play 78's. I can get a used one off of ebay for > $100 bucks or so. Most of the other decks I saw are just a bit out > of my range. > > That lets me do a flat preamp if I choose to mess with all that, but I > can also just use the S-PDIF or Line with the built in RIAA. And 78's > without resorting to software correction. > > I didn't realize the S/N ratio on turntables was so low. What would > those who on have messed with this before consider acceptable? > > -- > Richard A. Smith STR8-100 are nice. Solid, reliable and not too expensive. I've never tried the s-pdif on it and unless you have a pretty crap sound card (anything by creative) i'd assume it's worse than just recording the analog. But the analog should be quite nice. Playing 78's on a modern turntable is a cool feature. Get this and the cheapest ortofon e needles you can get. Loki From fons.adriaensen at skynet.be Sat Oct 29 20:09:19 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Sat Oct 29 20:12:55 2005 Subject: [linux-audio-dev] jack_callback <-> rest of the world In-Reply-To: <4af8d6ff0510291542n29a79db3p@mail.gmail.com> References: <4af8d6ff0510291542n29a79db3p@mail.gmail.com> Message-ID: <20051030000919.GF4956@linux-1> On Sun, Oct 30, 2005 at 12:42:47AM +0200, Richard Spindler wrote: > 1. what is the preferred way of feeding data from disk to the callback? Use a separate thread to read ahead. Trigger it in the same way as you would for a thread that takes data from the callback. > 2. What is the preferred way to notify the non-realtime thread that > something happened in the jack-callback? > A condition variable? How to avoid blocking? How do you do it? In all my apps I use threads from (my own) libclthreads which is a thin C++ abstaction of POSIX threads plus a communication system. All these threads contain an object that encapsulates a set of 16 message queues implemented as linked lists, and 16 counting semaphores, all 32 of them using a single condition variable plus mutex. A thread can wait on any subset of these events and optionally on a timeout. To tell another thread that a callback has occured, I signal (increment) one of the semas in the destination thread. There is a very tiny chance that this could block, if the destination happened to be in the (very short) critical section reading its input events when it was pre-empted by jack's callback thread (I've never seen this happen). If this is not acceptable, there is also a non-blocking version of the sema operation. It fails when the normal one would block. In that case the callback just remembers this and increments by one more next time. In more complex situations I would use a message containing parameters for the other thread instead of the sema. Since the message mechanism is zero-copy, there's virtually no overhead compared to the sema, and it's anyway deliverd by the same trigger. On a 2.6 system you could also use futex based semaphores. AFAIK, they never block on the V operation. -- FA From fons.adriaensen at skynet.be Sat Oct 29 17:36:11 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Sat Oct 29 20:13:00 2005 Subject: [linux-audio-dev] List maintainer: action required ! Message-ID: <20051029213611.GE4956@linux-1> Hello, Could someone please remove 'joesgarage79@cs.com' from the subscription list ? The last weeks I get a bounce from AOL for every message posted... -- FA From drobilla at connect.carleton.ca Sat Oct 29 23:03:39 2005 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sat Oct 29 23:05:45 2005 Subject: [linux-audio-dev] jack_callback <-> rest of the world In-Reply-To: <4af8d6ff0510291542n29a79db3p@mail.gmail.com> References: <4af8d6ff0510291542n29a79db3p@mail.gmail.com> Message-ID: <1130641420.2785.10.camel@localhost.localdomain> On Sun, 2005-30-10 at 00:42 +0200, Richard Spindler wrote: > I read the tutorial at http://userpages.umbc.edu/~berman3/ , it uses > mutex+condition, is it okay to do this? Are there better ways? That's a wonderful tutorial... on how NOT to write a Jack client. (There's no lock free data structures "in C" or Linux? There's one _included with Jack_...) On mutexes, calling pthread_mutex_trylock in the process thread is okay, but pthread_mutex_lock is not. Don't Do That(TM). -DR- From richard.spindler at gmail.com Sun Oct 30 02:28:56 2005 From: richard.spindler at gmail.com (Richard Spindler) Date: Sun Oct 30 02:29:04 2005 Subject: [linux-audio-dev] jack_callback <-> rest of the world In-Reply-To: <1130630585.6740.34.camel@c213-100-50-8.swipnet.se> References: <4af8d6ff0510291542n29a79db3p@mail.gmail.com> <1130630585.6740.34.camel@c213-100-50-8.swipnet.se> Message-ID: <4af8d6ff0510300028j7b541b74p@mail.gmail.com> 2005/10/30, Lars Luthman : > It depends on how detailed information you want in the non-RT thread. If > you just want to say "something happened!" you can use a counter of a > datatype that you know is read and written atomically (int usually > works) and increase it every time something happens. The non-RT thread > can then compare the counter's value to the value it had last time it > looked at it, and if it's different it knows that something has > happened. This would imply busy waiting, right? related question, what happens if I use the lockfree ringbuffer, and the non-realtime-thread tries to access it while it's full, how do I know when to try again? BTW. @all: thx for all the detailed answers. -Richard From richard.spindler at gmail.com Sun Oct 30 02:47:19 2005 From: richard.spindler at gmail.com (Richard Spindler) Date: Sun Oct 30 02:47:22 2005 Subject: [linux-audio-dev] jack_callback <-> rest of the world In-Reply-To: <4af8d6ff0510300028j7b541b74p@mail.gmail.com> References: <4af8d6ff0510291542n29a79db3p@mail.gmail.com> <1130630585.6740.34.camel@c213-100-50-8.swipnet.se> <4af8d6ff0510300028j7b541b74p@mail.gmail.com> Message-ID: <4af8d6ff0510300047v21b3b4b7g@mail.gmail.com> 2005/10/30, Richard Spindler : > related question, what happens if I use the lockfree ringbuffer, and > the non-realtime-thread tries to access it while it's full, how do I > know when to try again? Replying to myself: I just read the capture_client.c, it uses pthread_mutex_trylock and pthread_cond_signal, so I guess, that is okay. :) -Richard From mista.tapas at gmx.net Sun Oct 30 06:11:18 2005 From: mista.tapas at gmx.net (Florian Schmidt) Date: Sun Oct 30 06:11:34 2005 Subject: [linux-audio-dev] jack_callback <-> rest of the world In-Reply-To: <1130641420.2785.10.camel@localhost.localdomain> References: <4af8d6ff0510291542n29a79db3p@mail.gmail.com> <1130641420.2785.10.camel@localhost.localdomain> Message-ID: <20051030121118.213f6863@mango.fruits.de> On Sun, 30 Oct 2005 14:03:39 +1100 Dave Robillard wrote: > On Sun, 2005-30-10 at 00:42 +0200, Richard Spindler wrote: > > I read the tutorial at http://userpages.umbc.edu/~berman3/ , it uses > > mutex+condition, is it okay to do this? Are there better ways? > > That's a wonderful tutorial... on how NOT to write a Jack client. > (There's no lock free data structures "in C" or Linux? There's one > _included with Jack_...) > > On mutexes, calling pthread_mutex_trylock in the process thread is okay, > but pthread_mutex_lock is not. Don't Do That(TM). The tutorial client can be fixed pretty easily with this (see below), though as the comment said, the code was written when there didn't exist a lockfree ringbuffer implementation. This has changed (jack provides one). I know that you know this David, just restating the obvious for less experienced readers. Of course the tutorial client still needs to be considered broken even with the trylock. Also the basic problem of signalling (in this case the disk thread that there is work to do) still persists even with lockless ringbuffers. The other thinkable approach would be to make the diskthread wakeup regularly and check whether data is available in the ringbuffer. This is nasty, too, and unsuitable for some situations. So there's basically these approaches nowadays - using named pipes and having the signaller passing single bytes through it to wake up the signallee that blocks on the pipe. This is really not correct, though it might work ok in practice (see jack/ardour (in jack it is used to work around the fact that there's no inter-process mechanism for this though futexes could be used, too, if i understand correctly)). - using condition variables Btw: i think when using a single mutex only for the condition variable (as opposed to the tutorial client which uses the same mutex for the signalling _and_ for synchronizing access to its data structure), the likeliness of contention is rather unprobable given that that the signaller aquires (again, of course via trylock) right before and releases the lock right after the pthread_cond_signal/broadcast. Same for the singallee. As pthread_cond_wait releases the mutex while waiting and reaquires it before handing back control to the signallee the contention case becomes very unprobable when aquiring and releasing the lock right before and after the pthread_cond_wait. Of course with this strategy the case that trylock fails on the condition mutex needs to be handled gracefully (i.e. remembering for the next process callback to try again). Besides the one mutex used only for the condition var, there maybe need to be additional mutexes in this scenario for the shared data structures. Of course from the process callback pthread_mutex_lock is still a nono (again use trylock and handle failure gracefully). But i suppose most locking for the shared data can be worked around with lockless data structures... Btw: in the general case the signallee should always check for spurious wakeups which is not nessecary with the capture_client from the jack distribution as it doesn't hurt to wake up once or twice too often once in a while (at least not when using a ringbuffer - when it's empty the signallee simply goes back to waiting). Maybe the pthread_mutex_lock calls might be moved around the pthread_cond_wait call. The disk thread has the mutex locked all the time during writing. int process (jack_nframes_t nframes, void *arg) { thread_info_t *info = (thread_info_t *) arg; jack_default_audio_sample_t *in; sample_buffer_t *buf; unsigned int i; if (!info->can_process) { return 0; } /* we don't like taking locks, but until we have a lock free ringbuffer written in C, this is what has to be done */ if (pthread_mutex_trylock (&buffer_lock) != 0) { /* this is the unprobable contention case. we will simply do nothing here. audio will be lost. better than an xrun though */ return 0; } /* ok, aquired the mutex, so we can do our thing */ buf = get_free_buffer (nframes, nports); for (i = 0; i < nports; i++) { in = (jack_default_audio_sample_t *) jack_port_get_buffer (ports[i], nframes); memcpy (buf->data[i], in, sizeof (jack_default_audio_sample_t) * nframes); } put_write_buffer (buf); /* tell the disk thread that there is work to do */ pthread_cond_signal (&data_ready); pthread_mutex_unlock (&buffer_lock); return 0; } Have fun and correct me where wrong, Flo -- Palimm Palimm! http://tapas.affenbande.org From fons.adriaensen at skynet.be Sun Oct 30 07:36:41 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Sun Oct 30 07:31:50 2005 Subject: [linux-audio-dev] jack_callback <-> rest of the world In-Reply-To: <20051030121118.213f6863@mango.fruits.de> References: <4af8d6ff0510291542n29a79db3p@mail.gmail.com> <1130641420.2785.10.camel@localhost.localdomain> <20051030121118.213f6863@mango.fruits.de> Message-ID: <20051030123641.GB4959@linux-1> On Sun, Oct 30, 2005 at 12:11:18PM +0100, Florian Schmidt wrote: > Btw: i think when using a single mutex only for the condition variable > (as opposed to the tutorial client which uses the same mutex for the > signalling _and_ for synchronizing access to its data structure), the > likeliness of contention is rather unprobable given that that the > signaller aquires (again, of course via trylock) right before and > releases the lock right after the pthread_cond_signal/broadcast. > > Same for the singallee. As pthread_cond_wait releases the mutex while > waiting and reaquires it before handing back control to the signallee > the contention case becomes very unprobable when aquiring and releasing > the lock right before and after the pthread_cond_wait. This can still be so if the access to the shared data structure is regulated by the same mutex that protects the condition variable, provided that the operation on the shared data is very simple and fast. It should never be necessary to hold the mutex while accessing the samples, only while sending or receiving the information that the samples are available. In libclthreads, the operation performed while the mutex is held is either incr/decr of a counter, or adding/removing an element at the end/start of a linked list. Both operations are so trivial that it would be silly to use a separate mutex for them. The nice thing about condition variables is that they allow you to re-use the mutex in this way, and in fact that's why they exist at all. Thinking a bit further, the conclusion is that the use of lock-free data structures is warranted only iff the event passing mechanism is lock-free as well, otherwise nothing is gained. False wakeups are easy to avoid as well in this way. In libclthreads the sender will only signal the single CV iff the change of state of the ITC object (all the semas and mailboxes) would trigger some action in the receiver, i.e. it checks what the receiver is waiting for. In the other case only the state is updated. -- FA From taybin at earthlink.net Sun Oct 30 07:36:25 2005 From: taybin at earthlink.net (Taybin Rutkin) Date: Sun Oct 30 07:36:29 2005 Subject: [linux-audio-dev] List maintainer: action required ! In-Reply-To: <20051029213611.GE4956@linux-1> References: <20051029213611.GE4956@linux-1> Message-ID: Same here. Taybin On Oct 29, 2005, at 5:36 PM, fons adriaensen wrote: > Hello, > > Could someone please remove 'joesgarage79@cs.com' from the > subscription list ? > The last weeks I get a bounce from AOL for every message posted... > > -- > FA > > > > From mista.tapas at gmx.net Sun Oct 30 07:53:48 2005 From: mista.tapas at gmx.net (Florian Schmidt) Date: Sun Oct 30 07:53:54 2005 Subject: [linux-audio-dev] jack_callback <-> rest of the world In-Reply-To: <20051030123641.GB4959@linux-1> References: <4af8d6ff0510291542n29a79db3p@mail.gmail.com> <1130641420.2785.10.camel@localhost.localdomain> <20051030121118.213f6863@mango.fruits.de> <20051030123641.GB4959@linux-1> Message-ID: <20051030135348.79d64d5b@mango.fruits.de> On Sun, 30 Oct 2005 13:36:41 +0100 fons adriaensen wrote: > This can still be so if the access to the shared data structure is > regulated by the same mutex that protects the condition variable, > provided that the operation on the shared data is very simple and fast. True.. > In libclthreads, the operation performed while the mutex is held is > either incr/decr of a counter, or adding/removing an element at > the end/start of a linked list. Both operations are so trivial > that it would be silly to use a separate mutex for them. > The nice thing about condition variables is that they allow you > to re-use the mutex in this way, and in fact that's why they > exist at all. Yeah, but i figured with RT constrains on the signaller it looked a bit different. Thinking about it a bit more it seems i was wrong :) As in the other case (a data structure where operations carried out by the signallee might take a long time (signaller op naturally needs to be short time RT safe)) there's also nothing gained by seperating the two mutexes. > Thinking a bit further, the conclusion is that the use of lock-free > data structures is warranted only iff the event passing mechanism > is lock-free as well, otherwise nothing is gained. Naturally. > False wakeups are easy to avoid as well in this way. In libclthreads > the sender will only signal the single CV iff the change of state of > the ITC object (all the semas and mailboxes) would trigger some > action in the receiver, i.e. it checks what the receiver is waiting > for. In the other case only the state is updated. Oh i thought i read somewhere that when pthread_cond_wait it is not guaranteed that anyone actually signalled. Will do some more reading. Thanks for your insights, Flo -- Palimm Palimm! http://tapas.affenbande.org From dmills at spamblock.demon.co.uk Sun Oct 30 08:08:51 2005 From: dmills at spamblock.demon.co.uk (Dan Mills) Date: Sun Oct 30 08:08:56 2005 Subject: [linux-audio-dev] jack_callback <-> rest of the world In-Reply-To: <20051030121118.213f6863@mango.fruits.de> References: <4af8d6ff0510291542n29a79db3p@mail.gmail.com> <1130641420.2785.10.camel@localhost.localdomain> <20051030121118.213f6863@mango.fruits.de> Message-ID: <200510301308.51592.dmills@spamblock.demon.co.uk> On Sunday 30 October 2005 11:11, Florian Schmidt wrote: > > Also the basic problem of signalling (in this case the disk thread that > there is work to do) still persists even with lockless ringbuffers. The > other thinkable approach would be to make the diskthread wakeup > regularly and check whether data is available in the ringbuffer. This is > nasty, too, and unsuitable for some situations. > Actually this approach can work very well, just make sure that the ring buffers are sufficiently large and make the disk thread run at a lower RT priority then any of the audio handling threads. This is the approach taken in the rivendell broadcast automation system and it seems to work fine even with the disk array mounted over NFS. The trick is to remember that things like gain changes and effects can be applied in the process thread, so there is no need for big latency even with several seconds of disk buffer per file. IIRC we wake up the disk thread at a few tens of HZ. The downside is that it is kind of hard on memory usage when you need to support lots of parallel playbacks. Regards, Dan. From fons.adriaensen at skynet.be Sun Oct 30 08:14:19 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Sun Oct 30 08:09:29 2005 Subject: [linux-audio-dev] jack_callback <-> rest of the world In-Reply-To: <20051030135348.79d64d5b@mango.fruits.de> References: <4af8d6ff0510291542n29a79db3p@mail.gmail.com> <1130641420.2785.10.camel@localhost.localdomain> <20051030121118.213f6863@mango.fruits.de> <20051030123641.GB4959@linux-1> <20051030135348.79d64d5b@mango.fruits.de> Message-ID: <20051030131419.GC4959@linux-1> On Sun, Oct 30, 2005 at 01:53:48PM +0100, Florian Schmidt wrote: > Oh i thought i read somewhere that when pthread_cond_wait it is not > guaranteed that anyone actually signalled. Will do some more reading. It can return on unix signals, so you have to test for EINTR. I don't think it will wake up unexpectedly otherwise. I'm thinking of rewriting the whole ITC object so it uses a futex instead of the CV (that would also enable it to work in shared memory across process boundaries), but then I really need a lock free implementation for the linked lists. I guess the required primitives are platform dependant. Is their some library that provides them ? -- FA From mista.tapas at gmx.net Sun Oct 30 19:44:45 2005 From: mista.tapas at gmx.net (Florian Schmidt) Date: Sun Oct 30 19:44:52 2005 Subject: [linux-audio-dev] jack_callback <-> rest of the world In-Reply-To: <20051030131419.GC4959@linux-1> References: <4af8d6ff0510291542n29a79db3p@mail.gmail.com> <1130641420.2785.10.camel@localhost.localdomain> <20051030121118.213f6863@mango.fruits.de> <20051030123641.GB4959@linux-1> <20051030135348.79d64d5b@mango.fruits.de> <20051030131419.GC4959@linux-1> Message-ID: <20051031014445.37d530fa@mango.fruits.de> On Sun, 30 Oct 2005 14:14:19 +0100 fons adriaensen wrote: > On Sun, Oct 30, 2005 at 01:53:48PM +0100, Florian Schmidt wrote: > > > Oh i thought i read somewhere that when pthread_cond_wait it is not > > guaranteed that anyone actually signalled. Will do some more reading. > > It can return on unix signals, so you have to test for EINTR. > I don't think it will wake up unexpectedly otherwise. > > I'm thinking of rewriting the whole ITC object so it uses a > futex instead of the CV (that would also enable it to work > in shared memory across process boundaries), but then I really > need a lock free implementation for the linked lists. > I guess the required primitives are platform dependant. > Is their some library that provides them ? Btw: i just discovered that pthread mutexes and condvars can have a "process shared" flag which makes it possiblo to synchronize threads across processes as it seems. Could be useful for jack, no? pthread_condvar_setpshared() pthread_mutexattr_setpshared() Or do i misread that manpage? Flo -- Palimm Palimm! http://tapas.affenbande.org From fons.adriaensen at skynet.be Sun Oct 30 20:18:35 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Sun Oct 30 20:13:46 2005 Subject: [linux-audio-dev] jack_callback <-> rest of the world In-Reply-To: <20051031014445.37d530fa@mango.fruits.de> References: <4af8d6ff0510291542n29a79db3p@mail.gmail.com> <1130641420.2785.10.camel@localhost.localdomain> <20051030121118.213f6863@mango.fruits.de> <20051030123641.GB4959@linux-1> <20051030135348.79d64d5b@mango.fruits.de> <20051030131419.GC4959@linux-1> <20051031014445.37d530fa@mango.fruits.de> Message-ID: <20051031011835.GC5085@linux-1> On Mon, Oct 31, 2005 at 01:44:45AM +0100, Florian Schmidt wrote: > Btw: i just discovered that pthread mutexes and condvars can have a > "process shared" flag which makes it possiblo to synchronize threads > across processes as it seems. Could be useful for jack, no? > > pthread_condvar_setpshared() > pthread_mutexattr_setpshared() > > Or do i misread that manpage? Manpages sometimes document things that are not (yet) implemented. Maybe it is now (in 2.6) but I'm quite sure it was not in 2.4. For jack, all you need is the futexes (which are system wide, I tested that). I'm pretty sure that all of jack can be written without requiring a mutex shared with the client threads. A big advantage of using futexes in shared memory would be that they don't have to be recreated each time the callback order changes - unlike the pipes, they are not bound to a process, and to modify the 'trigger chain' all you need is to change some pointers. But ISTR that OSX only has named shared futexes (i.e. accessed via a file descriptor), and then of course the problem remains. -- FA From joq at io.com Sun Oct 30 21:10:13 2005 From: joq at io.com (Jack O'Quin) Date: Sun Oct 30 21:03:56 2005 Subject: [linux-audio-dev] jack_callback <-> rest of the world In-Reply-To: <20051030131419.GC4959@linux-1> (fons adriaensen's message of "Sun, 30 Oct 2005 14:14:19 +0100") References: <4af8d6ff0510291542n29a79db3p@mail.gmail.com> <1130641420.2785.10.camel@localhost.localdomain> <20051030121118.213f6863@mango.fruits.de> <20051030123641.GB4959@linux-1> <20051030135348.79d64d5b@mango.fruits.de> <20051030131419.GC4959@linux-1> Message-ID: <7qbr16jv22.fsf@io.com> fons adriaensen writes: > On Sun, Oct 30, 2005 at 01:53:48PM +0100, Florian Schmidt wrote: > >> Oh i thought i read somewhere that when pthread_cond_wait it is not >> guaranteed that anyone actually signalled. Will do some more reading. > > It can return on unix signals, so you have to test for EINTR. > I don't think it will wake up unexpectedly otherwise. According to the POSIX spec the signalled thread is not guaranteed that anything interesting has actually happened. It needs to check its own status and (perhaps) wait a while longer. > I'm thinking of rewriting the whole ITC object so it uses a > futex instead of the CV (that would also enable it to work > in shared memory across process boundaries), but then I really > need a lock free implementation for the linked lists. > I guess the required primitives are platform dependant. > Is their some library that provides them ? I believe there are no futexes in Linux 2.4 kernels. So, portable applications need some other solution. That's the main advantage of the pthread interfaces. They are not particularly wonderful, but they are (relatively) portable. -- joq From conrad.berhoerster at gmx.de Mon Oct 31 06:45:01 2005 From: conrad.berhoerster at gmx.de (conrad =?iso-8859-1?q?berh=F6rster?=) Date: Mon Oct 31 08:26:46 2005 Subject: [linux-audio-dev] Re: [linux-audio-user] Cheesetracker patch In-Reply-To: <20051028124925.GF10207@phlunky.Belkin> References: <20051028124925.GF10207@phlunky.Belkin> Message-ID: <200510311245.04264.conrad.berhoerster@gmx.de> Am Freitag, 28. Oktober 2005 14:49 schrieb james@dis-dot-dat.net: > I've written a simple patch to add info on the real-time capabilities > of LADSPA plugins in CheeseTracker. > > I know I seem to be the only CheeseTracker user on the lists, but just > in case... No you aren't !! praise the nice cheesetracker sizu c~ > > http://blog.dis-dot-dat.net/2005/10/cheesetracker-patch.html From smithbone at gmail.com Mon Oct 31 10:36:56 2005 From: smithbone at gmail.com (Richard Smith) Date: Mon Oct 31 10:37:02 2005 Subject: [linux-audio-dev] jack and S24_3BE In-Reply-To: <1130531053.16535.36.camel@localhost.localdomain> References: <8a0c36780510281158v20818ba6h4424772005f63d07@mail.gmail.com> <1130529260.16535.34.camel@localhost.localdomain> <8a0c36780510281309m2ce6a258mff18c52a78c06a1@mail.gmail.com> <1130531053.16535.36.camel@localhost.localdomain> Message-ID: <8a0c36780510310736y1726336cg1bd9506f2e0a15a9@mail.gmail.com> > > Sweet. Where? I googled for jack & S24_3BE but nothing showed up. > > http://sourceforge.net/tracker/?group_id=39687&atid=425939 This won't apply cleanly. I tried pulling it down with both Firefox and Konqueror so I don't think my browser munged it. rsmith@engine36:~/src/jack-audio-connection-kit-0.100.0$ patch -p1 < ../../downloads/jack-audio-connection-kit-0.100.0-bswap.patch patching file drivers/alsa/alsa_driver.c patching file drivers/alsa/alsa_driver.h patching file drivers/alsa/memops.c Hunk #2 succeeded at 99 with fuzz 2. missing header for unified diff at line 296 of patch can't find file to patch at input line 296 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- | /* ALERT: signed sign-extension portability !!! */ -------------------------- File to patch: -- Richard A. Smith From rlrevell at joe-job.com Mon Oct 31 10:57:46 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Mon Oct 31 11:36:18 2005 Subject: [linux-audio-dev] jack_callback <-> rest of the world In-Reply-To: <20051031014445.37d530fa@mango.fruits.de> References: <4af8d6ff0510291542n29a79db3p@mail.gmail.com> <1130641420.2785.10.camel@localhost.localdomain> <20051030121118.213f6863@mango.fruits.de> <20051030123641.GB4959@linux-1> <20051030135348.79d64d5b@mango.fruits.de> <20051030131419.GC4959@linux-1> <20051031014445.37d530fa@mango.fruits.de> Message-ID: <1130774267.32101.24.camel@mindpipe> On Mon, 2005-10-31 at 01:44 +0100, Florian Schmidt wrote: > On Sun, 30 Oct 2005 14:14:19 +0100 > fons adriaensen wrote: > > > On Sun, Oct 30, 2005 at 01:53:48PM +0100, Florian Schmidt wrote: > > > > > Oh i thought i read somewhere that when pthread_cond_wait it is not > > > guaranteed that anyone actually signalled. Will do some more reading. > > > > It can return on unix signals, so you have to test for EINTR. > > I don't think it will wake up unexpectedly otherwise. > > > > I'm thinking of rewriting the whole ITC object so it uses a > > futex instead of the CV (that would also enable it to work > > in shared memory across process boundaries), but then I really > > need a lock free implementation for the linked lists. > > I guess the required primitives are platform dependant. > > Is their some library that provides them ? > > > Btw: i just discovered that pthread mutexes and condvars can have a > "process shared" flag which makes it possiblo to synchronize threads > across processes as it seems. Could be useful for jack, no? > > pthread_condvar_setpshared() > pthread_mutexattr_setpshared() > > Or do i misread that manpage? What manpage? I don't have those on my system. Lee From jussi.laako at pp.inet.fi Mon Oct 31 14:39:46 2005 From: jussi.laako at pp.inet.fi (Jussi Laako) Date: Mon Oct 31 14:39:51 2005 Subject: [linux-audio-dev] jack_callback <-> rest of the world In-Reply-To: <20051031014445.37d530fa@mango.fruits.de> References: <4af8d6ff0510291542n29a79db3p@mail.gmail.com> <1130641420.2785.10.camel@localhost.localdomain> <20051030121118.213f6863@mango.fruits.de> <20051030123641.GB4959@linux-1> <20051030135348.79d64d5b@mango.fruits.de> <20051030131419.GC4959@linux-1> <20051031014445.37d530fa@mango.fruits.de> Message-ID: <1130787586.22295.2.camel@vaarlahti.uworld> On Mon, 2005-10-31 at 01:44 +0100, Florian Schmidt wrote: > Btw: i just discovered that pthread mutexes and condvars can have a > "process shared" flag which makes it possiblo to synchronize threads > across processes as it seems. Could be useful for jack, no? > pthread_condvar_setpshared() > pthread_mutexattr_setpshared() Yes, that's nice feature, I'm using that in my own apps. You can place the objects in shared memory. It works with Linux 2.6 kernels and NPTL. LinuxThreads doesn't have support for those (functions may exist, but always return error). -- Jussi Laako From mrfisher_1 at yahoo.com Mon Oct 31 14:40:47 2005 From: mrfisher_1 at yahoo.com (Mike Fisher) Date: Mon Oct 31 14:40:51 2005 Subject: [linux-audio-dev] midisport problem Message-ID: <20051031194047.18020.qmail@web61017.mail.yahoo.com> gentoo vanilla kernel 2.6.10 coldplug-20040920 hotplug-20040923 fxload-20020411 midisport_fw-0.5.0 to make this short.... I installed by following the instructions here... http://alsa.opensrc.org/index.php?page=USBMidiDevices I installed the midisport about a month ago and got it working. I was using kde at the time. I uninstalled kde and switched to windowmaker. Now the midisport doesn't work I reinstalled the above packages. still no luck. I even reinstalled kde. nothing. any ideas on this one? -Mike Fisher __________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs From mista.tapas at gmx.net Mon Oct 31 14:42:22 2005 From: mista.tapas at gmx.net (Florian Schmidt) Date: Mon Oct 31 14:42:35 2005 Subject: [linux-audio-dev] jack_callback <-> rest of the world In-Reply-To: <1130774267.32101.24.camel@mindpipe> References: <4af8d6ff0510291542n29a79db3p@mail.gmail.com> <1130641420.2785.10.camel@localhost.localdomain> <20051030121118.213f6863@mango.fruits.de> <20051030123641.GB4959@linux-1> <20051030135348.79d64d5b@mango.fruits.de> <20051030131419.GC4959@linux-1> <20051031014445.37d530fa@mango.fruits.de> <1130774267.32101.24.camel@mindpipe> Message-ID: <20051031204222.59a72b09@mango.fruits.de> On Mon, 31 Oct 2005 10:57:46 -0500 Lee Revell wrote: > > Btw: i just discovered that pthread mutexes and condvars can have a > > "process shared" flag which makes it possiblo to synchronize threads > > across processes as it seems. Could be useful for jack, no? > > > > pthread_condvar_setpshared() > > pthread_mutexattr_setpshared() > > > > Or do i misread that manpage? > > What manpage? I don't have those on my system. Hi, i misspelled the first one: pthread_condattr_setpshared is the name. See here, too: http://www.google.de/search?q=pthread_condattr_setpshared SCNR ;) Flo -- Palimm Palimm! http://tapas.affenbande.org From ix at replic.net Mon Oct 31 15:12:33 2005 From: ix at replic.net (carmen) Date: Mon Oct 31 15:12:41 2005 Subject: [linux-audio-dev] midisport problem In-Reply-To: <20051031194047.18020.qmail@web61017.mail.yahoo.com>; from mrfisher_1@yahoo.com on Mon, Oct 31, 2005 at 11:40:47AM -0800 References: <20051031194047.18020.qmail@web61017.mail.yahoo.com> Message-ID: <20051031121233.A20478@replic.net> > > I installed the midisport about a month ago and got it > working. I was using kde at the time. I uninstalled > kde and switched to windowmaker. Now the midisport > doesn't work I reinstalled the above packages. still > no luck. I even reinstalled kde. nothing. 'doesn\'t work' isnt very specific, perhaps you have some stuff from /var/log/messages or dmesg that might be relevant? btw, KDE should have nothing todo with it... From ce at christeck.de Mon Oct 31 15:53:29 2005 From: ce at christeck.de (Christoph Eckert) Date: Mon Oct 31 15:53:45 2005 Subject: [linux-audio-dev] midisport problem In-Reply-To: <20051031194047.18020.qmail@web61017.mail.yahoo.com> References: <20051031194047.18020.qmail@web61017.mail.yahoo.com> Message-ID: <200510312153.29596.ce@christeck.de> > gentoo > vanilla kernel 2.6.10 > coldplug-20040920 > hotplug-20040923 > fxload-20020411 same here... > midisport_fw-0.5.0 ...but AFAIR I took the tarball from the project homepage for this one. > to make this short.... > > I installed by following the instructions here... > http://alsa.opensrc.org/index.php?page=USBMidiDevices > > I installed the midisport about a month ago and got it > working. ?I was using kde at the time. ?I uninstalled > kde and switched to windowmaker. ?Now the midisport > doesn't work I reinstalled the above packages. ?still > no luck. ?I even reinstalled kde. nothing. as Carmen wrote, KDE is not related to this issue. PLease post some messages like shown by tail -f /var/log/messages when pluggin it in/switching it to USB mode. Best regards ce From mrfisher_1 at yahoo.com Mon Oct 31 16:29:04 2005 From: mrfisher_1 at yahoo.com (Mike Fisher) Date: Mon Oct 31 16:29:14 2005 Subject: [linux-audio-dev] midisport problem In-Reply-To: <20051031121233.A20478@replic.net> Message-ID: <20051031212904.29448.qmail@web61020.mail.yahoo.com> --- carmen wrote: > > > > I installed the midisport about a month ago and > got it > > working. I was using kde at the time. I > uninstalled > > kde and switched to windowmaker. Now the > midisport > > doesn't work I reinstalled the above packages. > still > > no luck. I even reinstalled kde. nothing. > > 'doesn\'t work' isnt very specific, perhaps you have > some stuff from /var/log/messages or dmesg that > might be relevant? > > btw, KDE should have nothing todo with it... > sorry, to be more specific. The firmware doesn't load into the device. I get this from /var/log/messages when I plug it in... Oct 31 16:27:23 bloody ohci_hcd 0000:00:02.0: wakeup Oct 31 16:27:23 bloody usb 2-2: new full speed USB device using ohci_hcd and address 13 I am aware that kde shouldn't have anything to do with it, but after uninstalling it is when the midisport stopped working, thats all. -Mike __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From lad at koloro.de Mon Oct 31 14:48:04 2005 From: lad at koloro.de (Uwe Koloska) Date: Mon Oct 31 17:04:41 2005 Subject: [linux-audio-dev] fst-1.6 doesn't compile with wine 0.9 Message-ID: <200510312048.04818.lad@koloro.de> Hello, just tried to update my installation of fst-1.6 to the newest (now beta!) wine. But there are several problems: the options to winebuild have changed and so in fst/Makefile the build-command must be changed: - the target must be renamed to "$(fst_exe_MODULE).spec.o:" cause winebuild creates an assembler file that can't be processed by the implicit rule ".c.o:" -- but the new winebuild can create the ".o" file directly. - "the executable must be named via the -F option" -- to get rid of this winebuild error message the option '-F' must be inserted just before $(fst_exe_MODULE) With this modifications the build creates the libfst.so successfully but when linking fstconfig with libfst there are two missing symbols: ./libfst.so: undefined reference to `__wine_spec_exe_entry' ./libfst.so: undefined reference to `__wine_spec_init_ctor' Unfortunately the wine documentation is not updated to this new behaviour and I was not able to figure out what to do. When building the intermediate assembler source (just undo the extension change for the .spec.o) and looking at it, the two symbols are destination marker: The first is just an address in an internal table and the second is the target of a jump command. I can't find any suggestions what to additionally link to libfst to satisfy this unresolved references ... Is there an updated version of libfst? Or someone with more wine knowledge, who can solve this problems? By further investigation I found a workaround that builds libfst but at least ardour gives a "memory access fault" (Speicherzugriffsfehler): Unpack the distribution cp fst/libfst.spec.c fst/libfst.spec.c_backup ./configure make cp fst/libfst.spec.c_backup fst/libfst.spec.c This uses the prebuilt libfst.spec.c but maybe this doesn't match the current wine version ... I have build ardour with "VST=1" and it only starts without "memory access fault" when giving the option "-V" Thank you Uwe Koloska