From S.W.Harris at ecs.soton.ac.uk Thu Jun 1 04:42:29 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Thu Jun 1 04:42:48 2006 Subject: [linux-audio-dev] LV2 library API In-Reply-To: <1149016174.12003.2.camel@DaveLap> References: <1148612989.31105.7.camel@DaveLap> <1148645921.8858.2.camel@localhost> <1148662471.29421.2.camel@DaveLap> <958b3a2e0605300522s6256b024i56bf5f0ec4a97b56@mail.gmail.com> <1149003837.8726.5.camel@DaveLap> <958b3a2e0605300953y74033b2dkd231e36d32407f53@mail.gmail.com> <1149016174.12003.2.camel@DaveLap> Message-ID: <20060601084229.GB5017@login.ecs.soton.ac.uk> On Tue, May 30, 2006 at 03:09:33 -0400, Dave Robillard wrote: > I'm a bit unhappy that it makes code longer and more messy though. The > primary design goal here is to make host code as terse and simple as > possible. strcmp'ing a string and then freeing it is quite a bit uglier > than just testing an enum val :/ This is maybe a PITA, but what about a runtime provided enum list, like: foo_enum = { { FOO_FLOAT, LV2_FLOAT_URI }, { FOO_MIDI, "http://example.org/datatypes/midi" }, { 0, NULL } }; lv2_set_urilist(foo_enum); the library can contain an builtin enum list that is set implictly, ie. it does lv2_set_urilist(lv2_internal_enum); when it starts. that way simple hosts can just use it as is, and more complex ones can specify the types they support, and everyone gets to use ints. - Steve From pieterp at joow.be Thu Jun 1 06:53:25 2006 From: pieterp at joow.be (Pieter Palmers) Date: Thu Jun 1 06:53:34 2006 Subject: [linux-audio-dev] [ANN] bcx2000edit: Editor for BCR2000/BCF2000 Message-ID: <447EC725.9070903@joow.be> Hi all, I had to familiarize myself with python for work, and I took it as an opportunity to hack on something I've want for some time now. I have these behringer control surfaces, and they are pretty cool, but there is no editor for them on linux. And using the device interface itself is a little cumbersome. So I figured out the sysex format (the patch dump format from "edit + >") and wrote a parser for it in python. I also have a small PyQt inteface (had to learn that too) that allows you to load files, change the values and save them as a new file. Note that this is very basic & non-bugfree software. No checking whatsoever is performed on the sysex files, so if your control surface displays "ERR" when you send a sysex file, you're probably violating the format. The GUI is also limited to changes on existing files only. I put this code online because I think it might be a nice starting point for somebody that want's to write a real editor. It shouln't be that hard (mostly GUI design), and they can use this code to further explore the sysex format. I'm not planning to work on this any further because (1) it serves my needs and (2) I need my time for other projects (most notably freebob). Anyway, you can find the code here: http://freebob.sourceforge.net/old/bcx2000edit.tar.gz Let me know if you start something with it. Greets, Pieter From x37v.alex at gmail.com Thu Jun 1 13:06:29 2006 From: x37v.alex at gmail.com (Alex) Date: Thu Jun 1 13:08:17 2006 Subject: [linux-audio-dev] real time priority programming tutorial Message-ID: Does anyone have a link to a reference about making apps with real time priority capabilities? I figure I can just look at jack but it would be nice see some tutorial, to learn what is actually happening/necessary, trade-offs, etc. thanks, Alex Norman From rlrevell at joe-job.com Thu Jun 1 14:29:35 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Thu Jun 1 14:29:45 2006 Subject: [linux-audio-dev] real time priority programming tutorial In-Reply-To: References: Message-ID: <1149186575.2472.9.camel@mindpipe> On Thu, 2006-06-01 at 10:06 -0700, Alex wrote: > Does anyone have a link to a reference about making apps with real > time priority capabilities? > I figure I can just look at jack but it would be nice see some > tutorial, to learn what is actually happening/necessary, trade-offs, > etc. The question is almost impossibly vague. It is a big area. Can you be more specific? What are you trying to do? Lee From drobilla at connect.carleton.ca Thu Jun 1 16:10:49 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Thu Jun 1 16:11:58 2006 Subject: [linux-audio-dev] LV2 library API In-Reply-To: <20060601084229.GB5017@login.ecs.soton.ac.uk> References: <1148612989.31105.7.camel@DaveLap> <1148645921.8858.2.camel@localhost> <1148662471.29421.2.camel@DaveLap> <958b3a2e0605300522s6256b024i56bf5f0ec4a97b56@mail.gmail.com> <1149003837.8726.5.camel@DaveLap> <958b3a2e0605300953y74033b2dkd231e36d32407f53@mail.gmail.com> <1149016174.12003.2.camel@DaveLap> <20060601084229.GB5017@login.ecs.soton.ac.uk> Message-ID: <1149192649.23852.16.camel@DaveLap> On Thu, 2006-06-01 at 09:42 +0100, Steve Harris wrote: > On Tue, May 30, 2006 at 03:09:33 -0400, Dave Robillard wrote: > > I'm a bit unhappy that it makes code longer and more messy though. The > > primary design goal here is to make host code as terse and simple as > > possible. strcmp'ing a string and then freeing it is quite a bit uglier > > than just testing an enum val :/ > > This is maybe a PITA, but what about a runtime provided enum list, like: > > foo_enum = { { FOO_FLOAT, LV2_FLOAT_URI }, > { FOO_MIDI, "http://example.org/datatypes/midi" }, > { 0, NULL } }; > lv2_set_urilist(foo_enum); > > the library can contain an builtin enum list that is set implictly, ie. it > does lv2_set_urilist(lv2_internal_enum); when it starts. > > that way simple hosts can just use it as is, and more complex ones can > specify the types they support, and everyone gets to use ints. Hmm.. that's not a bad idea. The current API could remain unaffected but still allow extension. OTOH, it's not really all that much better from just returning a string, but I would like to avoid the strcmp and free thing.. >From an (internal) code standpoint it will definitely be nicer that a big if/else chain with the known URIs hardcoded in. When I do more work on the static 'library state' stuff (eg lv2_set_urilist, lv2_add_prefix, etc) I'll give it a shot and see how it works out. -DR- From jens.andreasen at chello.se Thu Jun 1 19:06:39 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Thu Jun 1 19:06:56 2006 Subject: [linux-audio-dev] real time priority programming tutorial In-Reply-To: References: Message-ID: <1149203199.10430.108.camel@c80-216-124-251.cm-upc.chello.se> On Thu, 2006-06-01 at 10:06 -0700, Alex wrote: > Does anyone have a link to a reference about making apps with real > time priority capabilities? As such there is no difference between an RT app and a not RT app, except that the former varity might not work as advocated .... > I figure I can just look at jack but it would be nice see some > tutorial, to learn what is actually happening/necessary, trade-offs, > etc. > > thanks, > Alex Norman -- From loki.davison at gmail.com Thu Jun 1 19:26:06 2006 From: loki.davison at gmail.com (Loki Davison) Date: Thu Jun 1 19:26:12 2006 Subject: [linux-audio-dev] Re: real time priority programming tutorial In-Reply-To: References: Message-ID: On 6/2/06, Alex wrote: > Does anyone have a link to a reference about making apps with real > time priority capabilities? > I figure I can just look at jack but it would be nice see some > tutorial, to learn what is actually happening/necessary, trade-offs, > etc. > > thanks, > Alex Norman > Operating Systems Concept by Silberschatz, Galvin, and Gagne is pretty informative, though the copy i used to have was pretty old and i'm not sure how later editions have changed. Loki From josepadovani at yahoo.com.br Thu Jun 1 22:27:00 2006 From: josepadovani at yahoo.com.br (Jose Henrique Padovani) Date: Thu Jun 1 22:27:27 2006 Subject: [linux-audio-dev] Quatafire 610 and freebob: recent news? Message-ID: <447FA1F4.80109@yahoo.com.br> So: I have visited six motnhs ago the freebob site and became very curious about Quatafire 610 under linux... The site has not changed to much since then. Any news? It would be a very nice interface to use in any system. (linux, mac, win...) I have particular interest in intercative music on Puredata then low latency would be a important thing.. Another thing that would be nice know is if anyone knows about freebob integration on Debian based distros like Ubuntu. I thanks anyone that has news or sugestions (not RME, please: to high prices on my country). J.H. _______________________________________________________ Abra sua conta no Yahoo! Mail: 1GB de espa?o, alertas de e-mail no celular e anti-spam realmente eficaz. http://mail.yahoo.com.br/ From james at dis-dot-dat.net Fri Jun 2 04:32:28 2006 From: james at dis-dot-dat.net (james@dis-dot-dat.net) Date: Fri Jun 2 04:32:15 2006 Subject: [linux-audio-dev] real time priority programming tutorial In-Reply-To: <1149203199.10430.108.camel@c80-216-124-251.cm-upc.chello.se> References: <1149203199.10430.108.camel@c80-216-124-251.cm-upc.chello.se> Message-ID: <20060602083228.GM17442@fitz.Belkin> On Fri, 02 Jun, 2006 at 01:06AM +0200, Jens M Andreasen spake thus: > On Thu, 2006-06-01 at 10:06 -0700, Alex wrote: > > Does anyone have a link to a reference about making apps with real > > time priority capabilities? > > As such there is no difference between an RT app and a not RT app, > except that the former varity might not work as advocated .... I think he meant: how you demand RT priority and what you should do not to screw it up once you have it. > > I figure I can just look at jack but it would be nice see some > > tutorial, to learn what is actually happening/necessary, trade-offs, > > etc. > > > > thanks, > > Alex Norman From pieterp at joow.be Fri Jun 2 05:51:32 2006 From: pieterp at joow.be (Pieter Palmers) Date: Fri Jun 2 05:52:00 2006 Subject: [linux-audio-dev] Quatafire 610 and freebob: recent news? In-Reply-To: <447FA1F4.80109@yahoo.com.br> References: <447FA1F4.80109@yahoo.com.br> Message-ID: <44800A24.4050204@joow.be> Jose Henrique Padovani wrote: > So: > I have visited six motnhs ago the freebob site and became very curious > about Quatafire 610 under linux... > The site has not changed to much since then. Any news? > It would be a very nice interface to use in any system. (linux, mac, > win...) I have particular interest in intercative music on Puredata then > low latency would be a important thing.. > Another thing that would be nice know is if anyone knows about freebob > integration on Debian based distros like Ubuntu. > I thanks anyone that has news or sugestions (not RME, please: to high > prices on my country). > J.H. > FreeBoB 1.0 is going to be released very shortly now. Normally it would have been this week, but we are waiting for the other projects upon which we depend to release their stuff, so that it is insta-usable. FreeBoB 1.0 will support the quatafire 610. I'd say: keep an eye on the list. Greets, Pieter Palmers FreeBoB developer From list at phasorlab.de Fri Jun 2 06:14:33 2006 From: list at phasorlab.de (Matthias Koenig) Date: Fri Jun 2 06:14:42 2006 Subject: [linux-audio-dev] real time priority programming tutorial In-Reply-To: (x37v.alex@gmail.com's message of "Thu, 1 Jun 2006 10:06:29 -0700") References: Message-ID: <87ac8vdfue.fsf@zebra.localdomain> Alex writes: > Does anyone have a link to a reference about making apps with real > time priority capabilities? > I figure I can just look at jack but it would be nice see some > tutorial, to learn what is actually happening/necessary, trade-offs, > etc. For an introduction to the aspects of real-time programming as covered by the POSIX standard I would recommend the Oreilly POSIX.4 book by Bill O. Gallmeister: http://www.oreilly.com/catalog/posix4/ Matthias From rlrevell at joe-job.com Fri Jun 2 12:05:13 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Fri Jun 2 12:05:25 2006 Subject: [linux-audio-dev] real time priority programming tutorial In-Reply-To: <20060602083228.GM17442@fitz.Belkin> References: <1149203199.10430.108.camel@c80-216-124-251.cm-upc.chello.se> <20060602083228.GM17442@fitz.Belkin> Message-ID: <1149264314.27227.2.camel@mindpipe> On Fri, 2006-06-02 at 09:32 +0100, james@dis-dot-dat.net wrote: > On Fri, 02 Jun, 2006 at 01:06AM +0200, Jens M Andreasen spake thus: > > On Thu, 2006-06-01 at 10:06 -0700, Alex wrote: > > > Does anyone have a link to a reference about making apps with real > > > time priority capabilities? > > > > As such there is no difference between an RT app and a not RT app, > > except that the former varity might not work as advocated .... > > I think he meant: how you demand RT priority and what you should do > not to screw it up once you have it. > man sched_setscheduler > > > I figure I can just look at jack but it would be nice see some > > > tutorial, to learn what is actually happening/necessary, trade-offs, > > > etc. > > > > > > thanks, > > > Alex Norman > > From drobilla at connect.carleton.ca Fri Jun 2 13:19:58 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Fri Jun 2 13:21:23 2006 Subject: [linux-audio-dev] real time priority programming tutorial In-Reply-To: <1149264314.27227.2.camel@mindpipe> References: <1149203199.10430.108.camel@c80-216-124-251.cm-upc.chello.se> <20060602083228.GM17442@fitz.Belkin> <1149264314.27227.2.camel@mindpipe> Message-ID: <1149268798.17428.30.camel@DaveLap> On Fri, 2006-06-02 at 12:05 -0400, Lee Revell wrote: > On Fri, 2006-06-02 at 09:32 +0100, james@dis-dot-dat.net wrote: > > On Fri, 02 Jun, 2006 at 01:06AM +0200, Jens M Andreasen spake thus: > > > On Thu, 2006-06-01 at 10:06 -0700, Alex wrote: > > > > Does anyone have a link to a reference about making apps with real > > > > time priority capabilities? > > > > > > As such there is no difference between an RT app and a not RT app, > > > except that the former varity might not work as advocated .... > > > > I think he meant: how you demand RT priority and what you should do > > not to screw it up once you have it. > > > > man sched_setscheduler It think maybe this thread is mixing up realtime _priority_ and writing "realtime safe" code, it's not very clear what the original poster was asking about... (it's pretty common for people to mix up RT priority with other somewhat related things like latency, at least for users) -DR- From x37v.alex at gmail.com Sat Jun 3 20:25:55 2006 From: x37v.alex at gmail.com (Alex) Date: Sat Jun 3 20:26:07 2006 Subject: [linux-audio-dev] real time priority programming tutorial Message-ID: Sorry to be vague, basically, what I want to do is create a timer for an "event" sequencer I'm writing (which I will use to write music compositions, video, etc). I cannot find "event timers" that will give me accuracy of less than 1ms, so I'm using a 1ms resolution event timer and after that polling the time of day in order to get to the time I want. I'm trying to achieve ~256-900 event clock "ticks" per second and minimize jitter. First off, if anyone has advice for implementing such a timer I'd appreciate it, but second, I'm wondering how I can make my program have "real time" priority such that when a signal is created by this 1ms resolution event timer my app is quickly made to respond to the signal and so this can be done as a user, [using set_rlimits, pam or what have you (this is what i was talking about in my first email)]. Also, as I figure missed ticks are probably inevitable, I'm trying to figure out a way to make my program robust to missed clock ticks [so that over time i am still on beat]. Thank you, Alex Norman > > On Fri, 02 Jun, 2006 at 01:06AM +0200, Jens M Andreasen spake thus: > > On Thu, 2006-06-01 at 10:06 -0700, Alex wrote: > > > Does anyone have a link to a reference about making apps with real > > > time priority capabilities? > > > > As such there is no difference between an RT app and a not RT app, > > except that the former varity might not work as advocated .... > > I think he meant: how you demand RT priority and what you should do > not to screw it up once you have it. > > > > I figure I can just look at jack but it would be nice see some > > > tutorial, to learn what is actually happening/necessary, trade-offs, > > > etc. > > > > > > thanks, > > > Alex Norman From stefan at space.twc.de Sun Jun 4 19:21:02 2006 From: stefan at space.twc.de (Stefan Westerfeld) Date: Sun Jun 4 19:04:52 2006 Subject: [linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write Message-ID: <20060604232101.GA29257@space.twc.de> Hi! I am trying to notify a high priority (nice -20 or nice -19) thread from a realtime thread (from a jack callback to be precise). Of course I want the realtime thread to not block, but I want the high priority thread to react as soon as possible. For the first implementation, I used a condition, and pthread_cond_signal. But as I can't aquire a mutex within the realtime thread, at least not always (at most with trylock()), this results in racy code. Also, it doesn't integrate well with poll(), which the high priority process should be able to use. So basically I want to switch to a pipe write() instead of pthread_cond_signal. Now the question is: am I producing priority inversion, then? I've seen that the kernel code of pipe write has code like mutex_lock(PIPE_MUTEX(*inode)); (in fs/pipe.c, linux-2.6.16.16), so can this mutex cause priority inversion? However, on the other hand, I examined the code of glibc-2.3.6/ntpl/sysdeps/pthread, and found in pthread_cond_signal.c: __pthread_cond_signal (cond) pthread_cond_t *cond; { /* Make sure we are alone. */ lll_mutex_lock (cond->__data.__lock); /* Are there any waiters to be woken? */ if (cond->__data.__total_seq > cond->__data.__wakeup_seq) { /* Yes. Mark one of them as woken. */ ++cond->__data.__wakeup_seq; ++cond->__data.__futex; /* Wake one. */ lll_futex_wake (&cond->__data.__futex, 1); } /* We are done. */ lll_mutex_unlock (cond->__data.__lock); return 0; } So it looks like there is some kind of low level mutex locking involved even when signalling a condition. Can't this also lead to priority inversion? So what is the best way to achieve that some lower priority thread will definitely wakeup from a realtime priority thread, without causing priority inversion, under recent linux kernels? Cu... Stefan -- Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan From paul at linuxaudiosystems.com Mon Jun 5 07:14:07 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Mon Jun 5 07:14:06 2006 Subject: [linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write In-Reply-To: <20060604232101.GA29257@space.twc.de> References: <20060604232101.GA29257@space.twc.de> Message-ID: <1149506048.11527.198.camel@localhost.localdomain> On Mon, 2006-06-05 at 01:21 +0200, Stefan Westerfeld wrote: > Hi! > > I am trying to notify a high priority (nice -20 or nice -19) thread from > a realtime thread (from a jack callback to be precise). Of course I want > the realtime thread to not block, but I want the high priority thread to > react as soon as possible. For the first implementation, I used a > condition, and pthread_cond_signal. But as I can't aquire a mutex within > the realtime thread, at least not always (at most with trylock()), this > results in racy code. int pipes[2]; RT-thread: char c; write (pipes[0], &c, 1); other-thread: poll (.... on pipes[1] ... and others) writing to a pipe is not 100% RT safe, but if the pipe is created in a shm filesystem, its as close to it as you will get without ... futexes, which are used by current NPTL code for pthread signalling. they can still block, but they have the benefit that you do not need new code to use them - just use pthreads calls. this is why JACK (which uses the pipe model) puts its pipes into a shm filesystem by the way - not doing so leads to horrible xruns on most systems because locking the pipe involves interactions with a real filesystem on disk. > Now the question is: am I producing priority inversion, then? I've seen > that the kernel code of pipe write has code like > > mutex_lock(PIPE_MUTEX(*inode)); > > (in fs/pipe.c, linux-2.6.16.16), so can this mutex cause priority > inversion? no, because the high priority thread cannot wake up take the lock - the RT thread is already holding it. priority inversion happens when an higher thread attempts to acquire a lock currently held by a lower priority thread. in the design of a system based around relatively long time intervals between lock acquisition (10ths of msecs to many msecs), the high priority thread will always be acquiring the lock again long after the lower priority thread has finished with it. if you want to get all theoretical, then yes, any scheme that involves interactions between higher and lower priority thread can lead to priority inversion if there is no system-level help to prevent it. but in systems built around the data flow inherent in all current audio and video interfaces, it does not need to be an issue. if you cannot ensure that the low priority thread will release the lock long before the high priority needs it again, i'd suggest a redesign of your code. it will happen more quickly than the kernel acquiring priority inversion support. --p From radarsat1 at gmail.com Mon Jun 5 10:12:16 2006 From: radarsat1 at gmail.com (Steve) Date: Mon Jun 5 10:12:30 2006 Subject: [linux-audio-dev] real time priority programming tutorial In-Reply-To: References: Message-ID: <9b3e2dc20606050712y73e5cf89ubbde34d1e5fe05e5@mail.gmail.com> Here is essentially the code I have been using for this purpose. You don't necessarily need to use max priority for sp.sched_priority. There may be better ways of doing this, I guess... if anyone sees if I'm missing something. Seems to work, but has the disadvantage of having to run under "sudo" to gain the priority. I'm not 100% sure if the mlockall call is necessary. void set_process_highpriority() { /* Lock memory for better realtime response */ mlockall(MCL_FUTURE | MCL_CURRENT); /* Set realtime scheduler policy, with a high priority. */ sched_param sp; sched_getparam(getpid(), &sp); sp.sched_priority = sched_get_priority_min(SCHED_FIFO); sched_setscheduler(getpid(), SCHED_FIFO, &sp); if (sched_getscheduler(getpid()) != SCHED_FIFO) printf ("Warning: Could not set realtime scheduler policy. Servoloop may be slow.\n" " Try running as superuser.\n"); } From cuse at users.sourceforge.net Mon Jun 5 12:38:19 2006 From: cuse at users.sourceforge.net (Christian Schoenebeck) Date: Mon Jun 5 12:40:16 2006 Subject: [linux-audio-dev] real time priority programming tutorial In-Reply-To: <9b3e2dc20606050712y73e5cf89ubbde34d1e5fe05e5@mail.gmail.com> References: <9b3e2dc20606050712y73e5cf89ubbde34d1e5fe05e5@mail.gmail.com> Message-ID: <200606051838.20711.cuse@users.sourceforge.net> Am Montag, 5. Juni 2006 16:12 schrieb Steve: > Here is essentially the code I have been using for this purpose. > You don't necessarily need to use max priority for sp.sched_priority. > There may be better ways of doing this, I guess... if anyone sees if > I'm missing something. Seems to work, but has the disadvantage of > having to run under "sudo" to gain the priority. Depends on your system configuration. I don't have to call it as super user on my system. > I'm not 100% sure if the mlockall call is necessary. mlockall avoids memory swapping, so as long as you haven't completely turned off swapping in your system it's definitely a good idea to call mlockall in a RT sensitive process. If you're not a C++ hater, here's a general purpose "Thread" class which can be used for RT threads and low priority threads as well: http://cvs.linuxsampler.org/cgi-bin/viewcvs.cgi/linuxsampler/src/common/Thread.h http://cvs.linuxsampler.org/cgi-bin/viewcvs.cgi/linuxsampler/src/common/Thread.cpp Just derive from that abstract "Thread" class and implement the virtual method "int Main()" in your class. CU Christian From jussi.laako at pp.inet.fi Wed Jun 7 04:12:44 2006 From: jussi.laako at pp.inet.fi (Jussi Laako) Date: Wed Jun 7 04:13:49 2006 Subject: [linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write In-Reply-To: <1149506048.11527.198.camel@localhost.localdomain> References: <20060604232101.GA29257@space.twc.de> <1149506048.11527.198.camel@localhost.localdomain> Message-ID: <44868A7C.40204@pp.inet.fi> Paul Davis wrote: > writing to a pipe is not 100% RT safe, but if the pipe is created in a > shm filesystem, its as close to it as you will get without ... Nowadays, there's also available a very good interface from POSIX RT extensions; posix message queues. See mq_send(3). You can use either mq_receive(3) or mq_notify(3) for reception of the message. I also measured posix message queues to be about twice as fast as for example local (unix) sockets. Now that Linux systems generally are pretty close to full POSIX (IEEE-1003.1) compliance, I don't see any reason why not to make advantage of it. - Jussi From paul at linuxaudiosystems.com Wed Jun 7 08:49:38 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Wed Jun 7 08:49:42 2006 Subject: [linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write In-Reply-To: <44868A7C.40204@pp.inet.fi> References: <20060604232101.GA29257@space.twc.de> <1149506048.11527.198.camel@localhost.localdomain> <44868A7C.40204@pp.inet.fi> Message-ID: <1149684578.12354.62.camel@localhost.localdomain> On Wed, 2006-06-07 at 11:12 +0300, Jussi Laako wrote: > Paul Davis wrote: > > writing to a pipe is not 100% RT safe, but if the pipe is created in a > > shm filesystem, its as close to it as you will get without ... > > Nowadays, there's also available a very good interface from POSIX RT > extensions; posix message queues. See mq_send(3). You can use either > mq_receive(3) or mq_notify(3) for reception of the message. > > I also measured posix message queues to be about twice as fast as for > example local (unix) sockets. > > Now that Linux systems generally are pretty close to full POSIX > (IEEE-1003.1) compliance, I don't see any reason why not to make > advantage of it. nice to hear that they are faster. on the other hand, once again POSIX screws us all over by not integrating everything into a single blocking wait call. i've said it before, i'll say it again - this is one of the few things that the win32 API gets right - you can block in one call on almost *anything*. AFAICT, you cannot select/poll on a msg queue. From jussi.laako at pp.inet.fi Wed Jun 7 12:22:47 2006 From: jussi.laako at pp.inet.fi (Jussi Laako) Date: Wed Jun 7 12:24:43 2006 Subject: [linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write In-Reply-To: <1149684578.12354.62.camel@localhost.localdomain> References: <20060604232101.GA29257@space.twc.de> <1149506048.11527.198.camel@localhost.localdomain> <44868A7C.40204@pp.inet.fi> <1149684578.12354.62.camel@localhost.localdomain> Message-ID: <4486FD57.5020405@pp.inet.fi> Paul Davis wrote: > nice to hear that they are faster. on the other hand, once again POSIX > screws us all over by not integrating everything into a single blocking > wait call. i've said it before, i'll say it again - this is one of the > few things that the win32 API gets right - you can block in one call on > almost *anything*. AFAICT, you cannot select/poll on a msg queue. POSIX message queues are not very new concept anyway, it dates back to 1993. However, I have to admit that I liked the old QNX concept of send/receive/reply more. That's true. On the other hand you can have multiple sending parties on single queue, so you don't necessarily have to sleep on anything else. Or you can be signal-like asynchronously woken up when something arrives on message queue. Imo, generic concept on having to do something like select/poll on multiple descriptors can be problematic. And you cannot assign priorities for the descriptor like you can do for messages in message queue. Most of the real realtime operating systems are completely based on message queues and message passing. Message queues need slightly different way of thinking, but on the other hand, overcome some scheduling related problems when compared to pipe-like implementations where you don't explicitly specify message length, nor have priorities. - Jussi From kouhia at nic.funet.fi Wed Jun 7 14:35:10 2006 From: kouhia at nic.funet.fi (Juhana Sadeharju) Date: Wed Jun 7 14:35:25 2006 Subject: [linux-audio-dev] Re: real time priority programming tutorial Message-ID: >From: Alex > >Does anyone have a link to a reference about making apps with real >time priority capabilities? >I figure I can just look at jack but it would be nice see some >tutorial, to learn what is actually happening/necessary, trade-offs, >etc. I suggest to look at source codes. They give up-to-date info and a working solution. Saves time. There are also documentation on general realtime programming. E.g., I have found the following: http://www.funet.fi/~kouhia/APS33DTE.PDF http://www.funet.fi/~kouhia/sgirealtime.pdf http://www.funet.fi/~kouhia/sgitopics.pdf More recent versions could be found if you check their site. Other system makers could have equivalent docs (apple, microsoft). Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software From fons.adriaensen at skynet.be Wed Jun 7 14:32:44 2006 From: fons.adriaensen at skynet.be (Fons Adriaensen) Date: Wed Jun 7 17:35:40 2006 Subject: [linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write In-Reply-To: <1149684578.12354.62.camel@localhost.localdomain> References: <20060604232101.GA29257@space.twc.de> <1149506048.11527.198.camel@localhost.localdomain> <44868A7C.40204@pp.inet.fi> <1149684578.12354.62.camel@localhost.localdomain> Message-ID: <20060607183244.GA5937@linux-1.site> On Wed, Jun 07, 2006 at 08:49:38AM -0400, Paul Davis wrote: > nice to hear that they are faster. on the other hand, once again POSIX > screws us all over by not integrating everything into a single blocking > wait call. i've said it before, i'll say it again - this is one of the > few things that the win32 API gets right - you can block in one call on > almost *anything*. AFAICT, you cannot select/poll on a msg queue. You can build such a thing on top of condition variables - that is what they exists for - to let a thread wait one any condition you may want, no matter how complicated. It's possible to do this in a very 'clean' way in C++. First create 'service' classes for all the basic services you need: message boxes, pipes, counting semaphores, whatever. These classes should be handling the data only, not synchronisation. Derive them all from an abstract base class that interfaces their state changes to a second set of 'synchro' classes. Each of these uses just *one* condition variable, and that is the thing a thread waits for, by calling a 'synchro' object's wait(). Since _you_ design the condition in the 'synchro' objects it could be anything you want, from simple readyness of any element in the collection of 'service' objects you wait for (similar to poll/select) up to things such as 'wake me up when all of mailboxes #1, #3 and #6 have some data and sema #5 has at least a count of ten'. You could design a number of standard 'synchro' classes (as in libclthreads), and/or create ad-hoc ones when you need them. The problem then is all the system calls that use file descriptors, as they don't provide the interface of the 'service' base class. One solution is to delegate all use of such interfaces to 'helper threads' that each wait on a single file, socket, or whatever. You may want this delegation anyway for other reasons, e.g. disk threads that read/write audio files in the background, or a thread that receives and decodes OSC commands. -- FA Follie! Follie! Delirio vano e' questo! From rlrevell at joe-job.com Wed Jun 7 17:42:26 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Jun 7 17:42:57 2006 Subject: [linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write In-Reply-To: <20060607183244.GA5937@linux-1.site> References: <20060604232101.GA29257@space.twc.de> <1149506048.11527.198.camel@localhost.localdomain> <44868A7C.40204@pp.inet.fi> <1149684578.12354.62.camel@localhost.localdomain> <20060607183244.GA5937@linux-1.site> Message-ID: <1149716547.2592.13.camel@mindpipe> On Wed, 2006-06-07 at 20:32 +0200, Fons Adriaensen wrote: > On Wed, Jun 07, 2006 at 08:49:38AM -0400, Paul Davis wrote: > > > nice to hear that they are faster. on the other hand, once again POSIX > > screws us all over by not integrating everything into a single blocking > > wait call. i've said it before, i'll say it again - this is one of the > > few things that the win32 API gets right - you can block in one call on > > almost *anything*. AFAICT, you cannot select/poll on a msg queue. > > You can build such a thing on top of condition variables - that > is what they exists for - to let a thread wait one any condition > you may want, no matter how complicated. > But, from the original post it seems that pthread_cond_signal is not realtime safe as it locks a mutex: __pthread_cond_signal (cond) pthread_cond_t *cond; { /* Make sure we are alone. */ lll_mutex_lock (cond->__data.__lock); /* Are there any waiters to be woken? */ if (cond->__data.__total_seq > cond->__data.__wakeup_seq) { /* Yes. Mark one of them as woken. */ ++cond->__data.__wakeup_seq; ++cond->__data.__futex; /* Wake one. */ lll_futex_wake (&cond->__data.__futex, 1); } /* We are done. */ lll_mutex_unlock (cond->__data.__lock); return 0; } How can glibc guarantee that we are not put to sleep if there is contention? Lee From fons.adriaensen at skynet.be Wed Jun 7 18:09:42 2006 From: fons.adriaensen at skynet.be (Fons Adriaensen) Date: Wed Jun 7 18:09:54 2006 Subject: [linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write In-Reply-To: <1149716547.2592.13.camel@mindpipe> References: <20060604232101.GA29257@space.twc.de> <1149506048.11527.198.camel@localhost.localdomain> <44868A7C.40204@pp.inet.fi> <1149684578.12354.62.camel@localhost.localdomain> <20060607183244.GA5937@linux-1.site> <1149716547.2592.13.camel@mindpipe> Message-ID: <20060607220942.GA5899@linux-1.site> On Wed, Jun 07, 2006 at 05:42:26PM -0400, Lee Revell wrote: > But, from the original post it seems that pthread_cond_signal is not > realtime safe as it locks a mutex: > ... > How can glibc guarantee that we are not put to sleep if there is > contention? The mutex associated with a CV is held only - by the sender while modifying the condition - by the receiver while checking the condition So it is not held by the receiver while it is descheduled and waiting. Suppose you use a CV from a JACK process callback to tell some other thread in your app that a period of new samples is now available in a circular buffer. There is a _very small_ chance that the mutex you need to take is held by the receiving thread - this will happen if JACK's thread pre-empted the receiver at exactly the moment it was checking the condition, i.e. in between its mutex_lock() and pthread_cond_wait (). In that case, if you used mutex_lock(), the receiver will take over for a very short time until it calls pthread_cond_wait(), and you will be able to continue after that. If that is not acceptable (i.e. if you have a *very* short period time), use mutex_try_lock() instead. If it fails, don't do the pthread_cond_signal() but remember you have to signal two periods next time. -- FA Follie! Follie! Delirio vano e' questo! From drobilla at connect.carleton.ca Wed Jun 7 21:04:45 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Wed Jun 7 21:06:32 2006 Subject: [linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write In-Reply-To: <1149716547.2592.13.camel@mindpipe> References: <20060604232101.GA29257@space.twc.de> <1149506048.11527.198.camel@localhost.localdomain> <44868A7C.40204@pp.inet.fi> <1149684578.12354.62.camel@localhost.localdomain> <20060607183244.GA5937@linux-1.site> <1149716547.2592.13.camel@mindpipe> Message-ID: <1149728686.4812.4.camel@DaveLap> On Wed, 2006-06-07 at 17:42 -0400, Lee Revell wrote: > On Wed, 2006-06-07 at 20:32 +0200, Fons Adriaensen wrote: > > On Wed, Jun 07, 2006 at 08:49:38AM -0400, Paul Davis wrote: > > > > > nice to hear that they are faster. on the other hand, once again POSIX > > > screws us all over by not integrating everything into a single blocking > > > wait call. i've said it before, i'll say it again - this is one of the > > > few things that the win32 API gets right - you can block in one call on > > > almost *anything*. AFAICT, you cannot select/poll on a msg queue. > > > > You can build such a thing on top of condition variables - that > > is what they exists for - to let a thread wait one any condition > > you may want, no matter how complicated. > > > > But, from the original post it seems that pthread_cond_signal is not > realtime safe as it locks a mutex: The big question is: who cares? :) sem_post() is. A mutex/cond pair is just a big ugly slow non-RT-safe semaphore anyway. -DR- From tim at quitte.de Thu Jun 8 13:06:18 2006 From: tim at quitte.de (Tim Goetze) Date: Thu Jun 8 13:10:38 2006 Subject: [linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write In-Reply-To: <1149684578.12354.62.camel@localhost.localdomain> References: <20060604232101.GA29257@space.twc.de> <1149506048.11527.198.camel@localhost.localdomain> <44868A7C.40204@pp.inet.fi> <1149684578.12354.62.camel@localhost.localdomain> Message-ID: [Paul Davis] >On Wed, 2006-06-07 at 11:12 +0300, Jussi Laako wrote: >> Paul Davis wrote: >> > writing to a pipe is not 100% RT safe, but if the pipe is created in a >> > shm filesystem, its as close to it as you will get without ... >> >> Nowadays, there's also available a very good interface from POSIX RT >> extensions; posix message queues. See mq_send(3). You can use either >> mq_receive(3) or mq_notify(3) for reception of the message. >> >> I also measured posix message queues to be about twice as fast as for >> example local (unix) sockets. >> >> Now that Linux systems generally are pretty close to full POSIX >> (IEEE-1003.1) compliance, I don't see any reason why not to make >> advantage of it. > >nice to hear that they are faster. on the other hand, once again POSIX >screws us all over by not integrating everything into a single blocking >wait call. i've said it before, i'll say it again - this is one of the >few things that the win32 API gets right - you can block in one call on >almost *anything*. AFAICT, you cannot select/poll on a msg queue. actually, according to my copy of /usr/src/linux/ipc/mqueue.c and http://laurel.datsi.fi.upm.es/web/cgi-bin/man/man2html?7+mq_overview linux takes us out of the posix stone age and implements the poll syscall on message queues (which are simple file descriptors to a linux application). thanks kernel guys! portability questions aside, it remains the question whether mqd_t is significantly faster than an ordinary pipe when used with poll(). cheers, tim From fw at deneb.enyo.de Thu Jun 8 12:10:16 2006 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu Jun 8 13:56:55 2006 Subject: [linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write In-Reply-To: <20060607183244.GA5937@linux-1.site> (Fons Adriaensen's message of "Wed, 7 Jun 2006 20:32:44 +0200") References: <20060604232101.GA29257@space.twc.de> <1149506048.11527.198.camel@localhost.localdomain> <44868A7C.40204@pp.inet.fi> <1149684578.12354.62.camel@localhost.localdomain> <20060607183244.GA5937@linux-1.site> Message-ID: <87wtbrr5lj.fsf@mid.deneb.enyo.de> * Fons Adriaensen: > You can build such a thing on top of condition variables - that > is what they exists for - to let a thread wait one any condition > you may want, no matter how complicated. But don't you need an additional context switch, from the event listener thread to the actual processing thread? You could use a leader/followers scheme to deal with this, I think, but it's quite complicated. Doing it in the kernel would probably reduce overall complexity. From jussi.laako at pp.inet.fi Thu Jun 8 16:25:10 2006 From: jussi.laako at pp.inet.fi (Jussi Laako) Date: Thu Jun 8 16:25:51 2006 Subject: [linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write In-Reply-To: <1149716547.2592.13.camel@mindpipe> References: <20060604232101.GA29257@space.twc.de> <1149506048.11527.198.camel@localhost.localdomain> <44868A7C.40204@pp.inet.fi> <1149684578.12354.62.camel@localhost.localdomain> <20060607183244.GA5937@linux-1.site> <1149716547.2592.13.camel@mindpipe> Message-ID: <448887A6.2090509@pp.inet.fi> Lee Revell wrote: > But, from the original post it seems that pthread_cond_signal is not > realtime safe as it locks a mutex: Just about any syscall nowadays potentially acquires some sort of lock inside kernel. - Jussi From rlrevell at joe-job.com Thu Jun 8 16:31:03 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Thu Jun 8 16:32:19 2006 Subject: [linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write In-Reply-To: <448887A6.2090509@pp.inet.fi> References: <20060604232101.GA29257@space.twc.de> <1149506048.11527.198.camel@localhost.localdomain> <44868A7C.40204@pp.inet.fi> <1149684578.12354.62.camel@localhost.localdomain> <20060607183244.GA5937@linux-1.site> <1149716547.2592.13.camel@mindpipe> <448887A6.2090509@pp.inet.fi> Message-ID: <1149798664.3894.71.camel@mindpipe> On Thu, 2006-06-08 at 23:25 +0300, Jussi Laako wrote: > Lee Revell wrote: > > But, from the original post it seems that pthread_cond_signal is not > > realtime safe as it locks a mutex: > > Just about any syscall nowadays potentially acquires some sort of lock > inside kernel. The code in question was fron glibc, not the kernel. Lee From ivarga at csounds.com Fri Jun 9 15:58:59 2006 From: ivarga at csounds.com (Istvan Varga) Date: Fri Jun 9 17:01:19 2006 Subject: [linux-audio-dev] [ANN] Csound 5.02 release Message-ID: <200606092158.59326.ivarga@csounds.com> Links to downloadable packages can be found here: http://csound.sourceforge.net/ Changes in version 5.02: 2006-06-04 Michael Gogins * Changed the MIDI interoperability opcodes (OOps/midiinterop.c) midinoteoncps, midinoteonoct, midinoteonpch to leave key and velocity unchanged for score-driven performance. 2006-06-04 Istvan Varga * Engine/otran.c: work around constndx() not being compiled correctly 2006-06-03 Istvan Varga * Engine/fgens.c, InOut/libsnd_u.c, OOps/diskin.c, OOps/diskin2.c: GEN01, diskin, diskin2, soundin: with an iformat value of -1, reject headerless files, rather than assuming the same format as the one specified on the command line GEN01: added format codes 7 (8 bit unsigned), 8 (24 bit), and 9 (doubles) * Engine/entry1.c, H/sndinfUG.h, OOps/sndinfUG.c: filelen, filenchnls, filesr: added optional i-time argument that defaults to 1, and if zero, will make the opcodes return zero on headerless files rather than some possibly incorrect defaults * Opcodes/fout.c: fixed bug in fini opcode (negative numbers were read incorrectly) * Engine/sread.c, Engine/swrite.c, Engine/twarp.c: fixes to reading numbers in [] score expressions fixed 's' and 'e' score opcodes with time parameter 2006-06-02 Istvan Varga * New string opcodes: Sdst strsub Ssrc[, istart[, iend]] Sdst strsubk Ssrc, kstart, kend ichr strchar Sstr[, ipos] kchr strchark Sstr[, kpos] ilen strlen Sstr klen strlenk Sstr Sdst strupper Ssrc Sdst strupperk Ssrc Sdst strlower Ssrc Sdst strlowerk Ssrc Sval getcfg iopt ipos strindex Sstr1, Sstr2 kpos strindexk Sstr1, Sstr2 ipos strrindex Sstr1, Sstr2 kpos strrindexk Sstr1, Sstr2 * Engine/express.c, Engine/otran.c: fixed parsing of numbers in exponential notation also some parser fixes related to 0dbfs 2006-06-01 Istvan Varga * Added callback interface to the software bus with named channels, using new opcodes chnrecv and chnsend. The callback function can be set with csoundSetChannelIOCallback(). 2006-05-31 jpff * util/sndinfo.c: Added option to print looping information etc. 2006-05-31 Istvan Varga * InOut/widgets.cpp: FLbutton type 1 callback now sets the output to "ion" 2006-05-30 Istvan Varga * Opcodes/fout.c: new opcode: ficlose 2006-05-30 ma++ ingalls * aops.c, aops.h, csound.h: invalue/outvalue updates as per Istvan's comments * csound.c: changed "early return" comments to debug only * hetro.c: added pollevents inside processing loop * lpanal.c: added warning message with -g flag * sockrecv.c: took out usleep() declaration - was causing compile error 2006-05-28 ma++ ingalls * frontends/CsoundX: added to cvs * aops.c, entry1.c, entry1.h, csound.h: added hack to invalue/outvalue to support strings 2006-05-27 Istvan Varga * Added ATS analysis utility. 2006-05-26 ma++ ingalls * frontends/CsoundVST/AEffect.h: commented out 2 PRAGMAS causing compile error on mac * Opcodes/vst4cs/vsthost.c: added plug-in loading for MACH-O mac. commented out #includes that caused compile error on mac * Opcodes/vst4cs/vsthost.h: commented out #includes that caused compile error on mac * Opcodes/vst4cs/fxbank.h: commented out #includes that caused compile error on mac * OOps/aops.c: added i-rate support to invalue/outvalue 2006-05-24 Istvan Varga * InOut/rtalsa.c: changed default device from "default" to "plughw" * InOut/rtjack.c: list available device names for -i adc or -o dac if an invalid device is specified 2006-05-23 Istvan Varga * Opcodes/ugnorman.c: fixed "not initialised" bug in ATSbufread 2006-05-22 Istvan Varga * OOps/midiops.c: massign(): interpret channel number <= 0 as all channels * H/csoundCore.h, Top/csound.c: added new function GetCurrentThreadID() to CSOUND structure 2006-05-21 Michael Gogins * New API function: csoundGetCurrentThreadId() 2006-05-20 Istvan Varga * Opcodes/stackops.c: added new stack opcodes (stack, push, pop, push_f, pop_f); also moved monitor opcode here. * Reworked user defined opcodes to allow for up to 256 input/output arguments. * Opcodes/bilbar.c: removed use of C++ style comments. 2006-05-16 jpff * Engine/entry1.c: Change args of xin to match OPCODENUMOUTS 2006-05-15 Anthony Kozar * Top/cscormai.c: Fixed #includes. * interfaces/CsoundFile.cpp: isspace() is in and supposed to be in std namespace * H/csoundCore.h: Increased OPCODENUMOUTS to 64 as requested. 2006-05-15 Istvan Varga * Opcodes/monitor.c: added new opcode: monitor 2006-05-14 jpff * util/pvlook.c (pvlook): Rewritten for .pvx format 2006-05-13 jpff * util/pvanal.c: Added -B # argument to give a beta to the Kaiser window; still defaults to 6.8 2006-05-12 Istvan Varga * frontends/csound/csound_main.c: overwrite old log files, rather than appending messages 2006-05-08 Istvan Varga * New API functions: csoundCreateMutex, csoundLockMutex, csoundLockMutexNoWait, csoundUnlockMutex, csoundDestroyMutex, csoundRunCommand 2006-05-04 Istvan Varga * InOut/rtalsa.c: added new "devfile" MIDI driver that uses device files in /dev, based on code from Csound 4.23 mididevice.c 2006-05-03 Istvan Varga * InOut/FL_graph.cpp, InOut/widgets.cpp: * InOut/winFLTK.c, InOut/winFLTK.h: added more FLTK flags (see winFLTK.h) 2006-05-02 Istvan Varga * InOut/widgets.cpp, InOut/winFLTK.c, InOut/winFLTK.h: disable threads by default if graphs are used * OOps/sndinfUG.c: filepeak opcode now uses PEAK chunks with libsndfile >= 1.0.16 2006-04-30 Istvan Varga * Attempt to fix thread locks on MacOS X. * util/srconv.c: fixed output amplitude when downsampling allow utility to be stopped by yield callback * install.py, installer/misc/mkpackage.py: install TclCsound command documentation 2006-04-29 Istvan Varga * Made it possible to control the behavior of the FLTK plugin from the host application. This can be done with the following code between calling csoundPreCompile() and csoundCompile(): CSOUND *csound; ... csoundCreateGlobalVariable(csound, "FLTK_Flags", sizeof(int)); *((int*) csoundQueryGlobalVariable(csound, "FLTK_Flags")) = flags; where 'flags' can be the sum of any of the following values: 1: disable widget opcodes 2: disable FLTK graphs 4: disable the use of a separate thread for widget opcodes 8: disable the use of Fl::lock() and Fl::unlock() 16: disable the use of Fl::awake() additionally, after calling csoundCompile(), the same variable can be checked to find out if graphs or widget opcodes are used: 32: FLrun opcode was called 64: callbacks for FLTK graphs are set * Top/main.c: fixed crash on registering opcodes from the host application * frontends/fltk_gui: new GUI frontend that uses the Csound 5 API and FLTK 2006-04-19 Michael gogins * Updated Lua to version 5.1 (current version), changed lua_example.lua to use Class:method calls. 2006-04-17 John ffitch * Opcodes/bilbar.c: Added prepared piano string model * H/entry1.h: * Engine/entry1.c: Added remove opcode. Probably should be an API function rather than opcode * Engine/insert.c (delete_instr): New code to delete non-active instruments. Still needs to be checked as it may leave structures dangling. 2006-04-15 Istvan Varga * Engine/namedins.c, Engine/otran.c: optimizations in orchestra parser * interfaces/lua_interface.i: wrap cs_glue.hpp and csPerfThread.hpp 2006-04-09 Istvan Varga * Engine/envvar.c: csoundFileOpen(): check for files with .sd2 extension, and use sf_open() in this case if sf_open_fd() fails * InOut/FL_graph.cpp: wait for the window to be closed by the user at end of performance * InOut/libsnd.c: fixes in enabling peak chunks and dithering * InOut/libsnd_u.c: type2string(): added SD2 to file types * InOut/rtpa.c: print warning if the buffer size (-b) is not an integer multiple of ksmps in full-duplex mode * InOut/window.c: moved deferred loading of widgets plugin from main.c to make graphs work in utilities * Opcodes/compress.c: made rms levels relative to 0dBFS in distort opcode * H/csoundCore.h, Top/csound.c: added dispinit() function pointer to CSOUND structure, for use by utilities * H/version.h: updated API version to 1.01 to reflect change to CSOUND structure * util/pvanal.c: implemented graph displays (limited to 30 frames at this time) * util/sndinfo.c: clear SF_INFO structure before calling sf_open() 2006-04-08 Istvan Varga * OOps/sndinfUG.c: restored filepeak opcode 2006-04-07 Istvan Varga * H/version.h: updated version number to 5.02.0 to reflect addition of new opcodes * Opcodes/compress.c: fixed a few minor errors 2006-04-04 Michael Gogins * Changed FluidSynth opcodes slightly, with fluidEngine iChorusOn, iReverbOn pfields, defaulting to "on"; this can reduce noise in low frequencies in SoundFont rendering. * Updated Windows FluidSynth opcodes to use latest FluidSynth sources. 2006-03-28 jpff * Opcodes/compress.c: New code for distort and compress/expander from Barry Vercoe 2006-03-25 Istvan Varga * Engine/entry1.c, H/aops.h, H/entry1.h, OOps/bus.c, opcodes.dir, Opcodes/pitch.c, Opcodes/pitch.h, Opcodes/spectra.c, Top/csound.c: fixes in sensekey opcode 2006-03-22 Michael Gogins * Added ScoreGeneratorVST, a VST plugin for generating scores in VST hosts using Python. * Updated Windows installer for new targets, including Winsound. 2006-03-22 Istvan Varga * interfaces/cs_glue.cpp: * interfaces/cs_glue.hpp: - added new classes to wrap MIDI I/O: CsoundMidiInputStream sends MIDI input messages CsoundMidiOutputStream polls MIDI output messages - added MIDI I/O callbacks to CsoundCallbackWrapper - made it possible to use the message buffer in multiple threads, to allow for redirecting the message output of a CsoundPerformanceThread 2006-03-21 Istvan Varga * SConstruct, Makefile-win32: renamed Csound library to csound{32,64}.dll.5.1 on Windows * SConstruct: attempts to fix install target (still needs a lot of work) * Engine/namedins.c, OOps/bus.c: fixed a-rate channel allocation in user defined opcode with local ksmps * Engine/linevent.c: various minor fixes and code improvements From stefan at space.twc.de Fri Jun 9 18:37:39 2006 From: stefan at space.twc.de (Stefan Westerfeld) Date: Fri Jun 9 18:17:18 2006 Subject: [linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write In-Reply-To: <1149728686.4812.4.camel@DaveLap> References: <20060604232101.GA29257@space.twc.de> <1149506048.11527.198.camel@localhost.localdomain> <44868A7C.40204@pp.inet.fi> <1149684578.12354.62.camel@localhost.localdomain> <20060607183244.GA5937@linux-1.site> <1149716547.2592.13.camel@mindpipe> <1149728686.4812.4.camel@DaveLap> Message-ID: <20060609223739.GA32237@space.twc.de> Hi! On Wed, Jun 07, 2006 at 09:04:45PM -0400, Dave Robillard wrote: > On Wed, 2006-06-07 at 17:42 -0400, Lee Revell wrote: > > On Wed, 2006-06-07 at 20:32 +0200, Fons Adriaensen wrote: > > > On Wed, Jun 07, 2006 at 08:49:38AM -0400, Paul Davis wrote: > > > > > > > nice to hear that they are faster. on the other hand, once again POSIX > > > > screws us all over by not integrating everything into a single blocking > > > > wait call. i've said it before, i'll say it again - this is one of the > > > > few things that the win32 API gets right - you can block in one call on > > > > almost *anything*. AFAICT, you cannot select/poll on a msg queue. > > > > > > You can build such a thing on top of condition variables - that > > > is what they exists for - to let a thread wait one any condition > > > you may want, no matter how complicated. > > > > > > > But, from the original post it seems that pthread_cond_signal is not > > realtime safe as it locks a mutex: > > The big question is: who cares? :) sem_post() is. A mutex/cond pair is > just a big ugly slow non-RT-safe semaphore anyway. As far as I understand from the linux-2.6.16.16 and glibc-2.3.6 code, a semaphore has similar problems, as sem_post() is implemented in terms of futexes on newer linuxes, and futexes have a list of waiters, which is protected by a lock within the kernel. But the unlikelyness of a priority inversion problem that has been pointed out by others probably applies to any of the synchronization primitives that came up in this thread, be it conditions, pipes or semaphores. Cu... Stefan -- Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan From drobilla at connect.carleton.ca Fri Jun 9 22:03:14 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Fri Jun 9 22:03:26 2006 Subject: [linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write In-Reply-To: <20060609223739.GA32237@space.twc.de> References: <20060604232101.GA29257@space.twc.de> <1149506048.11527.198.camel@localhost.localdomain> <44868A7C.40204@pp.inet.fi> <1149684578.12354.62.camel@localhost.localdomain> <20060607183244.GA5937@linux-1.site> <1149716547.2592.13.camel@mindpipe> <1149728686.4812.4.camel@DaveLap> <20060609223739.GA32237@space.twc.de> Message-ID: <1149904994.7931.3.camel@localhost.localdomain> On Sat, 2006-06-10 at 00:37 +0200, Stefan Westerfeld wrote: > Hi! > > On Wed, Jun 07, 2006 at 09:04:45PM -0400, Dave Robillard wrote: > > On Wed, 2006-06-07 at 17:42 -0400, Lee Revell wrote: > > > On Wed, 2006-06-07 at 20:32 +0200, Fons Adriaensen wrote: > > > > On Wed, Jun 07, 2006 at 08:49:38AM -0400, Paul Davis wrote: > > > > > > > > > nice to hear that they are faster. on the other hand, once again POSIX > > > > > screws us all over by not integrating everything into a single blocking > > > > > wait call. i've said it before, i'll say it again - this is one of the > > > > > few things that the win32 API gets right - you can block in one call on > > > > > almost *anything*. AFAICT, you cannot select/poll on a msg queue. > > > > > > > > You can build such a thing on top of condition variables - that > > > > is what they exists for - to let a thread wait one any condition > > > > you may want, no matter how complicated. > > > > > > > > > > But, from the original post it seems that pthread_cond_signal is not > > > realtime safe as it locks a mutex: > > > > The big question is: who cares? :) sem_post() is. A mutex/cond pair is > > just a big ugly slow non-RT-safe semaphore anyway. > > As far as I understand from the linux-2.6.16.16 and glibc-2.3.6 code, > a semaphore has similar problems, as sem_post() is implemented in terms > of futexes on newer linuxes, and futexes have a list of waiters, which > is protected by a lock within the kernel. Well, sem_post is supposed to be async-signal safe (meaning it can't be preempted, meaning it's realtime safe). If the Linux people have broken that, they have done an evil stupid thing. POSIX semaphores are great, especially since you can (or at least should, apparently) signal things from signal callbacks and realtime threads with them (they work great for event-driven systems). Are you sure? Link? -DR- From seablaede at gmail.com Sat Jun 10 15:18:04 2006 From: seablaede at gmail.com (Thomas Vecchione) Date: Sat Jun 10 14:14:04 2006 Subject: [linux-audio-dev] Problems With QT Message-ID: <448B1AEC.4080706@gmail.com> Ok I apologize as this wont deal specificly with Linux, but I am working on a program that will be deployed on Qtopia I hope on a PDA, along with used on all three desktop platforms, so I suppose it qualifies;) The problem is that I am trying to develop it on my Mac which is all I have with me at the moment(My linux machine is at my house which I wont be at for several months while I work a gig out elsewhere). I am having problems getting Qt working correctly on the Mac, after a fair amount of work I think I finally got it to the point where it should be working, but it seems to be having problems with my version of the Mac OS and I figured I would toss it out here to see if anyone could help... This is a simple hello world application to confirm Qt is working... > Kraken:~/Documents/Code/HelloWorld seablade$ makec++ -c -pipe -g -Wall > -W -F/usr/local/Trolltech/Qt-4.1.3/lib -D__USE_WS_X11__ -DQT_GUI_LIB > -DQT_CORE_LIB -DQT_SHARED > -I/usr/local/Trolltech/Qt-4.1.3/mkspecs/darwin-g++ -I. > -I/usr/local/Trolltech/Qt-4.1.3/lib/QtCore.framework/Versions/4.0/Headers > -I/usr/local/Trolltech/Qt-4.1.3/include/QtCore > -I/usr/local/Trolltech/Qt-4.1.3/lib/QtGui.framework/Versions/4.0/Headers > -I/usr/local/Trolltech/Qt-4.1.3/include/QtGui > -I/usr/local/Trolltech/Qt-4.1.3/include -I. -I. -I. > -I/usr/local/include -o hello.o hello.cpp > In file included from > /usr/local/Trolltech/Qt-4.1.3/include/QtCore/qnamespace.h:27, > from > /usr/local/Trolltech/Qt-4.1.3/include/QtCore/qobjectdefs.h:27, > from > /usr/local/Trolltech/Qt-4.1.3/include/QtCore/qobject.h:29, > from > /usr/local/Trolltech/Qt-4.1.3/include/QtCore/qcoreapplication.h:27, > from > /usr/local/Trolltech/Qt-4.1.3/lib/QtGui.framework/Versions/4.0/Headers/QApplication.h:27, > from hello.cpp:1: > /usr/local/Trolltech/Qt-4.1.3/include/QtCore/qglobal.h: In function `int > qMacVersion()': > /usr/local/Trolltech/Qt-4.1.3/include/QtCore/qglobal.h:1038: error: ` > MacintoshVersion' is not a member of type `QSysInfo' > make: *** [hello.o] Error 1 Nothing wrong in the code that I wrote, but it seems to be having problems with the Mac Version, and I am not sure if there was some variable or something I missed setting? For some reason I always have much better luck developing on Linux than on either Windows or Mac... grr. Seablade From patrickkidd.lists at gmail.com Sun Jun 11 15:22:56 2006 From: patrickkidd.lists at gmail.com (Patrick Stinson) Date: Sun Jun 11 15:23:03 2006 Subject: [linux-audio-dev] Problems With QT In-Reply-To: <448B1AEC.4080706@gmail.com> References: <448B1AEC.4080706@gmail.com> Message-ID: <664bf2b80606111222m16809a9cndca9a7f7e0f240d3@mail.gmail.com> You are right, your question is out of context here. This list is for topics related to audio on linux, not everything on linux. You should go to www.trolltech.com, register for the qt-interest list, and post your question there. On 6/10/06, Thomas Vecchione wrote: > Ok I apologize as this wont deal specificly with Linux, but I am working > on a program that will be deployed on Qtopia I hope on a PDA, along with > used on all three desktop platforms, so I suppose it qualifies;) The > problem is that I am trying to develop it on my Mac which is all I have > with me at the moment(My linux machine is at my house which I wont be at > for several months while I work a gig out elsewhere). I am having > problems getting Qt working correctly on the Mac, after a fair amount of > work I think I finally got it to the point where it should be working, > but it seems to be having problems with my version of the Mac OS and I > figured I would toss it out here to see if anyone could help... > > This is a simple hello world application to confirm Qt is working... > > > Kraken:~/Documents/Code/HelloWorld seablade$ makec++ -c -pipe -g -Wall > > -W -F/usr/local/Trolltech/Qt-4.1.3/lib -D__USE_WS_X11__ -DQT_GUI_LIB > > -DQT_CORE_LIB -DQT_SHARED > > -I/usr/local/Trolltech/Qt-4.1.3/mkspecs/darwin-g++ -I. > > -I/usr/local/Trolltech/Qt-4.1.3/lib/QtCore.framework/Versions/4.0/Headers > > -I/usr/local/Trolltech/Qt-4.1.3/include/QtCore > > -I/usr/local/Trolltech/Qt-4.1.3/lib/QtGui.framework/Versions/4.0/Headers > > -I/usr/local/Trolltech/Qt-4.1.3/include/QtGui > > -I/usr/local/Trolltech/Qt-4.1.3/include -I. -I. -I. > > -I/usr/local/include -o hello.o hello.cpp > > In file included from > > /usr/local/Trolltech/Qt-4.1.3/include/QtCore/qnamespace.h:27, > > from > > /usr/local/Trolltech/Qt-4.1.3/include/QtCore/qobjectdefs.h:27, > > from > > /usr/local/Trolltech/Qt-4.1.3/include/QtCore/qobject.h:29, > > from > > /usr/local/Trolltech/Qt-4.1.3/include/QtCore/qcoreapplication.h:27, > > from > > /usr/local/Trolltech/Qt-4.1.3/lib/QtGui.framework/Versions/4.0/Headers/QApplication.h:27, > > from hello.cpp:1: > > /usr/local/Trolltech/Qt-4.1.3/include/QtCore/qglobal.h: In function `int > > qMacVersion()': > > /usr/local/Trolltech/Qt-4.1.3/include/QtCore/qglobal.h:1038: error: ` > > MacintoshVersion' is not a member of type `QSysInfo' > > make: *** [hello.o] Error 1 > > > Nothing wrong in the code that I wrote, but it seems to be having > problems with the Mac Version, and I am not sure if there was some > variable or something I missed setting? For some reason I always have > much better luck developing on Linux than on either Windows or Mac... grr. > > Seablade > -- Patrick Kidd Stinson http://www.patrickkidd.com/ http://pkaudio.sourceforge.net/ http://pksampler.sourceforge.net/ From capocasa at gmx.net Sun Jun 11 16:58:22 2006 From: capocasa at gmx.net (Carlo Capocasa) Date: Sun Jun 11 16:58:51 2006 Subject: [linux-audio-dev] Anyone wanna take over Shelljam? Message-ID: Well, I went down and write the kind of software only a musician could write, perfectly adapted to a musican's needs because the author is, himself, a musician. Unfortunately, those needs dwindled, as I spent so much time writing software I didn't have any time to make music anymore. So here's a brillintly conceived and hitherto well-executed program (I spend nights figuring out the simplest way to accomplish the task at hand, meticulously making use of advanced C++ features, and carefully selecting only the best and most-updated of libraries). Now I know this is some stuff people will want to use. Unfortunately, using the thing's a little like eating fried zucchini only half fried, of having a rare steak when all you can take is well done. (Not a bad joke for a vegan, huh?) I have to offer: * A convenient framework that is tested and works. It tickles high fidelity performance that I would not hesitate to use in professional production out of your cheap old $10 computer keyboard through the use of a smart little filtering algorithm. Using it, I have created the most amazing sounds with ZynAddSubFX that I have heard to date, with extremely little overhead. (Credit goes to Paul of course, I just the thing a little I/O voodoo and dynamics) * Using an input library platfrom that ALREADY HAS implementations for all major windowing systems (including X11, native Mac, DirectFB for the handheld people as well as some direct palm support). With this thing eventually we will be using our our old palm pilots (or some version thereof that includes WLAN) to remotely control our synths. Also, if your inclination is to write something low level, thousands of users will benefit from your work because you will code it not only for an obscure music program but for a true Swiss Army Knife of I/O. Very friendly developers and excellent recency of files. * Using THE very best real-time cross-platform MIDI library. Very easy to use, much easier than native ALSA and just as fast. Very portable, al through! * Ready road map adjusted perfectly to a real musician's needs in professional production and performance. Be the man who made the star! Features: * Extremely accurate (<15 CPU cycles) response keyboard stroke to MIDI converter * Even more accurate Mouse to MIDI controller message converter * Cheap keyboard support through elegant filter * Extremely portable * Very easy-to-use and widely supported hardware abstraction layer used * Excellent portable real time MIDI library used from the famous STK audio toolkit from the University of Columbia * Rock solid stable * Keyboard layout geared towards live performance * Project page set up and ready to use, account data waiting for transfer * Keystrokes read directly from hardware, no complexity through keymap localization * Support for text mode Possibilitites for extension: * XML based custom keymaps * keymap creation and loading GUI * friendly, untuitive libggi based GUI during play * 'non-blocking' libgii keyboard driver for testing a synth while manipulating parameters I have a clear vision of this project and remain available for consultation. Have fun with it guys! Eat up! Carlo From seablaede at gmail.com Sun Jun 11 19:18:16 2006 From: seablaede at gmail.com (Thomas Vecchione) Date: Sun Jun 11 18:14:06 2006 Subject: [linux-audio-dev] Problems With QT In-Reply-To: <664bf2b80606111222m16809a9cndca9a7f7e0f240d3@mail.gmail.com> References: <448B1AEC.4080706@gmail.com> <664bf2b80606111222m16809a9cndca9a7f7e0f240d3@mail.gmail.com> Message-ID: <448CA4B8.8000007@gmail.com> > You are right, your question is out of context here. This list is for > topics related to audio on linux, not everything on linux. You should > go to www.trolltech.com, register for the qt-interest list, and post > your question there. My impression was that it was for audio development on linux, as this question does relate to that, as it relates to an electronic libretto system for opera, and my intention was for deployment on primarily QT based handhelds. Yes the question in itself was rather general, however as I am already on to many lists as it is, and this is for development I was under the impression I didnt think it to far off topic thus why i posted. But that is fine, I have decided to dust of my Java anyways and skip the problem alltogether, I suppose we can consider this thread closed, should anyone wish to take a shot at it they can email me privately. Seablade From lars.luthman at gmail.com Mon Jun 12 07:56:09 2006 From: lars.luthman at gmail.com (Lars Luthman) Date: Mon Jun 12 07:56:24 2006 Subject: [linux-audio-dev] [ANN] GLASHCtl 0.2 Message-ID: <1150113369.8864.8.camel@localhost> GLASHCtl is a control applet for LASH. This is the first release. Other than my code it contains eggtrayicon.h and eggtrayicon.c (by Anders Carlsson and Jean-Yves Lefort), taken from libegg, and the LASH icon (by Thorsten Wilms) from the LASH project. A patch from Florian Schmidt, adding session renaming and directory switching, has also been applied. Get it at http://dino.nongnu.org/glashctl Attaching README: GLASHCTL ======================================================================= This is a simple applet for controlling the LASH Audio Session Handler. When you run it it will appear as a small LASH icon in your "notification area" or "system tray" (if your desktop manager is compatible with freedesktop.org's "System tray" standard, http://www.freedesktop.org/Standards/systemtray-spec). This is typically somewhere in the panel in KDE or GNOME. BUILDING IT ============================================================ To build this program you will need the following libraries: * libgtkmm (2.6.4 or newer) * libvte (0.11.15 or newer) * liblash (0.5.1 or newer) You will also need to have the LASH server, lashd, somewhere in your $PATH. To build the program with the default configuration (install in /usr/local, compile with -g -O2 etc), simply type 'make' in this directory. If you want to change the configuration, use the configure script (run configure --help for details). When you type 'make' a program called glashctl should be generated, and when you type 'make install' it should be installed on your system. You need to install it before you run it, otherwise it won't find the LASH icon file and will not start. USING IT ============================================================ To use the applet, simply run the program. If you have a standards-compliant system tray on your desktop a small LASH icon (a cardboard box with a soundwave on it) should appear there. It is probably insensitive (greyed out), unless you were already running lashd or have the LASH_START_SERVER environment variable set to 1. If you right-click the icon a menu will pop up where you can choose to start lashd. When lashd has started the icon should become sensitive (show colours), and you will be able to restore audio sessions, and when there is an active session, save it, close it, rename it or change its directory. You can also quit the applet from the popup menu. You can also left-click the icon to open a message window that shows information about the events received from lashd. NOTES ============================================================ The LASH icon was created by Thorsten Wilms for the LASH project (http://lash.nongnu.org). I know that the GNOME HIG discourages using the notification area for permanent icons and icons that have actions other than just opening a window associated with them, but until there is a standard for writing normal panel applets that work in both KDE and GNOME and in other window managers I'll do it anyway. Send bug reports and suggestions to Lars Luthman, lars.luthman@gmail.com -- Lars Luthman - please encrypt any email sent to me if possible PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E 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: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060612/bb94c9ff/attachment-0001.bin From mista.tapas at gmx.net Mon Jun 12 08:26:41 2006 From: mista.tapas at gmx.net (Florian Paul Schmidt) Date: Mon Jun 12 08:27:12 2006 Subject: [linux-audio-dev] [ANN] GLASHCtl 0.2 In-Reply-To: <1150113369.8864.8.camel@localhost> References: <1150113369.8864.8.camel@localhost> Message-ID: <20060612142641.1bb40bc6@mango.fruits> On Mon, 12 Jun 2006 13:56:09 +0200 Lars Luthman wrote: > To use the applet, simply run the program. If you have a > standards-compliant > system tray on your desktop a small LASH icon (a cardboard box with a > soundwave on it) should appear there. It is probably insensitive (greyed > out), unless you were already running lashd or have the > LASH_START_SERVER > environment variable set to 1. If you right-click the icon a menu will > pop up > where you can choose to start lashd. When lashd has started the icon > should You should maybe add that this will only work when jack is already started or JACK_START_SERVER is set in the environment. I haven't tried the 0.2 release, but the dev version i still run doesn't produce an error dialog if lashd failed to start. Maybe it should? Flo -- Palimm Palimm! http://tapas.affenbande.org From lars.luthman at gmail.com Tue Jun 13 12:11:05 2006 From: lars.luthman at gmail.com (Lars Luthman) Date: Tue Jun 13 12:11:29 2006 Subject: [linux-audio-dev] [ANN] GLASHCtl 0.2 In-Reply-To: <20060612142641.1bb40bc6@mango.fruits> References: <1150113369.8864.8.camel@localhost> <20060612142641.1bb40bc6@mango.fruits> Message-ID: <1150215065.8894.1.camel@localhost> On Mon, 2006-06-12 at 14:26 +0200, Florian Paul Schmidt wrote: > On Mon, 12 Jun 2006 13:56:09 +0200 > Lars Luthman wrote: > > > To use the applet, simply run the program. If you have a > > standards-compliant > > system tray on your desktop a small LASH icon (a cardboard box with a > > soundwave on it) should appear there. It is probably insensitive (greyed > > out), unless you were already running lashd or have the > > LASH_START_SERVER > > environment variable set to 1. If you right-click the icon a menu will > > pop up > > where you can choose to start lashd. When lashd has started the icon > > should > > You should maybe add that this will only work when jack is already > started or JACK_START_SERVER is set in the environment. Hm, true. I never even considered that option. Is anyone still starting jackd manually? > I haven't tried > the 0.2 release, but the dev version i still run doesn't produce an > error dialog if lashd failed to start. Maybe it should? Maybe. -- Lars Luthman - please encrypt any email sent to me if possible PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E 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: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060613/cb928d82/attachment.bin From mista.tapas at gmx.net Tue Jun 13 12:33:23 2006 From: mista.tapas at gmx.net (Florian Paul Schmidt) Date: Tue Jun 13 12:33:38 2006 Subject: [linux-audio-dev] [ANN] GLASHCtl 0.2 In-Reply-To: <1150215065.8894.1.camel@localhost> References: <1150113369.8864.8.camel@localhost> <20060612142641.1bb40bc6@mango.fruits> <1150215065.8894.1.camel@localhost> Message-ID: <20060613183323.0a432b5f@mango.fruits> On Tue, 13 Jun 2006 18:11:05 +0200 Lars Luthman wrote: > > You should maybe add that this will only work when jack is already > > started or JACK_START_SERVER is set in the environment. > > Hm, true. I never even considered that option. Is anyone still starting > jackd manually? Yah, me :) That's how i stumbled across it. I actually think that the majority of the users probably still start jackd (and lashd) manually. > > I haven't tried > > the 0.2 release, but the dev version i still run doesn't produce an > > error dialog if lashd failed to start. Maybe it should? > > Maybe. Hehe, your call of course :) Flo -- Palimm Palimm! http://tapas.affenbande.org From julien at c-lab.de Tue Jun 13 13:21:06 2006 From: julien at c-lab.de (Julien Claassen) Date: Tue Jun 13 13:21:22 2006 Subject: [linux-audio-dev] experience with doggiebox Message-ID: Hi all! Sorry for crossposting, but I wasn't sure, who could answer it more apropriately. Does anyone of you ever have had experience with doggiebox http://www.doggiebox.com Is the format of their drumkits known? It seems to me this software is kind of free. And they seem to have a few nice and free kits. Thus I thought perhaps one could convert them to hydrogen or soundfont. It looked straight forward enough. Any ideas, hints, whatever? Kindest regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net - the Linux TextBased Studio guide From notmyprivateemail at gmail.com Wed Jun 14 01:47:36 2006 From: notmyprivateemail at gmail.com (Alex Polite) Date: Wed Jun 14 01:47:40 2006 Subject: [linux-audio-dev] Writing LADSPA plugins in high level language? Message-ID: Hi there. Is it possible to write LADSPA plugins in anything but C/C++? I prefer perl, ruby or python. alex -- Alex Polite http://flosspick.org - finding the right open source From _ at whats-your.name Wed Jun 14 02:00:55 2006 From: _ at whats-your.name (carmen) Date: Wed Jun 14 02:00:59 2006 Subject: [linux-audio-dev] Writing LADSPA plugins in high level language? In-Reply-To: References: Message-ID: <20060614060055.GA12206@replic.net> On Wed Jun 14, 2006 at 07:47:36AM +0200, Alex Polite wrote: > Hi there. > > Is it possible to write LADSPA plugins in anything but C/C++? I prefer > perl, ruby or python when it gets down to doing something as simple as mangle a few samples or implement a filter, C is almost as concise as python/ruby/perl, and multiples faster. there are projects for both python and ruby that will compile to C code, however, if youre afraid to make the jump.. i'm guessing the code they generate is about as pleasing as something out of Microsoft FrontPage is to a seasoned CSS expert, though.. > > alex > > -- > Alex Polite > http://flosspick.org - finding the right open source > From loki.davison at gmail.com Wed Jun 14 02:07:36 2006 From: loki.davison at gmail.com (Loki Davison) Date: Wed Jun 14 02:07:40 2006 Subject: [linux-audio-dev] Re: Writing LADSPA plugins in high level language? In-Reply-To: References: Message-ID: On 6/14/06, Alex Polite wrote: > Hi there. > > Is it possible to write LADSPA plugins in anything but C/C++? I prefer > perl, ruby or python. > > alex > > -- > Alex Polite > http://flosspick.org - finding the right open source > quick, easy answer, no. Longer answer, no, but why anyway? Even longer answer, if you are using LV2 you can probably use a higher level dsp library. There seems to be a very limited collection of dsp libs for any of the languages you mentioned. I suspect the many wonderful benifits of using a language like python wouldn't apply to dsp stuff very well. It's all maths stuff anyway so the language doesn't much much difference unless it provides some highly tuned rt safe premitives to do dsp operations, i.e like some of the dsp libs. You could also write a RT nyquist interpreter as a dssi and then do your plugins as nyquist code. ;) From rlrevell at joe-job.com Wed Jun 14 02:09:33 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Jun 14 02:10:17 2006 Subject: [linux-audio-dev] Writing LADSPA plugins in high level language? In-Reply-To: References: Message-ID: <1150265374.19205.172.camel@mindpipe> On Wed, 2006-06-14 at 07:47 +0200, Alex Polite wrote: > Hi there. > > Is it possible to write LADSPA plugins in anything but C/C++? I prefer > perl, ruby or python. How do you do realtime in an interpreted language? How can you guarantee the interpreter won't do something that's not RT safe during a critical section? Lee From loki.davison at gmail.com Wed Jun 14 03:10:13 2006 From: loki.davison at gmail.com (Loki Davison) Date: Wed Jun 14 03:10:17 2006 Subject: [linux-audio-dev] Re: Writing LADSPA plugins in high level language? In-Reply-To: <1150265374.19205.172.camel@mindpipe> References: <1150265374.19205.172.camel@mindpipe> Message-ID: On 6/14/06, Lee Revell wrote: > On Wed, 2006-06-14 at 07:47 +0200, Alex Polite wrote: > > Hi there. > > > > Is it possible to write LADSPA plugins in anything but C/C++? I prefer > > perl, ruby or python. > > How do you do realtime in an interpreted language? How can you > guarantee the interpreter won't do something that's not RT safe during a > critical section? > > Lee Thus my simple answer, no ;) From pfh at acoustics.aau.dk Wed Jun 14 03:35:46 2006 From: pfh at acoustics.aau.dk (Pablo Faundez Hoffmann) Date: Wed Jun 14 03:37:13 2006 Subject: [linux-audio-dev] Re: Writing LADSPA plugins in high level language? In-Reply-To: References: Message-ID: On Jun 14, 2006, at 8:07 AM, Loki Davison wrote: > On 6/14/06, Alex Polite wrote: >> Hi there. >> >> Is it possible to write LADSPA plugins in anything but C/C++? I >> prefer >> perl, ruby or python. >> >> alex >> >> -- >> Alex Polite >> http://flosspick.org - finding the right open source >> > > quick, easy answer, no. Longer answer, no, but why anyway? Even longer > answer, if you are using LV2 you can probably use a higher level dsp > library. There seems to be a very limited collection of dsp libs for > any of the languages you mentioned. I suspect the many wonderful > benifits of using a language like python wouldn't apply to dsp stuff > very well. It's all maths stuff anyway so the language doesn't much > much difference unless it provides some highly tuned rt safe > premitives to do dsp operations, i.e like some of the dsp libs. could you name some of the dsp libs that provide rt safe premitives to do dsp operations?. Pablo > You > could also write a RT nyquist interpreter as a dssi and then do your > plugins as nyquist code. ;) From indigo at bitglue.com Wed Jun 14 09:25:22 2006 From: indigo at bitglue.com (Phil Frost) Date: Wed Jun 14 09:25:32 2006 Subject: [linux-audio-dev] Writing LADSPA plugins in high level language? In-Reply-To: References: Message-ID: <20060614132522.GA3483@unununium.org> On Wed, Jun 14, 2006 at 07:47:36AM +0200, Alex Polite wrote: > Hi there. > > Is it possible to write LADSPA plugins in anything but C/C++? I prefer > perl, ruby or python. > > alex Anything but C/C++, yes. See FAUST [1], a compiled language designed specificly for processing audio streams. Perl, Ruby, or Python, not really. [1] From radarsat1 at gmail.com Wed Jun 14 09:59:48 2006 From: radarsat1 at gmail.com (Steve) Date: Wed Jun 14 09:59:56 2006 Subject: [linux-audio-dev] Writing LADSPA plugins in high level language? In-Reply-To: <20060614132522.GA3483@unununium.org> References: <20060614132522.GA3483@unununium.org> Message-ID: <9b3e2dc20606140659q74c3f120jc98799b3e0dc4942@mail.gmail.com> I think this is a worthwhile topic actually... There is currently a shortage of interest in developing good alternative NATIVE machine-language-compiled languages. Although I have been programming C/C++ for a long time, I have lately been getting into Python and I really like it... Really, there's no REAL reason we can't use other languages for writing audio stuff, except that most newer languages tend to be designed for either interpreters or bytecode machines. The reason is straight-forward: Interpreters and virtual machines are way easier to debug and can take care of a lot of the nitty gritty work (like garbage collection), which is perfectly fine for things like application-writing, which tend to be I/O-bound processes. However, for certain tasks, like audio, it's still necessary to get the optimization and lean code that can only be generated by a good C compiler. While C is a great language, other languages frankly do provide nicer ways of expressing logic. Especially for things like audio, languages that offer vector operations might be much better suited. (For example, in the academic world, lots of audio research is done in Matlab for crying out loud... which I don't think is necessary the best language, but is well-known and good for what they are using it for. Now imagine being able to directly compile that into a VST or LADSPA or DSSI instead of having to manually translate it to C..!) Additionally with the availability of hardware that is optimized for vector processing (GPUs, the Cell processor, etc..), languages that can properly (and automatically) take advantage of it would be welcome. So why is the rest of the programming world able to move on to new languages while audio and realtime people are still stuck in the 80's with C? It doesn't seem fair, and the only reason is that the world has lost interest in native compilation so there is currently little effort being put into developing new languages that can be used for realtime processes. There are, of course, languages like SuperCollider and CSound, which ARE made for expressing audio algorithms. However, again they are generally interpreted. You can run them, but they can't really be considered equivalent to C, able to be compiled to code linked into a program or plugin. (Though perhaps there exists ways of generating plugins from CSound code, I wouldn't be surprised.) One thing I just learned about recently is Pyrex. It doesn't generate stand-alone programs but is meant for creating libraries that can be called from Python -- it generates C code from a Python-like language, which is structured to be called from Python. This makes sense to me... why worry about supported the millions of CPU architectures out there when this is already taken care of by GCC. So instead of generating ML, generate "portable ML" (i.e., C code), and let GCC take care of the platform-specific work. I think this is a great idea, except that I'd like to just write a whole program or plugin in it instead of making something that is meant to co-exist with Python "glue code". I'm definitely going to check out Faust too, as I hadn't heard of it before. Steve On 6/14/06, Phil Frost wrote: > On Wed, Jun 14, 2006 at 07:47:36AM +0200, Alex Polite wrote: > > Hi there. > > > > Is it possible to write LADSPA plugins in anything but C/C++? I prefer > > perl, ruby or python. > > > > alex > > Anything but C/C++, yes. See FAUST [1], a compiled language designed > specificly for processing audio streams. Perl, Ruby, or Python, not > really. > > [1] > From lars.luthman at gmail.com Wed Jun 14 10:11:30 2006 From: lars.luthman at gmail.com (Lars Luthman) Date: Wed Jun 14 10:11:34 2006 Subject: [linux-audio-dev] Writing LADSPA plugins in high level language? In-Reply-To: <9b3e2dc20606140659q74c3f120jc98799b3e0dc4942@mail.gmail.com> References: <20060614132522.GA3483@unununium.org> <9b3e2dc20606140659q74c3f120jc98799b3e0dc4942@mail.gmail.com> Message-ID: <1150294290.8894.2.camel@localhost> On Wed, 2006-06-14 at 09:59 -0400, Steve wrote: > So why is the rest of the programming world able to move on to new > languages while audio and realtime people are still stuck in the 80's > with C? We're not stuck in the 80's with C, we're stuck in the 90's with C++. C is only used for its nostalgic value to old programmers. =) -- Lars Luthman - please encrypt any email sent to me if possible PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E 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: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060614/beb50bf9/attachment.bin From sk at k-hornz.de Wed Jun 14 10:20:42 2006 From: sk at k-hornz.de (stefan kersten) Date: Wed Jun 14 10:21:02 2006 Subject: [linux-audio-dev] Writing LADSPA plugins in high level language? In-Reply-To: <1150265374.19205.172.camel@mindpipe> References: <1150265374.19205.172.camel@mindpipe> Message-ID: <20060614142042.GA4192@localdomain> On Wed, Jun 14, 2006 at 02:09:33AM -0400, Lee Revell wrote: > How do you do realtime in an interpreted language? How > can you guarantee the interpreter won't do something > that's not RT safe during a critical section? by properly designing the interpreter? From pw_lists at slinkp.com Wed Jun 14 10:48:54 2006 From: pw_lists at slinkp.com (Paul Winkler) Date: Wed Jun 14 10:49:27 2006 Subject: [linux-audio-dev] Writing LADSPA plugins in high level language? In-Reply-To: <9b3e2dc20606140659q74c3f120jc98799b3e0dc4942@mail.gmail.com> References: <20060614132522.GA3483@unununium.org> <9b3e2dc20606140659q74c3f120jc98799b3e0dc4942@mail.gmail.com> Message-ID: <20060614144854.GA9245@slinkp.com> On Wed, Jun 14, 2006 at 09:59:48AM -0400, Steve wrote: > There are, of course, languages like SuperCollider and CSound, which > ARE made for expressing audio algorithms. However, again they are > generally interpreted. You can run them, but they can't really be > considered equivalent to C, able to be compiled to code linked into a > program or plugin. (Though perhaps there exists ways of generating > plugins from CSound code, I wouldn't be surprised.) There's also the compile-to-C approach, e.g. sfront which takes SAOL code (sort of like csound with cleaner / more modern syntax) and generates C. I hacked up an attempt at generating Jack apps with sfront, which I never finished or released. SAOL interest seems to be pretty dead anyway. > One thing I just learned about recently is Pyrex. It doesn't generate > stand-alone programs but is meant for creating libraries that can be > called from Python -- it generates C code from a Python-like language, > which is structured to be called from Python. This makes sense to > me... why worry about supported the millions of CPU architectures out > there when this is already taken care of by GCC. So instead of > generating ML, generate "portable ML" (i.e., C code), and let GCC take > care of the platform-specific work. I think this is a great idea, > except that I'd like to just write a whole program or plugin in it > instead of making something that is meant to co-exist with Python > "glue code". Pyrex is good for making faster python libraries, which is a great thing, but it won't help with the problem that you really don't want to be running a python interpreter inside a realtime dsp system. -- Paul Winkler http://www.slinkp.com From radarsat1 at gmail.com Wed Jun 14 11:36:35 2006 From: radarsat1 at gmail.com (Steve) Date: Wed Jun 14 11:36:39 2006 Subject: [linux-audio-dev] Writing LADSPA plugins in high level language? In-Reply-To: <20060614144854.GA9245@slinkp.com> References: <20060614132522.GA3483@unununium.org> <9b3e2dc20606140659q74c3f120jc98799b3e0dc4942@mail.gmail.com> <20060614144854.GA9245@slinkp.com> Message-ID: <9b3e2dc20606140836r6baedd39q81397b244ed8c459@mail.gmail.com> > Pyrex is good for making faster python libraries, which is a great > thing, but it won't help with the problem that you really > don't want to be running a python interpreter inside a realtime > dsp system. Yes, that's sort of what I meant... I.e., languages like Pyrex allow to compile portions of python to native machine code, but it would be nice to have a language like that intended specifically for writing stand-alone native applications that aren't interpreted and could be stuck into DSP systems and realtime threads. For instance, at run-time, we don't necessarily need all the debugging features like backtracing and exception handling. (Okay exception handling isn't exactly a debugging feature but you know what I mean.) But that doesn't mean that a nice expressive language other than C can't be used to generate lean code. It just, afaik, hasn't been done. I only meant to suggest that Pyrex is sort of a step in the right direction... Steve From notmyprivateemail at gmail.com Wed Jun 14 11:40:12 2006 From: notmyprivateemail at gmail.com (Alex Polite) Date: Wed Jun 14 11:40:16 2006 Subject: [linux-audio-dev] Writing LADSPA plugins in high level language? In-Reply-To: <20060614132522.GA3483@unununium.org> References: <20060614132522.GA3483@unununium.org> Message-ID: On 6/14/06, Phil Frost wrote: > Anything but C/C++, yes. See FAUST [1], a compiled language designed > specificly for processing audio streams. Thanks a lot. Seems simple enough. Nice tutorial and all. alex -- Alex Polite http://flosspick.org - finding the right open source From S.W.Harris at ecs.soton.ac.uk Wed Jun 14 13:04:12 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed Jun 14 13:04:37 2006 Subject: [linux-audio-dev] Writing LADSPA plugins in high level language? In-Reply-To: <20060614142042.GA4192@localdomain> References: <1150265374.19205.172.camel@mindpipe> <20060614142042.GA4192@localdomain> Message-ID: <20060614170412.GB13633@login.ecs.soton.ac.uk> On Wed, Jun 14, 2006 at 04:20:42PM +0200, stefan kersten wrote: > On Wed, Jun 14, 2006 at 02:09:33AM -0400, Lee Revell wrote: > > How do you do realtime in an interpreted language? How > > can you guarantee the interpreter won't do something > > that's not RT safe during a critical section? > > by properly designing the interpreter? You sped a lot of your time when your writing plugins shaving a few cycles of work here and there to make things more efficient, introducing an intepreter into the mix just makes that a lot harder. When people think they want a VM or interpreter they often want garbage collection, generally garbage collection is not relatime safe. There are relatime garbage collectors, but they're not common and they're extremly complicated. Given that (Objective) C(++) has the best math libraries, debugging tools and is very efficient I dont see any reason for using any other general purpose language. Faust is another matter however. FWIW, you can compile Matlab into C, but actually Matlab/Octave is not that appropriate for writing plugins as it's designed and optimised for complete matricies, not rolling buffers. - Steve From lazzaro at eecs.berkeley.edu Wed Jun 14 13:26:15 2006 From: lazzaro at eecs.berkeley.edu (lazzaro) Date: Wed Jun 14 13:26:21 2006 Subject: [linux-audio-dev] Writing LADSPA plugins in high level language? In-Reply-To: <20060614170439.4419E1CB7011@music.columbia.edu> References: <20060614170439.4419E1CB7011@music.columbia.edu> Message-ID: <5B7ED96C-9D0B-4A11-9928-34B71A17957D@eecs.berkeley.edu> On Jun 14, 2006, at 10:04 AM, linux-audio-dev- request@music.columbia.edu wrote: > There are, of course, languages like SuperCollider and CSound, which > ARE made for expressing audio algorithms. However, again they are > generally interpreted. Sfront compiles a high-level music language (Structured Audio) to C, and there's no reason in theory that audio drivers couldn't be written for LADSPA. At the moment, though, all of the audio drivers are for interface APIs, not plug-in APIs ... the first plug-in API for sfront is most likely to be for AudioUnits, since I've moved from Linux to OS X as my computing platform these days. But anyone can write an audio driver for sfront, see: http://www.cs.berkeley.edu/~lazzaro/sa/sfman/devel/adriver/index.html for info on writing new audio drivers for sfront, and: http://www.cs.berkeley.edu/~lazzaro/sa/ For more general info on Structured Audio and sfront. --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- From indigo at bitglue.com Wed Jun 14 16:20:08 2006 From: indigo at bitglue.com (Phil Frost) Date: Wed Jun 14 16:20:18 2006 Subject: [linux-audio-dev] Writing LADSPA plugins in high level language? In-Reply-To: <20060614144854.GA9245@slinkp.com> References: <20060614132522.GA3483@unununium.org> <9b3e2dc20606140659q74c3f120jc98799b3e0dc4942@mail.gmail.com> <20060614144854.GA9245@slinkp.com> Message-ID: <20060614202008.GA20709@unununium.org> On Wed, Jun 14, 2006 at 10:48:54AM -0400, Paul Winkler wrote: > On Wed, Jun 14, 2006 at 09:59:48AM -0400, Steve wrote: > > One thing I just learned about recently is Pyrex. It doesn't generate > > stand-alone programs but is meant for creating libraries that can be > > called from Python -- it generates C code from a Python-like language, > > which is structured to be called from Python. This makes sense to > > me... why worry about supported the millions of CPU architectures out > > there when this is already taken care of by GCC. So instead of > > generating ML, generate "portable ML" (i.e., C code), and let GCC take > > care of the platform-specific work. I think this is a great idea, > > except that I'd like to just write a whole program or plugin in it > > instead of making something that is meant to co-exist with Python > > "glue code". > > Pyrex is good for making faster python libraries, which is a great > thing, but it won't help with the problem that you really > don't want to be running a python interpreter inside a realtime > dsp system. That's not entirely true. I once wrote an OS where the filesystem and ATA drivers were written in Python, which was accomplished by linking the kernel with libpython (no joke). Lower levels, like the memory manager, were written in Pyrex. In the end it was pretty slow and useless, but it did run, and at one point I managed to get on IRC with it :) Pyrex is pretty much Python + C, only the C syntax is changed to look more like Python. If you use only C types, then the code output by Pyrex will not depend on Python (except some of the module metadata it generates, but the generated functions can be executed without it). The problem though is that it's just C with a different syntax. Re. lack of interest in developing new compiled languages, see Wirth's law: . The good news is that in a few years, computers will be so damn fast that using Python to write audio plugins won't be so bad. Of course when that happens, we will have some fancy new language which is even slower, and manages to consume enough resources that it will seem as if computers are not in fact getting faster. You might as well just expect using a 20-year old language for all your audio work forever. From Dr.Graef at t-online.de Wed Jun 14 16:47:42 2006 From: Dr.Graef at t-online.de (Albert Graef) Date: Wed Jun 14 16:40:31 2006 Subject: [linux-audio-dev] Writing LADSPA plugins in high level language? In-Reply-To: <20060614170412.GB13633@login.ecs.soton.ac.uk> References: <1150265374.19205.172.camel@mindpipe> <20060614142042.GA4192@localdomain> <20060614170412.GB13633@login.ecs.soton.ac.uk> Message-ID: <449075EE.9030200@t-online.de> Steve Harris wrote: > When people think they want a VM or interpreter they often want garbage > collection, generally garbage collection is not relatime safe. There > are relatime garbage collectors, but they're not common and they're > extremly complicated. That's not necessarily true. If you can live without collecting cyclic structures then a simple reference counting scheme will do, which is very cheap and simple to implement. And SuperCollider shows that the more general case is tractable, too, at least in languages designed specifically for that purpose. But I agree, there is no point in using interpreted languages to program DSP algorithms which operate on the sample level. If properly designed, they are o.k. for providing the glue between ready-made units which operate on the block level (like SC does, and CSound, and ...), but not for sample-level stuff. That's what compiled languages like Faust are for. Even when computers get a lot faster than they are now, we don't have any cpu cycles to waste on number crunching. > Given that (Objective) C(++) has the best math libraries I think that the scientific computing community will object to that. "Real programmers use Fortran." ;-) > Faust is another matter however. Yes, because it will do optimizations on the expression level that your C compiler can't do, and that you might not bother to do manually. Albert -- 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.musikinformatik.uni-mainz.de/ag From kjetil at ccrma.stanford.edu Wed Jun 14 17:23:16 2006 From: kjetil at ccrma.stanford.edu (Kjetil S. Matheussen) Date: Wed Jun 14 17:23:20 2006 Subject: [linux-audio-dev] Re: Writing LADSPA plugins in high level language? In-Reply-To: <20060614170439.4419E1CB7011@music.columbia.edu> References: <20060614170439.4419E1CB7011@music.columbia.edu> Message-ID: Phil Frost: > Subject: Re: [linux-audio-dev] Writing LADSPA plugins in high level > language? > To: The Linux Audio Developers' Mailing List > > Message-ID: <20060614132522.GA3483@unununium.org> > Content-Type: text/plain; charset=us-ascii > > On Wed, Jun 14, 2006 at 07:47:36AM +0200, Alex Polite wrote: >> Hi there. >> >> Is it possible to write LADSPA plugins in anything but C/C++? I prefer >> perl, ruby or python. >> >> alex > > Anything but C/C++, yes. See FAUST [1], a compiled language designed > specificly for processing audio streams. Perl, Ruby, or Python, not > really. > > [1] The realtime extension for snd (scheme-like language) is another: http://www.notam02.no/arkiv/doc/snd-rt/ Here is a cool alsa softsynth written in that system: http://ccrma.stanford.edu/~kjetil/220c/ From kjetil at ccrma.stanford.edu Wed Jun 14 17:26:18 2006 From: kjetil at ccrma.stanford.edu (Kjetil S. Matheussen) Date: Wed Jun 14 17:26:22 2006 Subject: [linux-audio-dev] Re: Writing LADSPA plugins in high level language? In-Reply-To: <20060614170439.4419E1CB7011@music.columbia.edu> References: <20060614170439.4419E1CB7011@music.columbia.edu> Message-ID: Steve: > > I think this is a worthwhile topic actually... > There is currently a shortage of interest in developing good > alternative NATIVE machine-language-compiled languages. > Although I have been programming C/C++ for a long time, I have lately > been getting into Python and I really like it... Really, there's no > REAL reason we can't use other languages for writing audio stuff, I completely agree with you. And thats why I use SND for almost anything: http://ccrma.stanford.edu/software/snd/ From fbar at footils.org Wed Jun 14 18:06:01 2006 From: fbar at footils.org (Frank Barknecht) Date: Wed Jun 14 18:06:06 2006 Subject: [linux-audio-dev] Writing LADSPA plugins in high level language? In-Reply-To: <449075EE.9030200@t-online.de> References: <1150265374.19205.172.camel@mindpipe> <20060614142042.GA4192@localdomain> <20060614170412.GB13633@login.ecs.soton.ac.uk> <449075EE.9030200@t-online.de> Message-ID: <20060614220601.GA6303@fliwatut.scifi> Hallo, Albert Graef hat gesagt: // Albert Graef wrote: > But I agree, there is no point in using interpreted languages to program > DSP algorithms which operate on the sample level. If properly designed, > they are o.k. for providing the glue between ready-made units which > operate on the block level (like SC does, and CSound, and ...), but not > for sample-level stuff. And that's pretty much the standard invented by, I think, Max Matthews: the concept of a "ugen", a building block which itself operates on sample level, but which is designed in a way, that it can be combined to actually useful (musically) higher level constructs, that operate on bigger structures (blocks of samples most of the time). Every decent sound software nowadays, like SC, Pd, Csound of course, and plugins systems like LADSPA, VST etc. works by basically following that model. They do so not only because it's efficient (it sometimes isn't), but because it is easier to *think* in ugens, than to think in samples (especially once you do stuff like frequency domain processing, which is hard to *think* in on a sample level). Ciao -- Frank Barknecht _ ______footils.org_ __goto10.org__ From linux at blennerhassett.gen.nz Wed Jun 14 19:42:12 2006 From: linux at blennerhassett.gen.nz (Eliot Blennerhassett) Date: Wed Jun 14 19:42:27 2006 Subject: [linux-audio-dev] [ANN] Audioscience Driver version 300 released Message-ID: <200606151142.13927.linux@blennerhassett.gen.nz> Greetings, Version 300 of Audioscience HPI driver has been released and can be downloaded from here: http://www.audioscience.com/internet/download/linux_drivers.htm There are many changes, please read the release notes for details: http://www.audioscience.com/internet/download/drvnotes.txt In addition ALSA has been updated to use the same source code and DSP files. ?Currently only available in the ALSA Mercurial repository: http://alsa-project.org/download.php If you have any problems or queries about this new driver, please email support@ (our domain name), include info about your distro, kernel version, card type etc. regards -- Eliot Blennerhassett AudioScience Inc From Dr.Graef at t-online.de Wed Jun 14 20:37:15 2006 From: Dr.Graef at t-online.de (Albert Graef) Date: Wed Jun 14 20:30:03 2006 Subject: [linux-audio-dev] Writing LADSPA plugins in high level language? In-Reply-To: <20060614220601.GA6303@fliwatut.scifi> References: <1150265374.19205.172.camel@mindpipe> <20060614142042.GA4192@localdomain> <20060614170412.GB13633@login.ecs.soton.ac.uk> <449075EE.9030200@t-online.de> <20060614220601.GA6303@fliwatut.scifi> Message-ID: <4490ABBB.3010008@t-online.de> Frank Barknecht wrote: > Every decent sound software nowadays, like SC, Pd, Csound of course, > and plugins systems like LADSPA, VST etc. works by basically following > that model. They do so not only because it's efficient (it sometimes > isn't), but because it is easier to *think* in ugens, than to think in > samples (especially once you do stuff like frequency domain > processing, which is hard to *think* in on a sample level). Sure, but unfortunately all those nice little ugens don't grow on the trees, they must be programmed, too, and then you _are_ working on the sample level. ;-) This is where most of the heavy-duty number crunching takes place, and there you want a compiled language. That's what languages like Faust are for, to provide an alternative to C and assembler for the low-level stuff. (Not sure about snd, does it compile to native code which can execute in realtime?) Albert -- 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.musikinformatik.uni-mainz.de/ag From cournape at gmail.com Thu Jun 15 03:32:07 2006 From: cournape at gmail.com (David Cournapeau) Date: Thu Jun 15 03:32:11 2006 Subject: [linux-audio-dev] Re: Writing LADSPA plugins in high level language? In-Reply-To: References: <20060614170439.4419E1CB7011@music.columbia.edu> Message-ID: <5b8d13220606150032i4e3efa3fgfa2f1be9fc9dbfd6@mail.gmail.com> On 6/15/06, Kjetil S. Matheussen wrote: > > Phil Frost: > > Subject: Re: [linux-audio-dev] Writing LADSPA plugins in high level > > language? > > To: The Linux Audio Developers' Mailing List > > > > Message-ID: <20060614132522.GA3483@unununium.org> > > Content-Type: text/plain; charset=us-ascii > > > > On Wed, Jun 14, 2006 at 07:47:36AM +0200, Alex Polite wrote: > >> Hi there. > >> > >> Is it possible to write LADSPA plugins in anything but C/C++? I prefer > >> perl, ruby or python. > >> > >> alex > > > > Anything but C/C++, yes. See FAUST [1], a compiled language designed > > specificly for processing audio streams. Perl, Ruby, or Python, not > > really. > > > > [1] > > > The realtime extension for snd (scheme-like language) is another: > http://www.notam02.no/arkiv/doc/snd-rt/ > > Here is a cool alsa softsynth written in that system: > http://ccrma.stanford.edu/~kjetil/220c/ there is also chuck, that nobody has mentionned, I think : http://soundlab.cs.princeton.edu/research/chuck/ I am in no way as experienced as most people on this list for audio programming, but I don't see why C/C++ should be the only way to write software to handle audio stream, neither do I see why GC would be the only useful feature. For example, having language constructs to explicitely handle "time line" sounds like a good idea to me, and it looks like both Faust and chuck enable that. David From dominique.michel at citycable.ch Thu Jun 15 06:02:34 2006 From: dominique.michel at citycable.ch (Dominique Michel) Date: Thu Jun 15 06:02:56 2006 Subject: [linux-audio-dev] Writing LADSPA plugins in high level language? In-Reply-To: <20060614202008.GA20709@unununium.org> References: <20060614132522.GA3483@unununium.org> <9b3e2dc20606140659q74c3f120jc98799b3e0dc4942@mail.gmail.com> <20060614144854.GA9245@slinkp.com> <20060614202008.GA20709@unununium.org> Message-ID: <20060615120234.10135ba4@localhost> Le Wed, 14 Jun 2006 16:20:08 -0400, Phil Frost a ?crit : > On Wed, Jun 14, 2006 at 10:48:54AM -0400, Paul Winkler wrote: > > On Wed, Jun 14, 2006 at 09:59:48AM -0400, Steve wrote: > > > One thing I just learned about recently is Pyrex. It doesn't generate > > > stand-alone programs but is meant for creating libraries that can be > > > called from Python -- it generates C code from a Python-like language, > > > which is structured to be called from Python. This makes sense to > > > me... why worry about supported the millions of CPU architectures out > > > there when this is already taken care of by GCC. So instead of > > > generating ML, generate "portable ML" (i.e., C code), and let GCC take > > > care of the platform-specific work. I think this is a great idea, > > > except that I'd like to just write a whole program or plugin in it > > > instead of making something that is meant to co-exist with Python > > > "glue code". > > > > Pyrex is good for making faster python libraries, which is a great > > thing, but it won't help with the problem that you really > > don't want to be running a python interpreter inside a realtime > > dsp system. > > That's not entirely true. I once wrote an OS where the filesystem and > ATA drivers were written in Python, which was accomplished by linking > the kernel with libpython (no joke). Lower levels, like the memory > manager, were written in Pyrex. In the end it was pretty slow and > useless, but it did run, and at one point I managed to get on IRC with > it :) > > Pyrex is pretty much Python + C, only the C syntax is changed to look > more like Python. If you use only C types, then the code output by Pyrex > will not depend on Python (except some of the module metadata it > generates, but the generated functions can be executed without it). The > problem though is that it's just C with a different syntax. > > Re. lack of interest in developing new compiled languages, see Wirth's > law: . The good news is that > in a few years, computers will be so damn fast that using Python to > write audio plugins won't be so bad. Of course when that happens, we > will have some fancy new language which is even slower, and manages to > consume enough resources that it will seem as if computers are not in > fact getting faster. You might as well just expect using a 20-year old > language for all your audio work forever. It is another problem here. Everybody know about peak oil, but we are managing all our ressources the same way, like a business that don't want t they consumers to pay. We are thinking at we have enough cash (or oil, or anything else) in the bank for ever. Fast processors (as solar panels) use indium, and for what I know, it will be no indium left in the wild in about 10 or 15 years. So the right question here is: who will have enough cash to buy those fast computers in 10 or 15 years? From paul at linuxaudiosystems.com Thu Jun 15 08:53:11 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Thu Jun 15 08:52:52 2006 Subject: [linux-audio-dev] Re: Writing LADSPA plugins in high level language? In-Reply-To: <5b8d13220606150032i4e3efa3fgfa2f1be9fc9dbfd6@mail.gmail.com> References: <20060614170439.4419E1CB7011@music.columbia.edu> <5b8d13220606150032i4e3efa3fgfa2f1be9fc9dbfd6@mail.gmail.com> Message-ID: <1150375991.1765.115.camel@localhost.localdomain> On Thu, 2006-06-15 at 16:32 +0900, David Cournapeau wrote: > I am in no way as experienced as most people on this list for audio > programming, but I don't see why C/C++ should be the only way to write > software to handle audio stream, neither do I see why GC would be the > only useful feature. For example, having language constructs to > explicitely handle "time line" sounds like a good idea to me, and it > looks like both Faust and chuck enable that. there is no universal agreement on how such features should work. if you provide a "language" in which this is possible, you're really providing an application (such as supercollider). a some builtin language idea about what a playlist looks like ? there are many variants on the idea of a playlist, and i don't think you can usefully provide abstract building blocks (which is what a language is for) and support all the variations without compromising at least one of those goals. faust, btw, has no concept of a timeline in the sense that chuck does. From pw_lists at slinkp.com Thu Jun 15 09:18:13 2006 From: pw_lists at slinkp.com (Paul Winkler) Date: Thu Jun 15 09:18:33 2006 Subject: [linux-audio-dev] Writing LADSPA plugins in high level language? In-Reply-To: <20060615120234.10135ba4@localhost> References: <20060614132522.GA3483@unununium.org> <9b3e2dc20606140659q74c3f120jc98799b3e0dc4942@mail.gmail.com> <20060614144854.GA9245@slinkp.com> <20060614202008.GA20709@unununium.org> <20060615120234.10135ba4@localhost> Message-ID: <20060615131813.GB9237@slinkp.com> On Thu, Jun 15, 2006 at 12:02:34PM +0200, Dominique Michel wrote: > > On Wed, Jun 14, 2006 at 10:48:54AM -0400, Paul Winkler wrote: > > > Pyrex is good for making faster python libraries, which is a great > > > thing, but it won't help with the problem that you really > > > don't want to be running a python interpreter inside a realtime > > > dsp system. > > > > That's not entirely true. I once wrote an OS where the filesystem and > > ATA drivers were written in Python, which was accomplished by linking > > the kernel with libpython (no joke). Lower levels, like the memory > > manager, were written in Pyrex. In the end it was pretty slow and > > useless, but it did run, and at one point I managed to get on IRC with > > it :) I didn't say it wouldn't *work*. You're the one who said "pretty slow and worthless" :) -PW -- Paul Winkler http://www.slinkp.com From pw_lists at slinkp.com Thu Jun 15 09:19:35 2006 From: pw_lists at slinkp.com (Paul Winkler) Date: Thu Jun 15 09:19:44 2006 Subject: [linux-audio-dev] Writing LADSPA plugins in high level language? In-Reply-To: <5B7ED96C-9D0B-4A11-9928-34B71A17957D@eecs.berkeley.edu> References: <20060614170439.4419E1CB7011@music.columbia.edu> <5B7ED96C-9D0B-4A11-9928-34B71A17957D@eecs.berkeley.edu> Message-ID: <20060615131935.GC9237@slinkp.com> On Wed, Jun 14, 2006 at 10:26:15AM -0700, lazzaro wrote: > >There are, of course, languages like SuperCollider and CSound, which > >ARE made for expressing audio algorithms. However, again they are > >generally interpreted. > > > Sfront compiles a high-level music language (Structured Audio) to C, > and there's no reason in theory that audio drivers couldn't be written > for LADSPA. I remember asking you about this a couple years ago and you said it could be done, but you could only run one plugin instance at a time... .is that still the case? or am I misremembering? And, is all the sfront / saol action happening somewhere that I'm not aware of? I was always disappointed that there didn't seem to be a lively community around saol. -- Paul Winkler http://www.slinkp.com From S.W.Harris at ecs.soton.ac.uk Thu Jun 15 09:26:13 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Thu Jun 15 09:26:56 2006 Subject: [linux-audio-dev] Writing LADSPA plugins in high level language? In-Reply-To: <20060615131935.GC9237@slinkp.com> References: <20060614170439.4419E1CB7011@music.columbia.edu> <5B7ED96C-9D0B-4A11-9928-34B71A17957D@eecs.berkeley.edu> <20060615131935.GC9237@slinkp.com> Message-ID: <20060615132613.GA30555@login.ecs.soton.ac.uk> On Thu, Jun 15, 2006 at 09:19:35 -0400, Paul Winkler wrote: > On Wed, Jun 14, 2006 at 10:26:15AM -0700, lazzaro wrote: > > >There are, of course, languages like SuperCollider and CSound, which > > >ARE made for expressing audio algorithms. However, again they are > > >generally interpreted. > > > > > > Sfront compiles a high-level music language (Structured Audio) to C, > > and there's no reason in theory that audio drivers couldn't be written > > for LADSPA. > > I remember asking you about this a couple years ago and you said > it could be done, but you could only run one plugin instance > at a time... .is that still the case? or am I misremembering? > > And, is all the sfront / saol action happening somewhere > that I'm not aware of? I was always disappointed that there > didn't seem to be a lively community around saol. Yes, me too, I wrote some code in sfront and liked it, I even went as far as figuring out what needed to be done to remove the globals that prevented you from running more that one plugin at once, but never did the coding. - Steve From fons.adriaensen at alcatelaleniaspace.com Thu Jun 15 09:56:23 2006 From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen) Date: Thu Jun 15 09:56:39 2006 Subject: [linux-audio-dev] Re: Writing LADSPA plugins in high level language? In-Reply-To: <1150375991.1765.115.camel@localhost.localdomain> References: <20060614170439.4419E1CB7011@music.columbia.edu> <5b8d13220606150032i4e3efa3fgfa2f1be9fc9dbfd6@mail.gmail.com> <1150375991.1765.115.camel@localhost.localdomain> Message-ID: <20060615135623.GA8326@bth05w.ABSp.alcatel.be> On Thu, Jun 15, 2006 at 08:53:11AM -0400, Paul Davis wrote: > On Thu, 2006-06-15 at 16:32 +0900, David Cournapeau wrote: > > I am in no way as experienced as most people on this list for audio > > programming, but I don't see why C/C++ should be the only way to write > > software to handle audio stream, neither do I see why GC would be the > > only useful feature. For example, having language constructs to > > explicitely handle "time line" sounds like a good idea to me, and it > > looks like both Faust and chuck enable that. > > there is no universal agreement on how such features should work. if you > provide a "language" in which this is possible, you're really providing > an application (such as supercollider). > > a some builtin language idea about what a playlist looks like ? there > are many variants on the idea of a playlist, and i don't think you can > usefully provide abstract building blocks (which is what a language is > for) and support all the variations without compromising at least one of > those goals. > > faust, btw, has no concept of a timeline in the sense that chuck does. The bottom line here is that this sort of thing is dictated by the system, or by interfaces close to it such as JACK. And you better do thing the way the system expects you to, unless you are prepared to accept intermediate layers that add overhead and latency. One could in theory contruct a language that knows the concept of a 'period' of frames, and that allows you to write audio code and be oblivious of the fact that is in fact processed in chunks of N frames, that you have to maintain state between callbacks, etc. But you can only hide these things up to a certain point. When you write some code that maps badly onto the current period size, then either it will be be very inefficient, have horrible latency, or the language will just fail. So the result would be that the language becomes the thing that determines what sort of functionality can be programmed and what can't, and in that sense it has indeed become an 'application' rather than a language: it only allows you to do those things that were envisaged by its designer. There is a similar situation with multithreading. ADA is one of the few languages that supports it natively, and most early ADA compilers had their own implementation. But if you want your ADA tasks to interact in a natural way with the surrounding system, then you have to use the system's concept of what a thread is (i.e. construct the ADA tasks on top of NPTL), and it's near impossible to do this without either exposing somehow the underlying system to the user, or limiting the functionality. -- FA Follie! Follie! Delirio vano e' questo! From most at museresearch.com Thu Jun 15 13:49:59 2006 From: most at museresearch.com (Michael Ost) Date: Thu Jun 15 13:50:25 2006 Subject: [linux-audio-dev] Jack's IPC overhead Message-ID: <1150393799.4542.37.camel@bluefred> We are considering re-architecting our VST host in Receptor to run each plugin in a separate process and connecting the processes with Jack. How much extra overhead can we expect? Receptor is basically a PC running our VST host. That's the only audio app that is running. Currently all the VSTs run in our host app's process, so we have no context switch or system call to get them to process. This helps keep processing overhead low. But the downsides are that (1) all plugins share the same 2GB VM space and (2) we can't make use of a machine with > 2GB RAM. (And (3) one crashing VST can take down our whole mixer, but that's another story...) As it turns out customers are interested in using Receptor to run sample players which are hungry for both VM and RAM. So giving each VST its own process would give the VST its own VM space with lots of elbow room, and allow Linux give all of those plugin apps access to the additional RAM even though they are still 32bit apps. As we looked over the Jack docs, it seems like a natural for supporting this kind of architecture. We would break out our VST support into a separate app and connect them to our Host app via Jack. This seems to be how FST is implemented and how Jack is intended to be used. So does anyone have a sense of how much overhead is introduced by the per-process() IPC that Jack uses? Our worst case would be 57 VST plugins with a 32x2 sample buffer (.725 msecs). How much extra overhead would those 57 Jack calls to process() add to the overall processing time? Any other gotchas? Thanks for any help... mo From paul at linuxaudiosystems.com Thu Jun 15 13:59:52 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Thu Jun 15 14:00:58 2006 Subject: [linux-audio-dev] Jack's IPC overhead In-Reply-To: <1150393799.4542.37.camel@bluefred> References: <1150393799.4542.37.camel@bluefred> Message-ID: <1150394392.22276.18.camel@localhost.localdomain> On Thu, 2006-06-15 at 10:49 -0700, Michael Ost wrote: > As we looked over the Jack docs, it seems like a natural for supporting > this kind of architecture. We would break out our VST support into a > separate app and connect them to our Host app via Jack. This seems to be > how FST is implemented and how Jack is intended to be used. > > So does anyone have a sense of how much overhead is introduced by the > per-process() IPC that Jack uses? Our worst case would be 57 VST plugins > with a 32x2 sample buffer (.725 msecs). How much extra overhead would > those 57 Jack calls to process() add to the overall processing time? Any > other gotchas? sounds like a bad idea (for this number of "entities") in general, but it might work. its not possible to provide actual numbers, because its totally dependent on (a) CPU architecture and (b) CPU speed. there are two costs: (a) actual context switch time, determined by CPU speed and CPU architecture (number of registers to be saved, etc) (b) TLB invalidation overhead caused by the context switch the cost for (b) depends on the working set size of the execution context on each side of the switch. there's no way to answer how much this can be without measurement. however, i would be reasonably sure that at 32 frame/period, the overhead of these context switches is going to cost *a lot* as a percentage of the overall cycles available for processing. i would still advocate on behalf of JACK, however: run the existing FX- centric plugins inside an internal JACK client (i.e. a JACK "plugin") or a single external JACK client, then run the sample players etc as external JACK clients just as FST does. --p From most at museresearch.com Thu Jun 15 14:16:40 2006 From: most at museresearch.com (Michael Ost) Date: Thu Jun 15 14:17:08 2006 Subject: [linux-audio-dev] Jack's IPC overhead In-Reply-To: <1150394392.22276.18.camel@localhost.localdomain> References: <1150393799.4542.37.camel@bluefred> <1150394392.22276.18.camel@localhost.localdomain> Message-ID: <1150395400.4542.56.camel@bluefred> On Thu, 2006-06-15 at 13:59 -0400, Paul Davis wrote: > On Thu, 2006-06-15 at 10:49 -0700, Michael Ost wrote: > > As we looked over the Jack docs, it seems like a natural for supporting > > this kind of architecture. We would break out our VST support into a > > separate app and connect them to our Host app via Jack. This seems to be > > how FST is implemented and how Jack is intended to be used. > > > > So does anyone have a sense of how much overhead is introduced by the > > per-process() IPC that Jack uses? Our worst case would be 57 VST plugins > > with a 32x2 sample buffer (.725 msecs). How much extra overhead would > > those 57 Jack calls to process() add to the overall processing time? Any > > other gotchas? > > sounds like a bad idea (for this number of "entities") in general, but > it might work. > > its not possible to provide actual numbers, because its totally > dependent on (a) CPU architecture and (b) CPU speed. there are two > costs: Since we build the hardware this is well constrained. We are using an Athlon 2500+ in older units and a Turion ML-34 in newer ones. > (a) actual context switch time, determined by CPU speed > and CPU architecture (number of registers to be > saved, etc) > (b) TLB invalidation overhead caused by the context switch > > the cost for (b) depends on the working set size of the execution > context on each side of the switch. there's no way to answer how much > this can be without measurement. This could be large given that we are trying to solve the problem for memory hungry VSTs. > however, i would be reasonably sure that at 32 frame/period, the > overhead of these context switches is going to cost *a lot* as a > percentage of the overall cycles available for processing. > > i would still advocate on behalf of JACK, however: run the existing FX- > centric plugins inside an internal JACK client (i.e. a JACK "plugin") > or a single external JACK client, then run the sample players etc as > external JACK clients just as FST does. Sounds like our best bet would to be flexible and keep some plugins internal and link to others (sample players) externally. That way we can play with the costs vs benefits. Thanks alot for your reply ... mo From lazzaro at eecs.berkeley.edu Thu Jun 15 14:26:25 2006 From: lazzaro at eecs.berkeley.edu (lazzaro) Date: Thu Jun 15 14:26:33 2006 Subject: [linux-audio-dev] Re: Writing LADSPA plugins in high level language? In-Reply-To: <20060615135640.4AD951CE1305@music.columbia.edu> References: <20060615135640.4AD951CE1305@music.columbia.edu> Message-ID: [feel free to redistribute this posting to other mailing lists] On Jun 15, 2006, at 6:56 AM, Paul Winkler wrote: > And, is all the sfront / saol action happening somewhere > that I'm not aware of? I was always disappointed that there > didn't seem to be a lively community around saol. No, the MIT mailing list went inactive a few years ago, and to my knowledge a new one hasn't sprung up to replace it. The only communication channel at the moment is the mailing list to be notified of new sfront releases via freshmeat.net: http://freshmeat.net/projects/sfront/ Which does have 10 subscribers, and I'm not one of them, so there must be 11 sfront users left in the world (at least) :-). I've actually spent the last few months going through my queue of bug reports and feature requests, and updating the code base. But, these are the sorts of changes that benefit from doing them in "batch mode" and then testing thoroughly, so the plan is to hold off on a new release until its time for me to switch back into teaching mode for the fall ... Historically, a few things happened with sfront: [1] The standardization of RTP MIDI via the IETF took priority, and it took longer than I had thought (first running code happened Christmas 2000, and the IESG approved the I-Ds a few months ago: http://www1.ietf.org/mail-archive/web/ietf-announce/current/ msg02110.html We're now in the copy-editing queue (it takes a long time to proof-read 250 pages of dense text ...), once this is done we'll get our RFC numbers. [2] It took a long time to really get a sense of where SAOL could fit in the community ... I think pitching it as a Max/MSP or Pd or SuperCollider or CSound competitor won't succeed ... instead, I think it needs to be relaunched as "audio Postscript" -- an ISO/IEC standard for normatively interchanging audio algorithms in a domain-specific representation. And, as a extra bonus, SAOL is easier for human programmers to read/write than Postscript :-). This is an old idea -- some of you may remember an editorial David Wessel wrote about "audio Postscript" many years ago in Electronic Musician magazine ... Admittedly, SAOL is not perfect for this role -- being standardized almost a decade ago, its inevitable that its dated in some respects, and even during its birth some of its design decisions were controversial. But, I don't think that a core group of academic and industrial folks would be willing to mount (another) 5 year effort to standardize a better audio algorithm interchange language, unless they see real evidence from the community that there's a need for such an effort. And the best way to show that need is to try to insert SAOL into markets for such an interchange format where SAOL's limitations are not of great concern. >> Sfront compiles a high-level music language (Structured Audio) to C, >> and there's no reason in theory that audio drivers couldn't be >> written >> for LADSPA. > > I remember asking you about this a couple years ago and you said > it could be done, but you could only run one plugin instance > at a time... .is that still the case? or am I misremembering? You are remembering correctly ... Basically, one of the "feature requests" in my queue is improving the sfront audio driver API to remove this restriction, and to reality-test it by writing an AudioUnits driver. Until that happens, yes, you'd be limited to single-instantiation for your LADSPA driver ... realistically, I don't think "multiple instances" would make it into the "late summer 2006" release, unless I get lucky and finish earlier items in the queue ahead of schedule. The priority items are fixing real semantic bugs in the language implementation, since sfront is serving as a de-facto secondary reference implementation at this point, as saolc has trouble running a lot of correct SAOL code ... --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- From Dr.Graef at t-online.de Thu Jun 15 15:07:35 2006 From: Dr.Graef at t-online.de (Albert Graef) Date: Thu Jun 15 15:00:17 2006 Subject: [linux-audio-dev] Re: Writing LADSPA plugins in high level language? In-Reply-To: <20060615135623.GA8326@bth05w.ABSp.alcatel.be> References: <20060614170439.4419E1CB7011@music.columbia.edu> <5b8d13220606150032i4e3efa3fgfa2f1be9fc9dbfd6@mail.gmail.com> <1150375991.1765.115.camel@localhost.localdomain> <20060615135623.GA8326@bth05w.ABSp.alcatel.be> Message-ID: <4491AFF7.7060900@t-online.de> > On Thu, Jun 15, 2006 at 08:53:11AM -0400, Paul Davis wrote: >>faust, btw, has no concept of a timeline in the sense that chuck does. No, that's right. As I pointed out elsewhere in this thread, Faust is a language for programming ugens, not for managing sequences and playlists. We're talking about different levels of an audio processing system here. Alfons Adriaensen wrote: > One could in theory contruct a language that knows the concept of a > 'period' of frames, and that allows you to write audio code and be > oblivious of the fact that is in fact processed in chunks of N frames, > that you have to maintain state between callbacks, etc. This is what Faust actually does. At the language level, it provides the illusion of working with infinite streams of audio samples (or, mathematically speaking, real-valued functions of discrete time) so that you don't have to worry about the state which has to be kept between different blocks, the compiler will take care of that for you. > But you can > only hide these things up to a certain point. When you write some > code that maps badly onto the current period size, then either it > will be be very inefficient, have horrible latency, or the language > will just fail. Right. That's why the C code generated by Faust is essentially just the bare-bones block processing callback which takes the actual block size and the audio buffers as parameters. It's up to the different "architectures" to decide how this routine is actually used in a manner which is optimal with regard to a given "host system", be it Jack, LADSAP, VST, SuperCollider or whatever. Of course any domain-specific high-level language has its trade-offs of convenience vs. implementation overhead vs. limits of the domain model. This is hard to get right for low-level DSP programming because efficiency is of utmost importance, but I think that Faust does this pretty well. The only roadblock right now is that it is not suitable for multirate processing yet, but Yann is working on that. Fons, I hope that with your experience as a seasoned DSP programmer you will try Faust some time; I think you might like it, and your feedback will surely be valuable. :) Albert -- 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.musikinformatik.uni-mainz.de/ag From kjetil at ccrma.stanford.edu Thu Jun 15 15:50:45 2006 From: kjetil at ccrma.stanford.edu (Kjetil S. Matheussen) Date: Thu Jun 15 15:50:50 2006 Subject: [linux-audio-dev] Writing LADSPA plugins in high level language In-Reply-To: <20060615003009.2B0911CC87E9@music.columbia.edu> References: <20060615003009.2B0911CC87E9@music.columbia.edu> Message-ID: Albert Graef: > assembler for the low-level stuff. (Not sure about snd, does it compile > to native code which can execute in realtime?) Yes, the realtime extension that I wrote compiles a scheme-like language into hard realtime-safe c code, which can be run and scheduled while snd is running. Its not optimizing as much as faust, but mostly its not significantly slower than hand-written C either. Sometimes it can even be faster. Its a practical language to get real things done because it blends into guile scheme and common lisp music so that everything is in the same source and communicates with each other. Its possible to implement things like ardour or supercollider in snd if anyone want to do that (although they have to fix some of the many bugs first :-) ). From kjetil at ccrma.stanford.edu Thu Jun 15 15:54:42 2006 From: kjetil at ccrma.stanford.edu (Kjetil S. Matheussen) Date: Thu Jun 15 15:54:46 2006 Subject: [linux-audio-dev] Re: Writing LADSPA plugins in high level language? In-Reply-To: <20060615135640.4AD951CE1305@music.columbia.edu> References: <20060615135640.4AD951CE1305@music.columbia.edu> Message-ID: "David Cournapeau": >>> >>> On Wed, Jun 14, 2006 at 07:47:36AM +0200, Alex Polite wrote: >>>> Hi there. >>>> >>>> Is it possible to write LADSPA plugins in anything but C/C++? I prefer >>>> perl, ruby or python. >>>> >>>> alex >>> >>> Anything but C/C++, yes. See FAUST [1], a compiled language designed >>> specificly for processing audio streams. Perl, Ruby, or Python, not >>> really. >>> >>> [1] >> >> >> The realtime extension for snd (scheme-like language) is another: >> http://www.notam02.no/arkiv/doc/snd-rt/ >> >> Here is a cool alsa softsynth written in that system: >> http://ccrma.stanford.edu/~kjetil/220c/ > there is also chuck, that nobody has mentionned, I think : > > http://soundlab.cs.princeton.edu/research/chuck/ > Not really. Chuck code runs in a VM and does not compile to native machine code. It also process blocks of samples, while faust and snd process one and one sample. In this respect, Chuck is more in the same class of programs like Supercollider, nyquist, csound, pd and many many others. From jens.andreasen at chello.se Thu Jun 15 16:17:12 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Thu Jun 15 16:17:20 2006 Subject: [linux-audio-dev] Mx44.1 ... The Sequel Message-ID: <1150402632.9396.37.camel@c80-216-124-251.cm-upc.chello.se> Mx44 got itself an update and will now understand some of the most important standard GS midi controllers. Also included is a fix for compiling with gcc 4. The homepage has moved to: http://members.chello.se/luna/ Mx44 is a multichannel polyphonic synthesizer, loosely based on FM-synthesis, with a Klingon approach to oscillators ... Implemented GS controllers -------------------------- R ## Ctrl 73 Attack (modifies the time value of all env stage 1 and 2) 75 Decay (modifies the time value of all env stage 3 and 4) 79 Loop (modifies the time value of all env stage 5 and 6) 72 Release (you get the drill ...) 05 Portamento (routed to intonation, being the closest match) 94 Celeste (modifies amount of frequency offset) * 07 Channel Volume (yep!) 10 Pan (rotates the sound-image) * 01 Modulation (modulation send amount from op with "Wheel" btn ON) * 70 Timbre (modulation send amount from op with "Wheel" btn OFF) * 71 Variation (balance between modulation from op 1+3/op 2+4) * 74 Cutoff Freq (resonance ctrl for oscillators connected to envelope) Controllers marked with asterix operates in true RT mode (ie: on a sustained note.) The rest is set up at note-on -- mvh // Jens M Andreasen From kjetil at ccrma.stanford.edu Thu Jun 15 17:13:26 2006 From: kjetil at ccrma.stanford.edu (Kjetil S. Matheussen) Date: Thu Jun 15 17:13:30 2006 Subject: [linux-audio-dev] Re: Writing LADSPA plugins in high level language? In-Reply-To: References: <20060615135640.4AD951CE1305@music.columbia.edu> Message-ID: On Thu, 15 Jun 2006, Kjetil S. Matheussen wrote: > > "David Cournapeau": >>>> >>>> On Wed, Jun 14, 2006 at 07:47:36AM +0200, Alex Polite wrote: >>>>> Hi there. >>>>> >>>>> Is it possible to write LADSPA plugins in anything but C/C++? I prefer >>>>> perl, ruby or python. >>>>> >>>>> alex >>>> >>>> Anything but C/C++, yes. See FAUST [1], a compiled language designed >>>> specificly for processing audio streams. Perl, Ruby, or Python, not >>>> really. >>>> >>>> [1] >>> >>> >>> The realtime extension for snd (scheme-like language) is another: >>> http://www.notam02.no/arkiv/doc/snd-rt/ >>> >>> Here is a cool alsa softsynth written in that system: >>> http://ccrma.stanford.edu/~kjetil/220c/ >> there is also chuck, that nobody has mentionned, I think : >> >> http://soundlab.cs.princeton.edu/research/chuck/ >> > > Not really. Chuck code runs in a VM and does not compile to native machine > code. It also process blocks of samples, while faust and snd process one and > one sample. In this respect, Chuck is more in the same class of programs like > Supercollider, nyquist, csound, pd and many many others. > Actually, when thinking about it, I don't know how Chuck process its samples. I just presumed that there is a different sample and data rate, but I might be wrong. Its certainly different from faust and common lisp music / snd realtime extension at least. From Dr.Graef at t-online.de Thu Jun 15 18:00:21 2006 From: Dr.Graef at t-online.de (Albert Graef) Date: Thu Jun 15 17:53:13 2006 Subject: [linux-audio-dev] Writing LADSPA plugins in high level language In-Reply-To: References: <20060615003009.2B0911CC87E9@music.columbia.edu> Message-ID: <4491D875.9030404@t-online.de> Thanks for clearing that up. I must really take a closer look at snd some time... :) Kjetil S. Matheussen wrote: > Yes, the realtime extension that I wrote compiles a scheme-like language > into hard realtime-safe c code, which can be run and scheduled while snd > is running. Its not optimizing as much as faust, but mostly its not > significantly slower than hand-written C either. Sometimes it can even > be faster. Its a practical language to get real things done because it > blends into guile scheme and common lisp music so that everything is in > the same source and communicates with each other. Its possible to > implement things like ardour or supercollider in snd if anyone want to > do that (although they have to fix some of the many bugs first :-) ). -- 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.musikinformatik.uni-mainz.de/ag From radarsat1 at gmail.com Fri Jun 16 00:11:45 2006 From: radarsat1 at gmail.com (Steve) Date: Fri Jun 16 00:11:51 2006 Subject: [linux-audio-dev] gettimeofday() freeze? Message-ID: <9b3e2dc20606152111q4ba00799xd471842a379caad@mail.gmail.com> Hi, Tonight I actually for once got around to working a bit on my pet audio project, and thought I'd finally try to tackle my issues with a processor-intensive audio loop. So I started writing a simple timing class (C++) to do some profiling... Unfortunately, instead I've found myself wasting my time because my computer (or at least X) keeps freezing! It seems that whenever I put a call to gettimeofday() in my audio loop (which gets called about every 40-or-so milliseconds, a latency I'd like to reduce), and run the program, everything just freezes... no mouse, keyboard, no screen updates, etc. Reboot required. (I tried using ssh from another computer but got no response... strangely I did get a ping response however.) To be more specific, the loop is actually a callback from PortAudio. With gettimeofday commented out, there is no freeze, the software runs as expected. Originally I thought it might be a priority problem, but I tried running it without a priority boost and using "nice -n 19", but still I get a system freeze. It's strange, because I was under the impression that a user process should never be able to hang my whole system if not running as root. Has anyone else had issues with this? Is there a better way to profile my code? Unfortunately it's a GUI program (using SDL for graphics) so it's difficult to run it in text mode. I might try figuring out how to comment out all the graphics stuff though, to see if it has the same effect without X running. I'm using Ubuntu Dapper, up-to-date: $ uname -a Linux hal9000 2.6.15-22-686 #1 SMP PREEMPT Sun May 7 16:37:57 UTC 2006 i686 GNU/Linux Thanks, Steve From notmyprivateemail at gmail.com Fri Jun 16 07:22:24 2006 From: notmyprivateemail at gmail.com (Alex Polite) Date: Fri Jun 16 07:22:28 2006 Subject: [linux-audio-dev] Writing a winner takes it all gain filter. Message-ID: Hi there. Thanks to everyone who responded to the request about high level languages for audio work. I made a wikipage to order your input and my findings. http://tinyurl.com/p4zqo It definitely looks like Faust is the most serious contender for writing LADSPA plugins. It seems to be actively maintained and well documented. It claims to be able to generate different types of plugins/applications from the same code. I'll print the tutorial and read it over the weekend. My first project will be a winner-takes-it-all-gain filter that takes n number of inputs and lowers the gain on all but the loudest signal. I want to use this on recordings of conversations where each speaker has a separate microphone. First I tried sidechain ducking which didn't really work for me. Then I tried expanding each channel, so as to mute it when it fell under the threshold. That works pretty well but it's not perfect. This winner-takes-it-all thingy should be dead simple to implement and I expect it work pretty well. alex -- Alex Polite http://flosspick.org - finding the right open source From lars.luthman at gmail.com Fri Jun 16 07:30:11 2006 From: lars.luthman at gmail.com (Lars Luthman) Date: Fri Jun 16 07:30:21 2006 Subject: [linux-audio-dev] Writing a winner takes it all gain filter. In-Reply-To: References: Message-ID: <1150457411.8903.0.camel@localhost> On Fri, 2006-06-16 at 13:22 +0200, Alex Polite wrote: > My first project will be a winner-takes-it-all-gain filter that takes > n number of inputs and lowers the gain on all but the loudest signal. Where n is a fixed number I suppose? Otherwise it won't work as a LADSPA. -- Lars Luthman - please encrypt any email sent to me if possible PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E 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: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060616/ba2947e9/attachment.bin From radarsat1 at gmail.com Fri Jun 16 07:43:20 2006 From: radarsat1 at gmail.com (Steve) Date: Fri Jun 16 07:43:25 2006 Subject: [linux-audio-dev] Writing a winner takes it all gain filter. In-Reply-To: <1150457411.8903.0.camel@localhost> References: <1150457411.8903.0.camel@localhost> Message-ID: <9b3e2dc20606160443r68077b4l797fca5278cf5b19@mail.gmail.com> > Where n is a fixed number I suppose? Otherwise it won't work as a > LADSPA. On the other hand, SuperCollider would be perfect for that... (It has automatic multichannel expansion) From fons.adriaensen at alcatelaleniaspace.com Fri Jun 16 09:05:46 2006 From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen) Date: Fri Jun 16 09:05:58 2006 Subject: [linux-audio-dev] Re: Writing LADSPA plugins in high level language? In-Reply-To: <4491AFF7.7060900@t-online.de> References: <20060614170439.4419E1CB7011@music.columbia.edu> <5b8d13220606150032i4e3efa3fgfa2f1be9fc9dbfd6@mail.gmail.com> <1150375991.1765.115.camel@localhost.localdomain> <20060615135623.GA8326@bth05w.ABSp.alcatel.be> <4491AFF7.7060900@t-online.de> Message-ID: <20060616130546.GC8871@bth05w.ABSp.alcatel.be> On Thu, Jun 15, 2006 at 09:07:35PM +0200, Albert Graef wrote: > This is hard to get right for low-level DSP programming because > efficiency is of utmost importance, but I think that Faust does this > pretty well. The only roadblock right now is that it is not suitable for > multirate processing yet, but Yann is working on that. Fons, I hope that > with your experience as a seasoned DSP programmer you will try Faust > some time; I think you might like it, and your feedback will surely be > valuable. :) After the LAC presentation I already had a look of course, and yes it looks like something I might like. But it will have to wait until I manage to finish a few other things... -- FA Follie! Follie! Delirio vano e' questo! From ben at glw.com Fri Jun 16 10:10:00 2006 From: ben at glw.com (Ben Loftis) Date: Fri Jun 16 10:09:58 2006 Subject: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 33, Issue 11 In-Reply-To: <20060616130602.430E31D1B3E7@music.columbia.edu> References: <20060616130602.430E31D1B3E7@music.columbia.edu> Message-ID: <200606160910.00114.ben@glw.com> Hi Alex. What you're trying to implement is called an automixer. "Winner Takes All" is probably not going to work as well as your original expander. It will have problems when somebody coughs, drops their books, bumps the mic, tries to interject, etc, because it will duck the current speaker. Here are some of the subtleties that you might want to consider: A "filibuster" function which guarantees that once a mic is gated on, it stays on until the speaker has gone silent for a second or three, and it can't be silenced by some other mic gating on. An "AGC" (automatic gain control) algorithm on each mic that guarantees quiet speakers and loud speakers have the same perceived volume in the recording. Duck the unused mics a few dB instead of a fully gating them, or always leave one mic open. The room ambience is important and it (kinda) proves the recording hasn't been doctored. I picked up an IED 8000-series automixer which does all these things on eBay for $20.00. Dan Dugan also makes some nice ones. So if this is a one-shot deal for a serious project, you may want to consider finding something similar that is proven to work rather than rolling your own. Just my $0.02 -Ben Loftis > > My first project will be a winner-takes-it-all-gain filter that takes > n number of inputs and lowers the gain on all but the loudest signal. > I want to use this on recordings of conversations where each speaker > has a separate microphone. First I tried sidechain ducking which > didn't really work for me. Then I ?tried expanding each channel, so as > to mute it when it fell under the threshold. That works pretty well > but it's not perfect. This winner-takes-it-all thingy should be dead > simple to implement and I expect it work pretty well. > > alex From bil at ccrma.Stanford.EDU Fri Jun 16 10:29:45 2006 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Fri Jun 16 10:29:52 2006 Subject: [linux-audio-dev] Re: Writing a winner takes it all gain filter. In-Reply-To: <20060616130602.2C88C1D1B3E5@music.columbia.edu> References: <20060616130602.2C88C1D1B3E5@music.columbia.edu> Message-ID: <20060616142721.M19738@ccrma.Stanford.EDU> Why do you say sndlib is "poorly maintained"? I did not get any bug reports that I remember. Also, it can be used with LADSPA, but I prefer a higher level approach. From Dr.Graef at t-online.de Fri Jun 16 13:12:48 2006 From: Dr.Graef at t-online.de (Albert Graef) Date: Fri Jun 16 13:05:20 2006 Subject: [linux-audio-dev] Re: Writing LADSPA plugins in high level language? In-Reply-To: <20060616130546.GC8871@bth05w.ABSp.alcatel.be> References: <20060614170439.4419E1CB7011@music.columbia.edu> <5b8d13220606150032i4e3efa3fgfa2f1be9fc9dbfd6@mail.gmail.com> <1150375991.1765.115.camel@localhost.localdomain> <20060615135623.GA8326@bth05w.ABSp.alcatel.be> <4491AFF7.7060900@t-online.de> <20060616130546.GC8871@bth05w.ABSp.alcatel.be> Message-ID: <4492E690.9010505@t-online.de> Alfons Adriaensen wrote: > After the LAC presentation I already had a look of course, and yes > it looks like something I might like. But it will have to wait until > I manage to finish a few other things... Yes, I'm voting for making the day 0x24 hours! -- 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.musikinformatik.uni-mainz.de/ag From kjetil at ccrma.stanford.edu Fri Jun 16 14:44:57 2006 From: kjetil at ccrma.stanford.edu (Kjetil S. Matheussen) Date: Fri Jun 16 14:45:08 2006 Subject: [linux-audio-dev] Writing a winner takes it all gain filter. In-Reply-To: <20060616130602.2C88C1D1B3E5@music.columbia.edu> References: <20060616130602.2C88C1D1B3E5@music.columbia.edu> Message-ID: "Alex Polite": >Hi there. > >Thanks to everyone who responded to the request about high level >languages for audio work. >I made a wikipage to order your input and my findings. > >http://tinyurl.com/p4zqo > >It definitely looks like Faust is the most serious contender for >writing LADSPA plugins. It seems to be actively maintained and well >documented. It claims to be able to generate different types of >plugins/applications from the same code. I'll print the tutorial and >read it over the weekend. > I suggest that you rewrite the comment about snd. Writing "lispish, yuck" doesn't give you much credit as someone worth listening to. Also, for many other really good alternatives, like csound and supercollider, you have just written "naa". I suggest that you do some more research as well... From parumi at iua.upf.edu Fri Jun 16 15:22:13 2006 From: parumi at iua.upf.edu (Pau Arumi) Date: Fri Jun 16 15:10:15 2006 Subject: [linux-audio-dev] [iua-mtg] CLAM 0.91.0 Message-ID: <449304E5.90905@iua.upf.edu> CLAM 0.91.0 Release Announcement ?Spectral transformations, annotator, packaging, and desktop integration release' We are glad to announce the 0.91.0 CLAM release which comes by the hand with Music Annotator 0.3.2, Network Editor 0.3.1 and SMSTools 0.4.1. They are available for download as source tarballs and also as binary packages for Windows, Ubuntu dapper, Debian sid and Fedora Core 5. MacOsX binaries are not available for this release, but we promise they will be back soon. This release is the first official one which incorporates the new CLAM Music Annotator featuring chord extraction. Almost 30 new spectral transformations have been incorporated into the processing repository. Some of them are already available from the NetworkEditor. Application usage has received some extra stress on this release. Applications are better integrated on Windows and Linux desktops. Step by step application tutorials are available on the clam wiki for Music Annotator [1], SMSTools [2], Network Editor and Prototyper [3]. And, all of them all provide examples to start with. Please read these and other improvements in the changelog [4] or visit our website [5] for further details. We expect as much feedback as possible from all our users. Besides the mailing list, you can likely find us at #clam channel on FreeNode (IRC network). The CLAM team [1] http://iua-share.upf.es/wikis/clam/index.php/Music_Annotator_tutorial [2] http://iua-share.upf.es/wikis/clam/index.php/SMSTools_tutorial [3] http://iua-share.upf.es/wikis/clam/index.php/Network_Editor_tutorial [4] http://clam.iua.upf.edu/ChangeLog.html [5] http://clam.iua.upf.edu From smcameron at yahoo.com Fri Jun 16 16:24:01 2006 From: smcameron at yahoo.com (Stephen Cameron) Date: Fri Jun 16 16:24:07 2006 Subject: [linux-audio-dev] How to use the alsa sequencer? Message-ID: <20060616202401.37147.qmail@web33003.mail.mud.yahoo.com> Hi, I'm trying to figure out how to use the ALSA sequencer with my app. (to date, I've been just using raw midi). What I'm supposed to use for the "name" parameter for snd_seq_open is not exactly clear. I've been using "hw:0,0" and it returns zero, but I'm not sure it's right (see aconnect -lio output below.); That's my soundcard, however, I'm really trying to send to a softsynth. [scameron@zuul ~]$ amidi -l Device Name hw:0,0 Audigy MPU-401 (UART) hw:0,1 Audigy MPU-401 #2 hw:0,2 Emu10k1 Synth MIDI (16 subdevices) hw:0,3 Emu10k1 Synth MIDI (16 subdevices) [scameron@zuul ~]$ I have code to open and set up an alsa client port that looks like this: struct midi_handle *midi_open_alsa(unsigned char *name) { int rc; struct midi_handle_alsa *mh; unsigned char clientname[255], portname[255]; sprintf(clientname, "Gneutronica (%d)", getpid()); mh = (struct midi_handle_alsa *) malloc(sizeof(*mh)); if (mh == NULL) return NULL; rc = snd_seq_open(&mh->seqp, name, SND_SEQ_OPEN_OUTPUT, 0); if (rc < 0) { printf("snd_seq_open returns %d\n", rc); free(mh); return NULL; } rc = snd_seq_set_client_name(mh->seqp, clientname); if (rc < 0) printf("snd_seq_set_client_name failed \n"); sprintf(portname, "Gneutronica output (%d:%d)", getpid(), 0); mh->outputport = snd_seq_create_simple_port(mh->seqp, portname, SND_SEQ_PORT_CAP_READ|SND_SEQ_PORT_CAP_SUBS_READ, SND_SEQ_PORT_TYPE_MIDI_GENERIC); if (mh->outputport < 0) printf("snd_seq_create_simple_port failed\n"); return (struct midi_handle *) mh; } struct midi_handle_alsa is just this: struct midi_handle_alsa { snd_seq_t *seqp; /* alsa sequencer port */ int outputport; }; This *appears* to work... When I run my app, I can see this: [root@zuul ~]# aconnect -loi client 0: 'System' [type=kernel] 0 'Timer ' 1 'Announce ' Connecting To: 15:0 client 14: 'Midi Through' [type=kernel] 0 'Midi Through Port-0' client 16: 'Audigy MPU-401 #2' [type=kernel] 0 'Audigy MPU-401 (UART)' 32 'Audigy MPU-401 #2' client 17: 'Emu10k1 WaveTable' [type=kernel] 0 'Emu10k1 Port 0 ' 1 'Emu10k1 Port 1 ' 2 'Emu10k1 Port 2 ' 3 'Emu10k1 Port 3 ' client 128: 'FLUID Synth (6096)' [type=user] 0 'Synth input port (6096:0)' client 129: 'Gneutronica (14693)' [type=user] 0 'Gneutronica output (14693:0)' There's my app, client 129, and I can do this: [root@zuul ~]# aconnect 129:0 128:0 [root@zuul ~]# aconnect -loi client 0: 'System' [type=kernel] 0 'Timer ' 1 'Announce ' Connecting To: 15:0 client 14: 'Midi Through' [type=kernel] 0 'Midi Through Port-0' client 16: 'Audigy MPU-401 #2' [type=kernel] 0 'Audigy MPU-401 (UART)' 32 'Audigy MPU-401 #2' client 17: 'Emu10k1 WaveTable' [type=kernel] 0 'Emu10k1 Port 0 ' 1 'Emu10k1 Port 1 ' 2 'Emu10k1 Port 2 ' 3 'Emu10k1 Port 3 ' client 128: 'FLUID Synth (6096)' [type=user] 0 'Synth input port (6096:0)' Connected From: 129:0 client 129: 'Gneutronica (14693)' [type=user] 0 'Gneutronica output (14693:0)' Connecting To: 128:0 [root@zuul ~]# Which, I think looks correct... the aconnect makes client 128:0 subscribe to 129:0, right? But, when I try to send events from my app, they don't seem to go through. Here's the event sending code: void midi_noteon_alsa(struct midi_handle *mh, unsigned char channel, unsigned char value, unsigned char volume) { struct midi_handle_alsa *mha = (struct midi_handle_alsa *) mh; snd_seq_event_t ev; snd_seq_ev_clear(&ev); snd_seq_ev_set_source(&ev, mha->outputport); snd_seq_ev_set_subs(&ev); snd_seq_ev_set_direct(&ev); ev.type = SND_SEQ_EVENT_NOTEON; ev.data.note.channel = channel; ev.data.note.note = value; ev.data.note.velocity = volume; ev.data.note.off_velocity = 0; ev.data.note.duration = 100; /* it's drums... there is no note off. */ printf("Sending event to port %d, note=%d, vel=%d, pid=%d\n", mha->outputport, ev.data.note.note, ev.data.note.velocity, getpid()); snd_seq_event_output(mha->seqp, &ev); return; } I get output from my app that looks like: Bass Drum Sending event to port 0, note=35, vel=100, pid=14693 Bass Drum Sending event to port 0, note=36, vel=100, pid=14693 Rim Stick Sending event to port 0, note=37, vel=100, pid=14693 Tom Hi Sending event to port 0, note=38, vel=100, pid=14693 Hand Clap Sending event to port 0, note=39, vel=100, pid=14693 (The channel is zero.) If I use raw midi (write to a file descriptor hooked to /dev/snd/midiC2D0 and use snd-virmidi acconnected to Fluidsynth... it works. I'm obviously missing something, but it's not obvious to me what it is... Any ideas? Thanks, -- steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From orlarey at grame.fr Fri Jun 16 16:34:45 2006 From: orlarey at grame.fr (Orlarey Yann) Date: Fri Jun 16 16:35:53 2006 Subject: [linux-audio-dev] Writing a winner takes it all gain filter. In-Reply-To: References: Message-ID: <449315E5.9070808@grame.fr> Hi Alex, Alex Polite a ?crit : > My first project will be a winner-takes-it-all-gain filter that takes > n number of inputs and lowers the gain on all but the loudest signal. If I have correctly understood the problem, here is how it could be implemented in Faust : envelop = abs : max ~ -(0.00001); loudest(x,y) = x*(envelop(x)>envelop(y)) + y*(envelop(x) <= envelop(y)); process = loudest; The first line compute a very simple envelop from an input signal : y(t) = max( abs(x(t)), y(t-1) - 0.000001 ) The second line computes the loudest of two signals by comparing their envelops. The last line defines the 'process' we want to compute (the equivalent of main in C). Here is the core of the code generated by the Faust compiler : for (int i=0; i fRec0Temp)) + (fTemp0 * (fRec1Temp <= fRec0Temp))); fRec1 = fRec1Temp; fRec0 = fRec0Temp; } If you need more than two input signals you can cascade several loudest modules. For example : process = loudest : loudest; will take the loudest of 3 signals And : process = loudest : loudest : loudest; will take the loudest of 4 signals. Instead of cascading 'loudest' manually so to speak, you could also write : process = seq(i,7,loudest); This will take the loudest of 8 signals by cascading 'loudest' 7 times. Obviously this is not the most efficient way as it computes 2*7 envelops instead of the 8 needed. Here is a more efficient solution that computes the right number of envelops: envelop = abs : max ~ -(0.00001); loudest(ex,x,y) = max(ex, envelop(y)), x*(ex>envelop(y)) + y*(ex <= envelop(y)); chain(n) = first : seq(i,n-1,loudest) : ! ; first(x) = envelop(x), x; process = chain (8); As you can see, loudest now takes 3 arguments and produces 2 signals. The first argument is the envelop of x and the first result is the combined envelop of x and y. Hoping this will help... Yann From S.W.Harris at ecs.soton.ac.uk Sat Jun 17 06:27:41 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sat Jun 17 06:28:00 2006 Subject: [linux-audio-dev] Writing a winner takes it all gain filter. In-Reply-To: References: <20060616130602.2C88C1D1B3E5@music.columbia.edu> Message-ID: <20060617102741.GA21525@login.ecs.soton.ac.uk> On Fri, Jun 16, 2006 at 11:44:57 -0700, Kjetil S. Matheussen wrote: > I suggest that you rewrite the comment about snd. Writing "lispish, yuck" > doesn't give you much credit as someone worth listening to. Hum. It's maybe not tactfuly expressed, but the s-expression syntax has a number of objectors with informed positions. It is near one end of a broad spectrum of languages so inevitably not to everyones taste. - Steve From smcameron at yahoo.com Sat Jun 17 13:19:48 2006 From: smcameron at yahoo.com (Stephen Cameron) Date: Sat Jun 17 13:19:55 2006 Subject: [linux-audio-dev] Re: How to use the alsa sequencer? In-Reply-To: <20060616202401.37147.qmail@web33003.mail.mud.yahoo.com> Message-ID: <20060617171948.15792.qmail@web33005.mail.mud.yahoo.com> --- Stephen Cameron wrote: > > Hi, > > I'm trying to figure out how to use the ALSA sequencer > with my app. (to date, I've been just using raw midi). Some progress... This code seems to work... it relies on explicitly setting the destination client id to 128... where I happen to know the fluidsynth happens to be sitting. void midi_noteon_alsa(struct midi_handle *mh, unsigned char channel, unsigned char value, unsigned char volume) { struct midi_handle_alsa *mha = (struct midi_handle_alsa *) mh; snd_seq_event_t ev; struct snd_seq_real_time tstamp; int rc; memset(&tstamp, 0, sizeof(tstamp)); snd_seq_ev_clear(&ev); snd_seq_ev_set_source(&ev, mha->outputport); snd_seq_ev_set_subs(&ev); snd_seq_ev_set_dest(&ev, 128, 0); /* <---- magically makes it work */ /* snd_seq_ev_set_direct(&ev); snd_seq_ev_set_dest(&ev, SND_SEQ_EVENT_PORT_SUBSCRIBED, 0); */ snd_seq_ev_set_noteon(&ev, channel, value, volume); /* ev.data.note.duration = 1000; */ /* it's drums... there is no note off. */ snd_seq_ev_schedule_real(&ev, mha->queue, 1, &tstamp); /* printf("Sending event to port %d, chan=%d, note=%d, vel=%d, pid=%d\n", mha->outputport, ev.data.note.channel, ev.data.note.note, ev.data.note.velocity, getpid()); */ rc = snd_seq_event_output(mha->seqp, &ev); if (rc < 0) printf("Failed to output note.\n"); snd_seq_drain_output(mha->seqp); return; } But if I take out this line snd_seq_ev_set_dest(&ev, 128, 0); And replace it with: snd_seq_ev_set_dest(&ev, SND_SEQ_EVENT_PORT_SUBSCRIBED, 0); And try to use aconnect to connect things together, it doesn't seem to work. So, there's some piece of the puzzle regarding how aconnect works that I'm missing. Any ideas? Thanks, -- steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From kjetil at ccrma.stanford.edu Sat Jun 17 16:37:45 2006 From: kjetil at ccrma.stanford.edu (Kjetil S. Matheussen) Date: Sat Jun 17 16:37:50 2006 Subject: [linux-audio-dev] Writing a winner takes it all gain filter. Message-ID: Steve Harris: >Hum. It's maybe not tactfuly expressed, but the s-expression syntax has a >number of objectors with informed positions. > >It is near one end of a broad spectrum of languages so inevitably not to >everyones taste. Sure. Syntax can be more compact without s-expressions, and the syntax can also be more formed towards specific purposes without s-expressions as well, like smalltalk that use {...} instead of (lambda ()...), and C that use {...} instead of (begin ...), and things like accessing array values or setting values requires more characters with s-expression since you can't use special characters for common tasks. But the fact that you have complete control over the language in a way that a non-lisper is probably not able to understand without ever using lisp macros weights up for all those things. However, when people normally bash lisp, its probably because of the following reason: All the paranthesis looks ugly and are confusing. For example, I actually spent almost two years programming lisp before I started to like lisp very much. The paranthesis confusion dissapeared quickly, but thinking lispish was harder. Before that, I thought python was the most beautiful language of them all. (I knew about 20 programming languages at that time.) From loki.davison at gmail.com Sat Jun 17 21:36:21 2006 From: loki.davison at gmail.com (Loki Davison) Date: Sat Jun 17 21:36:25 2006 Subject: [linux-audio-dev] Re: Writing a winner takes it all gain filter. In-Reply-To: References: Message-ID: On 6/18/06, Kjetil S. Matheussen wrote: > > Steve Harris: > >Hum. It's maybe not tactfuly expressed, but the s-expression syntax has a > >number of objectors with informed positions. > > > >It is near one end of a broad spectrum of languages so inevitably not to > >everyones taste. > > Sure. Syntax can be more compact without s-expressions, and the syntax can > also be more formed towards specific purposes without s-expressions as > well, like smalltalk that use {...} instead of (lambda ()...), and C that > use {...} instead of (begin ...), and things like accessing array values > or setting values requires more characters with s-expression since you > can't use special characters for common tasks. But the fact that you have > complete control over the language in a way that a non-lisper is probably > not able to understand without ever using lisp macros weights up for all > those things. > > However, when people normally bash lisp, its probably because of the > following reason: > All the paranthesis looks ugly and are confusing. > > For example, I actually spent almost two years programming lisp before I > started to like lisp very much. The paranthesis confusion dissapeared > quickly, but thinking lispish was harder. Before that, I thought python > was the most beautiful language of them all. (I knew about 20 programming > languages at that time.) I program python where I work and it is a really wonderful and beautiful language. I prefer the syntax of lisp for some stuff though. What common lisp lacks is a half decent standard library like python that actually has useful stuff in it. Also an easy way to right bindings for libs in other languages would be nice too. Loki From notmyprivateemail at gmail.com Sun Jun 18 05:19:39 2006 From: notmyprivateemail at gmail.com (Alex Polite) Date: Sun Jun 18 05:19:48 2006 Subject: [linux-audio-dev] Re: Writing a winner takes it all gain filter. In-Reply-To: <20060616142721.M19738@ccrma.Stanford.EDU> References: <20060616130602.2C88C1D1B3E5@music.columbia.edu> <20060616142721.M19738@ccrma.Stanford.EDU> Message-ID: On 6/16/06, Bill Schottstaedt wrote: > Why do you say sndlib is "poorly maintained"? I did not get any > bug reports that I remember. Sorry. That should have been libsndfile -- Alex Polite http://flosspick.org - finding the right open source From notmyprivateemail at gmail.com Sun Jun 18 05:22:53 2006 From: notmyprivateemail at gmail.com (Alex Polite) Date: Sun Jun 18 05:23:01 2006 Subject: [linux-audio-dev] Writing a winner takes it all gain filter. In-Reply-To: References: <20060616130602.2C88C1D1B3E5@music.columbia.edu> Message-ID: On 6/16/06, Kjetil S. Matheussen wrote: > > I suggest that you rewrite the comment about snd. Writing "lispish, yuck" > doesn't give you much credit as someone worth listening to. (I (just) ((don't happen to like) parentheses)) :) > > Also, for many other really good alternatives, like csound and > supercollider, you have just written "naa". I suggest that you do some > more research as well... yeah yeah -- Alex Polite http://flosspick.org - finding the right open source From notmyprivateemail at gmail.com Sun Jun 18 05:32:17 2006 From: notmyprivateemail at gmail.com (Alex Polite) Date: Sun Jun 18 05:32:27 2006 Subject: [Faudiostream-devel] [linux-audio-dev] Writing a winner takes it all gain filter. In-Reply-To: <449315E5.9070808@grame.fr> References: <449315E5.9070808@grame.fr> Message-ID: On 6/16/06, Orlarey Yann wrote: > > Hoping this will help... It sure does. Thank you very much. I read the Faust tutorial over the weekend and I am now absolutely convinced that Faust is just the thing I was looking for. alex -- Alex Polite http://flosspick.org - finding the right open source From mle+la at mega-nerd.com Sun Jun 18 06:00:56 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Sun Jun 18 06:01:10 2006 Subject: [linux-audio-dev] Re: Writing a winner takes it all gain filter. In-Reply-To: References: <20060616130602.2C88C1D1B3E5@music.columbia.edu> <20060616142721.M19738@ccrma.Stanford.EDU> Message-ID: <20060618200056.38377c7b.mle+la@mega-nerd.com> Alex Polite wrote: > On 6/16/06, Bill Schottstaedt wrote: > > Why do you say sndlib is "poorly maintained"? I did not get any > > bug reports that I remember. > > Sorry. That should have been libsndfile What do you mean about libsndfile being poorly maintained? Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ Fundamentalist : Someone who is colour blind and yet wants everyone else to see the world with the same lack of colour. From notmyprivateemail at gmail.com Sun Jun 18 06:44:56 2006 From: notmyprivateemail at gmail.com (Alex Polite) Date: Sun Jun 18 06:45:01 2006 Subject: [linux-audio-dev] Re: Writing a winner takes it all gain filter. In-Reply-To: <20060618200056.38377c7b.mle+la@mega-nerd.com> References: <20060616130602.2C88C1D1B3E5@music.columbia.edu> <20060616142721.M19738@ccrma.Stanford.EDU> <20060618200056.38377c7b.mle+la@mega-nerd.com> Message-ID: On 6/18/06, Erik de Castro Lopo wrote: > What do you mean about libsndfile being poorly maintained? Not libsndfile in itself but the ruby wrapper for it. alex -- Alex Polite http://flosspick.org - finding the right open source From smcameron at yahoo.com Sun Jun 18 08:34:18 2006 From: smcameron at yahoo.com (Stephen Cameron) Date: Sun Jun 18 08:34:24 2006 Subject: [linux-audio-dev] Re: How to use the alsa sequencer? In-Reply-To: <20060617171948.15792.qmail@web33005.mail.mud.yahoo.com> Message-ID: <20060618123418.26429.qmail@web33002.mail.mud.yahoo.com> --- Stephen Cameron wrote: > But if I take out this line > > snd_seq_ev_set_dest(&ev, 128, 0); > > And replace it with: > > snd_seq_ev_set_dest(&ev, SND_SEQ_EVENT_PORT_SUBSCRIBED, 0); > > And try to use aconnect to connect things together, it doesn't > seem to work. Perusing /usr/include/alsa/seqmid.h cleared up the confusion. The port number has to be SND_SEQ_ADDRESS_UNKNOWN, not 0, best accomplished by: snd_seq_ev_set_subs(&ev); Then it works with aconnect. Thanks for reading my newbie ramblings... -- steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From pedro.lopez.cabanillas at gmail.com Sun Jun 18 13:24:11 2006 From: pedro.lopez.cabanillas at gmail.com (Pedro Lopez-Cabanillas) Date: Sun Jun 18 13:24:21 2006 Subject: [linux-audio-dev] Re: How to use the alsa sequencer? In-Reply-To: <20060618100115.D1A0D1D68C62@music.columbia.edu> References: <20060618100115.D1A0D1D68C62@music.columbia.edu> Message-ID: <200606181924.12079.pedro.lopez.cabanillas@gmail.com> On Sunday, 18 June 2006, Stephen Cameron wrote: > > Hi, > > > > I'm trying to figure out how to use the ALSA sequencer > > with my app. ?(to date, I've been just using raw midi). [..] > But if I take out this line > > ? ? ? ? snd_seq_ev_set_dest(&ev, 128, 0); > > And replace it with: > > ? ? ? ? ?snd_seq_ev_set_dest(&ev, SND_SEQ_EVENT_PORT_SUBSCRIBED, 0); > > And try to use aconnect to connect things together, it doesn't > seem to work. > > So, there's some piece of the puzzle regarding how aconnect > works that I'm missing. snd_seq_ev_set_subs(&ev); I guess you may want to generate the ALSA library documentation from the sources with doxygen. It is also available online: http://www.alsa-project.org/alsa-doc/alsa-lib/seq.html Regards, Pedro From notmyprivateemail at gmail.com Sun Jun 18 14:58:39 2006 From: notmyprivateemail at gmail.com (Alex Polite) Date: Sun Jun 18 14:58:46 2006 Subject: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 33, Issue 11 In-Reply-To: <200606160910.00114.ben@glw.com> References: <20060616130602.430E31D1B3E7@music.columbia.edu> <200606160910.00114.ben@glw.com> Message-ID: On 6/16/06, Ben Loftis wrote: > Hi Alex. What you're trying to implement is called an automixer. "Winner > Takes All" is probably not going to work as well as your original expander. > It will have problems when somebody coughs, drops their books, bumps the mic, > tries to interject, etc, because it will duck the current speaker. Here are > some of the subtleties that you might want to consider: > > A "filibuster" function which guarantees that once a mic is gated on, it stays > on until the speaker has gone silent for a second or three, and it can't be > silenced by some other mic gating on. > > An "AGC" (automatic gain control) algorithm on each mic that guarantees quiet > speakers and loud speakers have the same perceived volume in the recording. > > Duck the unused mics a few dB instead of a fully gating them, or always leave > one mic open. The room ambience is important and it (kinda) proves the > recording hasn't been doctored. > > I picked up an IED 8000-series automixer which does all these things on eBay > for $20.00. Dan Dugan also makes some nice ones. So if this is a one-shot > deal for a serious project, you may want to consider finding something > similar that is proven to work rather than rolling your own. > Hi Ben. Thanks for your input. Since I don't have a high quality audio card I want to remain in the digital domain for as long as possible. I was thinking that I could fix the problem with coughs and such with automation. The kind folks on the ardour list tells me that ardour will let me do effect automation. I'll fool around with the faust code Yann posted and get back to you guys when I hit a wall ;) -- Alex Polite http://flosspick.org - finding the right open source From smcameron at yahoo.com Sun Jun 18 16:37:53 2006 From: smcameron at yahoo.com (Stephen Cameron) Date: Sun Jun 18 16:38:00 2006 Subject: [linux-audio-dev] Re: How to use the alsa sequencer? In-Reply-To: <200606181924.12079.pedro.lopez.cabanillas@gmail.com> Message-ID: <20060618203753.17343.qmail@web33001.mail.mud.yahoo.com> > snd_seq_ev_set_subs(&ev); > > I guess you may want to generate the ALSA library documentation from the > sources with doxygen. It is also available online: > http://www.alsa-project.org/alsa-doc/alsa-lib/seq.html > Thanks, I'd found that already... it's slightly better than no documentation. :-) But I'll take what I can get. It's a little rough going at first when it kind of assumes you're aware of a big picture that, in my case, I was almost totally unaware of. As you slowly figure it out, and the bigger picture of how all the pieces fit together -- sequencer ports, clients, channels, and how they're named and accessed and what's what, the docs become a little clearer. Helps to understand it before you read it, heh. -- steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From cp_singh at faith.co.jp Sun Jun 18 23:31:27 2006 From: cp_singh at faith.co.jp (chandrashekhar singh) Date: Sun Jun 18 23:31:53 2006 Subject: [linux-audio-dev] Re: Linux Audio driver problem on TI OMAP 2430 References: <14ACE099F888004586603AEC0A559C2E1A2580@DLEE09.ent.ti.com> Message-ID: <009401c69350$da4ffde0$5811a80a@cpsingh> Hi Nishanth, Hope you are doing well. We have an issue with the Linux kernel 2.6 for OMAP 2430 which is available on TI site for download. The Stereo effect does not work. Would you advise us some thing, why it does work? We are planning to test our surround and other effect modules on this target but due to stereo does not work, we can't test our midi engine with effect module. Please advise us if any to come out of this problem. Best Regards chandrashekhar ----- Original Message ----- From: "Menon, Nishanth" To: "chandrashekhar singh" Sent: Wednesday, June 07, 2006 11:01 PM Subject: RE: Linux Audio driver problem on TI OMAP 2430 Chandrashekar, If ur using MV kernel, then there are some interesting things u can play with :).. u can now choose to switch b/w the onboard speakers and the headset speakers using IOCTLs (don't remember offhand what it was). There is one interesting factor I had reported to the SDP team, recording can be done from headset mic (the 2.5 mm) only if I plug in a headset into the 3.5mm jack.. just thought I'd warn u on this.. minor irritant, but better know than being surprised.. Regards, Nishanth Menon > -----Original Message----- > From: chandrashekhar singh [mailto:cp_singh@faith.co.jp] > Sent: Tuesday, June 06, 2006 10:18 PM > To: Menon, Nishanth > Cc: Khasim, Syed > Subject: Re: Linux Audio driver problem on TI OMAP 2430 > > Hi Nishanth, > > Thanks for your prompt response which saved our alot of time > now we have tested our application on revised version of Board > component and it seems working perfectly. > > Thanking you all. > ======================== > \ chandrashekhar singh > \ cp_singh@faith.co.jp > / Faith Inc. Tokyo > / www.faith.co.jp > ======================== > ----- Original Message ----- > From: "Menon, Nishanth" > To: "Khasim, Syed" ; "chandrashekhar singh" > > Sent: Wednesday, May 31, 2006 9:52 PM > Subject: RE: Linux Audio driver problem on TI OMAP 2430 > > > Hi Chandrashekar, > Please look for modification to the following board revision numbers: > * T2 Companion Board, Revision 750-2012-001 (E). > * Connectivity Board, Revision 750-2003-002 (D). > * Enhanced LCD/Audio Board, Revision 750-2038-001 (C). > Regards, > Nishanth Menon > > -----Original Message----- > > From: linux-omap-open-source-bounces@linux.omap.com > [mailto:linux-omap- > > open-source-bounces@linux.omap.com] On Behalf Of Khasim, Syed > > Sent: Wednesday, May 31, 2006 7:29 AM > > To: chandrashekhar singh; linux-omap-open-source@linux.omap.com > > Subject: RE: Linux Audio driver problem on TI OMAP 2430 > > > > Hi Chandra shekhar, > > > > Which version of 2430 SDP is this and are you working with TWL4030 > (T2) > > audio codec? > > > > There was a noise issue with T2 audio codec and got resolved later. > This > > needs some hardware modifications. You might have to upgrade your > board. > > Please contact your vendor. > > > > Regards, > > Khasim > > > > -----Original Message----- > > From: linux-omap-open-source-bounces+x0khasim=ti.com@linux.omap.com > > [mailto:linux-omap-open-source-bounces+x0khasim=ti.com@linux.omap.com] > > On Behalf Of chandrashekhar singh > > Sent: Wednesday, May 31, 2006 6:07 AM > > To: linux-omap-open-source@linux.omap.com > > Subject: Linux Audio driver problem on TI OMAP 2430 > > > > Dear All, > > We are working on a porting on porting of a audio application on > > TI OMAP 2430. > > > > We have got running Monta-vista linux kernel 2.4 on this target board > > and ported our application, while playing we noticed that there is > > some noise generated by audio driver in back ground. > > > > For testing purpose we have downloaded Genaral Linux kernel 2.6 for > > OMAP 2430 from TI site and tested our appliction on this. > > > > The problem remain same on both linux. > > > > If any body had experience this problem and have got some solution > > please help me out. > > > > > > Thanks in advance. > > chandrashekhar > > _______________________________________________ > > Linux-omap-open-source mailing list > > Linux-omap-open-source@linux.omap.com > > http://linux.omap.com/mailman/listinfo/linux-omap-open-source > > _______________________________________________ > > Linux-omap-open-source mailing list > > Linux-omap-open-source@linux.omap.com > > http://linux.omap.com/mailman/listinfo/linux-omap-open-source From jez at technetium.net.au Mon Jun 19 04:03:43 2006 From: jez at technetium.net.au (jez@technetium.net.au) Date: Mon Jun 19 04:03:52 2006 Subject: [linux-audio-dev] LADSPA Extension for Extra GUI Data Message-ID: <20060619180343.307d9kslps8400gc@webmail.technetium.net.au> Hello, i'm new here, i've been working on a very simple, backward-forwards compatible extension to LADSPA/DSSI to allow hosts to display more meaningful gui's with a "describe_value" function which takes the port index and a LADSPA_Data and allows the plugin to return a meaningful description. eg. for a waveform port it might return "SAW", "SIN", "SQR" etc for a cutoff filter it might return the frequency in Hz for a tuning port it might return "-4 semitones" also wanting to add a mechanism to group ports into logical sections. without changing the underlying APIs, only by adding more layers on top this way preserving backwards compatibility, the host simply dlsyms for "ladgui_descriptor" and if it's there it makes use of the extra data, otherwise it falls back to how it previously did things once the API is done i plan to make a reference gui the idea behind this is that plugins will not need any of their own gui code as a useful gui can be constructed on the fly as a part of the host or a separate process that will work for any plugin so plugin developers never need worry about constructing a gui and can instead just make nice useable algorithms and test them quickly and easily. nicknamed LADGUI for now. API so far is at http://ftsf.technetium.net.au/code/ladgui/ladgui.h what i'd like to know is, if this is a stupid idea ^_^ it seems like a good one to me, but when i joined here to post this i noticed lots of talk about LADSPA2, i've tried to read up on it but i can't seem to find much information about it, and it doesn't seem to be backwards compatible and doesn't seem to add anything to help create guis in the host? is there a page somewhere which explains it all? i'm sure there's lots of useful stuff that i'm missing, what other things would be useful in such an extension? thanks Jez Kabanov From S.W.Harris at ecs.soton.ac.uk Mon Jun 19 04:51:05 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Mon Jun 19 04:51:32 2006 Subject: [linux-audio-dev] LADSPA Extension for Extra GUI Data In-Reply-To: <20060619180343.307d9kslps8400gc@webmail.technetium.net.au> References: <20060619180343.307d9kslps8400gc@webmail.technetium.net.au> Message-ID: <20060619085105.GA13431@login.ecs.soton.ac.uk> On Mon, Jun 19, 2006 at 06:03:43 +1000, jez@technetium.net.au wrote: > Hello, i'm new here, > i've been working on a very simple, backward-forwards compatible extension to > LADSPA/DSSI to allow hosts to display more meaningful gui's with a > "describe_value" function which takes the port index and a LADSPA_Data and > allows the plugin to return a meaningful description. eg. > for a waveform port it might return "SAW", "SIN", "SQR" etc > for a cutoff filter it might return the frequency in Hz > for a tuning port it might return "-4 semitones" This is handled in LADSPA+RDF and LV2 (aka LADSPA2) using scalePoints, eg. http://lv2plug.in/plugins/Amp-example.lv2/amp.ttl, search for lv2:scalePoint. That one's a silly example, but it makes the point. Things like "-4 semitones" will be handled by a units extensions, which will also allow hosts to use things like native gain control sliders for decibel ports, and BBT controls for time inputs. This idea is better in some ways, though though overall I prefer doing it though description, rather than programatically. - Steve From jez at technetium.net.au Sun Jun 18 17:51:59 2006 From: jez at technetium.net.au (Jez Kabanov) Date: Mon Jun 19 05:50:09 2006 Subject: [linux-audio-dev] Re: LADSPA Extension for Extra GUI Data References: 20060619180343.307d9kslps8400gc@webmail.technetium.net.au Message-ID: <4495CAFF.9030403@technetium.net.au> > This is handled in LADSPA+RDF and LV2 (aka LADSPA2) using scalePoints, eg. > http://lv2plug.in/plugins/Amp-example.lv2/amp.ttl, search for > lv2:scalePoint. That one's a silly example, but it makes the point. > > Things like "-4 semitones" will be handled by a units extensions, which > will also allow hosts to use things like native gain control sliders for > decibel ports, and BBT controls for time inputs. > > This idea is better in some ways, though though overall I prefer doing it > though description, rather than programatically. > > - Steve hmm, wouldn't that mean you need to code something (or include another library) to parse all that description language making it difficult for the host coder, and requires learning of a new language for the plugin developer. seems much simpler and quicker for a plugin developer and host developer to use a simple callback. but the localisation is a good idea, but couldn't be handled via gettext in the usual manner. the advantage of this method is that it can achieve these goals without breaking compatibility, further extensions can be added simply by adding another "layer" of API like this and DSSI do which can be queried by the host as needed or it can simply fall back if the host or the plugin don't support it. seems to me like LV2 has lots of good ideas, but is shooting itself in the foot with complexity? - Jez From t_w_ at freenet.de Mon Jun 19 06:04:56 2006 From: t_w_ at freenet.de (Thorsten Wilms) Date: Mon Jun 19 06:05:05 2006 Subject: [linux-audio-dev] Re: LADSPA Extension for Extra GUI Data In-Reply-To: <4495CAFF.9030403@technetium.net.au> References: <4495CAFF.9030403@technetium.net.au> Message-ID: <20060619100456.GA7336@charly.SWORD> On Mon, Jun 19, 2006 at 07:51:59AM +1000, Jez Kabanov wrote: > > hmm, wouldn't that mean you need to code something (or include another > library) to parse all that description language making it difficult for > the host coder, and requires learning of a new language for the plugin > developer. seems much simpler and quicker for a plugin developer and host > developer to use a simple callback. > but the localisation is a good idea, but couldn't be handled via gettext > in the usual manner. A library to make hosting LV2s easy is in progress and almost finished, afaik. > seems to me like LV2 has lots of good ideas, but is shooting itself in the > foot with complexity? It's rather LADSPA which shot itself in the foot: With LADSPA, fixed data fields providing information about the plugin (like the number and type of ports) are inside the plugin binary, resulting in a number of problems: * There is lots of tedious, but quite complex code for providing data needed inside every plugin source. * The plugin has to be loaded and linked to retrieve any information about it. * There's no support for internationalisation. * Adding anything to the static data means breaking binary compatibility. LV2 separates the static data into RDF files in the easy to hand-write Turtle syntax. This provides a solution to all of the above problems. By using RDF, any kind of additional data can be added by plugin authors without compatibility problems. Thanks to RDF namespacing, anyone can create extensions under their own namespace. Successful extensions can then later be made part of the core spec. Strings can be internationalised easily. --- Thorsten Wilms From clemens at ladisch.de Mon Jun 19 08:09:01 2006 From: clemens at ladisch.de (Clemens Ladisch) Date: Mon Jun 19 08:09:55 2006 Subject: [linux-audio-dev] How to use the alsa sequencer? In-Reply-To: <20060616202401.37147.qmail@web33003.mail.mud.yahoo.com> References: <20060616202401.37147.qmail@web33003.mail.mud.yahoo.com> Message-ID: <20060619120901.GA21345@turing.informatik.uni-halle.de> Stephen Cameron wrote: > What I'm supposed to use for the "name" parameter for snd_seq_open > is not exactly clear. "default" > I've been using "hw:0,0" and it returns zero, "default" happens to be an alias for "hw" at the moment, and the ALSA library doesn't bother to check for superfluous parameters ... Regards, Clemens From fons.adriaensen at alcatelaleniaspace.com Mon Jun 19 08:15:02 2006 From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen) Date: Mon Jun 19 08:15:13 2006 Subject: [linux-audio-dev] Re: LADSPA Extension for Extra GUI Data In-Reply-To: <20060619100456.GA7336@charly.SWORD> References: <4495CAFF.9030403@technetium.net.au> <20060619100456.GA7336@charly.SWORD> Message-ID: <20060619121501.GA837@bth05w.ABSp.alcatel.be> On Mon, Jun 19, 2006 at 12:04:56PM +0200, Thorsten Wilms wrote: > It's rather LADSPA which shot itself in the foot: > With LADSPA, fixed data fields providing information about the plugin (like > the number and type of ports) are inside the plugin binary, resulting in a > number of problems: All of them fake. > * There is lots of tedious, but quite complex code for providing data needed > inside every plugin source. False. Its bl**dy simple, unless you want to make it difficult. > * The plugin has to be loaded and linked to retrieve any information about it. Loading and unloading it is still a lot simpler than what you need to do now. > * There's no support for internationalisation. It could easily be added without breaking anything. > * Adding anything to the static data means breaking binary compatibility. No it doesn't, unless you want it to. Reminds me of the description, in Colin Crouch's wonderful book "Postdemocrazia", of how privatisation was sold to the British public, and the story of the lamb and the woolf which he uses to illustrate the process: A lamb and a woolf are both are living near a river, not far from each other. Woolf: Lamb, you are pollution my water ! You'r pi**ing in it and I have to drink it ! Therefore I will kill you. Lamb: But you know that isn't true ! I'm living downstream from you, so you are polluting *my* water ! Woolf: That doesn't matter. I'll kill you anyway. -- FA Follie! Follie! Delirio vano e' questo! From mte_multi at hotmail.com Mon Jun 19 11:27:47 2006 From: mte_multi at hotmail.com (yvan chenard) Date: Mon Jun 19 11:27:58 2006 Subject: [linux-audio-dev] loopback with hda -intel Message-ID: Hi, maybe someone can help me, I find no ways to route (loop_back) the Line-in(where I have my tv-tuner pluged in) to the headphone jack, maybe someone know how to do it or know any links on documentation on how to do it. The sound card is onboard Intel D945GTP the chipset is STAC9220 (from sigmatel) (HDA_intel compatible) I am runing ALSA 1.0.11 not in the kernel(as module). kernel 2.6.16.5. The only way to get sound from LineIn to HeadPhone right now is "cat /dev/dsp > /dev/audio", but the quality is realy bad( with this command I know that the configuration of the input and output is OK). Thank You for your time. Yvan _________________________________________________________________ Mode, recettes et d?tente sur Sympatico / MSN Mieux vivre http://mieuxvivre.sympatico.msn.ca/Accueil/ From pedro.lopez.cabanillas at gmail.com Mon Jun 19 11:29:25 2006 From: pedro.lopez.cabanillas at gmail.com (Pedro Lopez-Cabanillas) Date: Mon Jun 19 11:30:08 2006 Subject: [linux-audio-dev] Re: How to use the alsa sequencer? In-Reply-To: <20060619080353.1C8B21D8B472@music.columbia.edu> References: <20060619080353.1C8B21D8B472@music.columbia.edu> Message-ID: <200606191729.26130.pedro.lopez.cabanillas@gmail.com> On Monday, 19 June 2006, Stephen Cameron wrote: > > http://www.alsa-project.org/alsa-doc/alsa-lib/seq.html > > Thanks, I'd found that already... it's slightly better than no > documentation. :-) ?But I'll take what I can get. ?It's a little > rough going at first when it kind of assumes you're aware of a big > picture that, in my case, I was almost totally unaware of. ?As you > slowly figure it out, and the bigger picture of how all the pieces > fit together -- sequencer ports, clients, channels, and how they're > named and accessed and what's what, the docs become a little clearer. > > Helps to understand it before you read it, heh. This document is the original proposal, by the ALSA sequencer author: http://www.alsa-project.org/~frank/alsa-sequencer/index.html A bit outdated, but a very intersting reading, if you want to get the big picture. Regards, Pedro From drobilla at connect.carleton.ca Mon Jun 19 13:49:14 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Mon Jun 19 13:49:23 2006 Subject: [linux-audio-dev] Re: LADSPA Extension for Extra GUI Data In-Reply-To: <20060619121501.GA837@bth05w.ABSp.alcatel.be> References: <4495CAFF.9030403@technetium.net.au> <20060619100456.GA7336@charly.SWORD> <20060619121501.GA837@bth05w.ABSp.alcatel.be> Message-ID: <1150739354.9290.5.camel@localhost.localdomain> On Mon, 2006-06-19 at 14:15 +0200, Alfons Adriaensen wrote: > On Mon, Jun 19, 2006 at 12:04:56PM +0200, Thorsten Wilms wrote: > > > It's rather LADSPA which shot itself in the foot: > > With LADSPA, fixed data fields providing information about the plugin (like > > the number and type of ports) are inside the plugin binary, resulting in a > > number of problems: > > All of them fake. Fake like the countless bug reports I get about your filter plugins not working because they take some silly arbitrary unit instead of Hz for cutoff frequency? -DR- From drobilla at connect.carleton.ca Mon Jun 19 13:55:27 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Mon Jun 19 13:55:37 2006 Subject: [linux-audio-dev] LADSPA Extension for Extra GUI Data In-Reply-To: <20060619180343.307d9kslps8400gc@webmail.technetium.net.au> References: <20060619180343.307d9kslps8400gc@webmail.technetium.net.au> Message-ID: <1150739727.9290.10.camel@localhost.localdomain> On Mon, 2006-06-19 at 18:03 +1000, jez@technetium.net.au wrote: > Hello, i'm new here, > i've been working on a very simple, backward-forwards compatible extension to > LADSPA/DSSI to allow hosts to display more meaningful gui's with a > "describe_value" function which takes the port index and a LADSPA_Data and > allows the plugin to return a meaningful description. eg. > for a waveform port it might return "SAW", "SIN", "SQR" etc > for a cutoff filter it might return the frequency in Hz > for a tuning port it might return "-4 semitones" > > also wanting to add a mechanism to group ports into logical sections. > without changing the underlying APIs, only by adding more layers on top this way > preserving backwards compatibility, the host simply dlsyms for > "ladgui_descriptor" and if it's there it makes use of the extra data, otherwise > it falls back to how it previously did things > > once the API is done i plan to make a reference gui > the idea behind this is that plugins will not need any of their own gui code as > a useful gui can be constructed on the fly as a part of the host or a separate > process that will work for any plugin so plugin developers never need worry > about constructing a gui and can instead just make nice useable algorithms and > test them quickly and easily. > > nicknamed LADGUI for now. > > API so far is at http://ftsf.technetium.net.au/code/ladgui/ladgui.h > > what i'd like to know is, if this is a stupid idea ^_^ The idea itself isn't stupid, but the implementation is.. let's say less than wise. (Consider my personal blatant bias, but...) I'd suggest taking a look at LV2. There is a data file you can add all this information to (whatever information you want to), without defining any APIs, changing any host code, etc, etc. You definitely shouldn't have to break binary compatibility of things just to add some hints for hosts, this is the problem LV2 is meant to solve... -DR- From drobilla at connect.carleton.ca Mon Jun 19 13:57:47 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Mon Jun 19 13:58:23 2006 Subject: [linux-audio-dev] Re: LADSPA Extension for Extra GUI Data In-Reply-To: <4495CAFF.9030403@technetium.net.au> References: <20060619180343.307d9kslps8400gc@webmail.technetium.net.au> <4495CAFF.9030403@technetium.net.au> Message-ID: <1150739867.9290.12.camel@localhost.localdomain> On Mon, 2006-06-19 at 07:51 +1000, Jez Kabanov wrote: > > This is handled in LADSPA+RDF and LV2 (aka LADSPA2) using scalePoints, eg. > > http://lv2plug.in/plugins/Amp-example.lv2/amp.ttl, search for > > lv2:scalePoint. That one's a silly example, but it makes the point. > > > > Things like "-4 semitones" will be handled by a units extensions, which > > will also allow hosts to use things like native gain control sliders for > > decibel ports, and BBT controls for time inputs. > > > > This idea is better in some ways, though though overall I prefer doing it > > though description, rather than programatically. > > > > - Steve > > hmm, wouldn't that mean you need to code something (or include another > library) to parse all that description language making it difficult for > the host coder, and requires learning of a new language for the plugin > developer. seems much simpler and quicker for a plugin developer and host > developer to use a simple callback. > but the localisation is a good idea, but couldn't be handled via gettext > in the usual manner. > > the advantage of this method is that it can achieve these goals without > breaking compatibility, further extensions can be added simply by adding > another "layer" of API like this and DSSI do which can be queried by the > host as needed or it can simply fall back if the host or the plugin don't > support it. > > seems to me like LV2 has lots of good ideas, but is shooting itself in the > foot with complexity? http://www.scs.carleton.ca/~drobilla/files/slv2_jack_host.c If that can be less complex, I want to hear how. :) -DR- From lars.luthman at gmail.com Mon Jun 19 14:05:48 2006 From: lars.luthman at gmail.com (Lars Luthman) Date: Mon Jun 19 14:05:52 2006 Subject: [linux-audio-dev] Re: LADSPA Extension for Extra GUI Data In-Reply-To: <1150739867.9290.12.camel@localhost.localdomain> References: <20060619180343.307d9kslps8400gc@webmail.technetium.net.au> <4495CAFF.9030403@technetium.net.au> <1150739867.9290.12.camel@localhost.localdomain> Message-ID: <1150740348.7619.8.camel@localhost> On Mon, 2006-06-19 at 13:57 -0400, Dave Robillard wrote: > On Mon, 2006-06-19 at 07:51 +1000, Jez Kabanov wrote: > > seems to me like LV2 has lots of good ideas, but is shooting itself in the > > foot with complexity? > > http://www.scs.carleton.ca/~drobilla/files/slv2_jack_host.c > > If that can be less complex, I want to hear how. :) And here's a simple demo host written using libslv2 (it could be a lot smaller if I didn't wrap things in C++ classes): http://cvs.savannah.nongnu.org/viewcvs/dino/extras/lv2/?root=dino -- Lars Luthman - please encrypt any email sent to me if possible PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E 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: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060619/3cf5b6d5/attachment.bin From fons.adriaensen at skynet.be Mon Jun 19 14:44:25 2006 From: fons.adriaensen at skynet.be (Fons Adriaensen) Date: Mon Jun 19 14:44:19 2006 Subject: [linux-audio-dev] Re: LADSPA Extension for Extra GUI Data In-Reply-To: <1150739354.9290.5.camel@localhost.localdomain> References: <4495CAFF.9030403@technetium.net.au> <20060619100456.GA7336@charly.SWORD> <20060619121501.GA837@bth05w.ABSp.alcatel.be> <1150739354.9290.5.camel@localhost.localdomain> Message-ID: <20060619184425.GB5899@linux-1.site> On Mon, Jun 19, 2006 at 01:49:14PM -0400, Dave Robillard wrote: > On Mon, 2006-06-19 at 14:15 +0200, Alfons Adriaensen wrote: > > All of them fake. > > Fake like the countless bug reports I get about your filter plugins not > working because they take some silly arbitrary unit instead of Hz for > cutoff frequency? If you mean the "Moog" filters, it's not arbitrary, but 1/octave as for everything in AMS, for which they were written. I never had a bug report for this, rather the opposite. And why then should *you* be getting them ? If OTOH you mean the 4-band parametric, it does take frequency control values in Hz (and gains in dB). All this doesn't change the fact that the rationale I commented on *is* fake, whatever the qualities of LV2 (which I do not even deny). -- FA Follie! Follie! Delirio vano e' questo! From S.W.Harris at ecs.soton.ac.uk Mon Jun 19 16:33:08 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Mon Jun 19 16:33:56 2006 Subject: [linux-audio-dev] Re: LADSPA Extension for Extra GUI Data In-Reply-To: <20060619184425.GB5899@linux-1.site> References: <4495CAFF.9030403@technetium.net.au> <20060619100456.GA7336@charly.SWORD> <20060619121501.GA837@bth05w.ABSp.alcatel.be> <1150739354.9290.5.camel@localhost.localdomain> <20060619184425.GB5899@linux-1.site> Message-ID: <20060619203308.GA9308@login.ecs.soton.ac.uk> On Mon, Jun 19, 2006 at 08:44:25 +0200, Fons Adriaensen wrote: > All this doesn't change the fact that the rationale I commented on > *is* fake, whatever the qualities of LV2 (which I do not even deny). I dont agree that it's fake per se, but I do think it was overstated. It can be /difficult/ to maintain binary compatibility, but it is rarely impossible, unless a really bad design decisision was taken.. - Steve From stefan at space.twc.de Mon Jun 19 17:11:07 2006 From: stefan at space.twc.de (Stefan Westerfeld) Date: Mon Jun 19 16:42:45 2006 Subject: [linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write In-Reply-To: <1149904994.7931.3.camel@localhost.localdomain> References: <20060604232101.GA29257@space.twc.de> <1149506048.11527.198.camel@localhost.localdomain> <44868A7C.40204@pp.inet.fi> <1149684578.12354.62.camel@localhost.localdomain> <20060607183244.GA5937@linux-1.site> <1149716547.2592.13.camel@mindpipe> <1149728686.4812.4.camel@DaveLap> <20060609223739.GA32237@space.twc.de> <1149904994.7931.3.camel@localhost.localdomain> Message-ID: <20060619211107.GA6877@space.twc.de> Hi! On Fri, Jun 09, 2006 at 10:03:14PM -0400, Dave Robillard wrote: > > > The big question is: who cares? :) sem_post() is. A mutex/cond pair is > > > just a big ugly slow non-RT-safe semaphore anyway. > > > > As far as I understand from the linux-2.6.16.16 and glibc-2.3.6 code, > > a semaphore has similar problems, as sem_post() is implemented in terms > > of futexes on newer linuxes, and futexes have a list of waiters, which > > is protected by a lock within the kernel. > > Well, sem_post is supposed to be async-signal safe (meaning it can't be > preempted, meaning it's realtime safe). If the Linux people have broken > that, they have done an evil stupid thing. POSIX semaphores are great, > especially since you can (or at least should, apparently) signal things > from signal callbacks and realtime threads with them (they work great > for event-driven systems). > > Are you sure? Link? The userspace code of sem_post() can be found in glibc-2.3.6/nptl/sysdeps/unix/sysv/linux/sem_post.c: int __new_sem_post (sem_t *sem) { int *futex = (int *) sem; int nr = atomic_increment_val (futex); int err = lll_futex_wake (futex, nr); if (__builtin_expect (err, 0) < 0) { __set_errno (-err); return -1; } return 0; } There are assembler versions, but they also need the futex_wake syscall, so it doesn't matter which version you read. And here is the kernel code from linux-2.6.16.16/kernel/futex.c: static int futex_wake(unsigned long uaddr, int nr_wake) { union futex_key key; struct futex_hash_bucket *bh; struct list_head *head; struct futex_q *this, *next; int ret; down_read(¤t->mm->mmap_sem); ret = get_futex_key(uaddr, &key); if (unlikely(ret != 0)) goto out; bh = hash_futex(&key); spin_lock(&bh->lock); head = &bh->chain; list_for_each_entry_safe(this, next, head, list) { if (match_futex (&this->key, &key)) { wake_futex(this); if (++ret >= nr_wake) break; } } spin_unlock(&bh->lock); out: up_read(¤t->mm->mmap_sem); return ret; } The spin_lock(&bh->lock) is the one I was referring to in my earlier mail. Cu... Stefan -- Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan From rlrevell at joe-job.com Mon Jun 19 16:48:27 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Mon Jun 19 16:48:44 2006 Subject: [linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write In-Reply-To: <20060619211107.GA6877@space.twc.de> References: <20060604232101.GA29257@space.twc.de> <1149506048.11527.198.camel@localhost.localdomain> <44868A7C.40204@pp.inet.fi> <1149684578.12354.62.camel@localhost.localdomain> <20060607183244.GA5937@linux-1.site> <1149716547.2592.13.camel@mindpipe> <1149728686.4812.4.camel@DaveLap> <20060609223739.GA32237@space.twc.de> <1149904994.7931.3.camel@localhost.localdomain> <20060619211107.GA6877@space.twc.de> Message-ID: <1150750107.2754.35.camel@mindpipe> On Mon, 2006-06-19 at 23:11 +0200, Stefan Westerfeld wrote: > The spin_lock(&bh->lock) is the one I was referring to in my earlier > mail. Taking a spinlock should be realtime safe - they are not supposed to be held for long and cannot sleep. Worst case scenario should be that you spin for a few hundred microseconds. It's a bug if a spinlock is held for much longer or is heavily contended. Lee From jez at technetium.net.au Mon Jun 19 05:31:10 2006 From: jez at technetium.net.au (Jez Kabanov) Date: Mon Jun 19 17:29:11 2006 Subject: [linux-audio-dev] LADSPA Extension for Extra GUI Data References: 20060619180343.307d9kslps8400gc@webmail.technetium.net.au Message-ID: <44966EDE.8030509@technetium.net.au> > > The idea itself isn't stupid, but the implementation is.. let's say less > than wise. > > (Consider my personal blatant bias, but...) I'd suggest taking a look at > LV2. There is a data file you can add all this information to (whatever > information you want to), without defining any APIs, changing any host > code, etc, etc. > > You definitely shouldn't have to break binary compatibility of things > just to add some hints for hosts, this is the problem LV2 is meant to > solve... > > -DR- while i'm no expert in this area, i'm having some trouble understanding your rationale. how is it breaking binary compatibility? is binary compatibility even an issue? shouldn't the host just look for the plugin and load it and check for the existence of a symbol, if it exists then call it, otherwise it doesn't and everything is just as it was. the host never need know anything about the binary structure of the plugin except to know that there's a function called "ladspa_descriptor", adding ladgui certainly doesn't stop old hosts from loading and using the plugin, i've modified nekobee to use ladgui and it runs exactly as it used to in an unmodified rosegarden, so how is binary compatibilty an issue? whereas LV2 breaks compatibilty with old plugins (this seems like more of an issue to me), adds a lot of complexity and requires the host to use an additional liblv2 library. - Jez From S.W.Harris at ecs.soton.ac.uk Mon Jun 19 17:34:05 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Mon Jun 19 17:34:37 2006 Subject: [linux-audio-dev] LADSPA Extension for Extra GUI Data In-Reply-To: <1150739727.9290.10.camel@localhost.localdomain> References: <20060619180343.307d9kslps8400gc@webmail.technetium.net.au> <1150739727.9290.10.camel@localhost.localdomain> Message-ID: <20060619213404.GB9308@login.ecs.soton.ac.uk> On Mon, Jun 19, 2006 at 01:55:27PM -0400, Dave Robillard wrote: > > API so far is at http://ftsf.technetium.net.au/code/ladgui/ladgui.h > > > > what i'd like to know is, if this is a stupid idea ^_^ > > The idea itself isn't stupid, but the implementation is.. let's say less > than wise. > > (Consider my personal blatant bias, but...) I'd suggest taking a look at > LV2. There is a data file you can add all this information to (whatever > information you want to), without defining any APIs, changing any host > code, etc, etc. The provisional LV2 spec is at http://lv2pluig.in/ it could do with some human language text explaining the technical parts, not just C and RDFS, but I think theres enough there to make sense of it. FWIW, I think the "not changing any code" thing is a blind, someone, somewhere has to change some code if you want new behaviour*. To me the critical thing is not that, but that a display function or whatever only solves half the problem. You would also like the app to be able to "understand" the control value and it's units. But I said that allready :) * though not if you don't which can be more of an advantage than you'd think. - Steve From fons.adriaensen at skynet.be Mon Jun 19 17:58:43 2006 From: fons.adriaensen at skynet.be (Fons Adriaensen) Date: Mon Jun 19 17:58:41 2006 Subject: [linux-audio-dev] LADSPA Extension for Extra GUI Data In-Reply-To: <20060619213404.GB9308@login.ecs.soton.ac.uk> References: <20060619180343.307d9kslps8400gc@webmail.technetium.net.au> <1150739727.9290.10.camel@localhost.localdomain> <20060619213404.GB9308@login.ecs.soton.ac.uk> Message-ID: <20060619215843.GD5899@linux-1.site> On Mon, Jun 19, 2006 at 10:34:05PM +0100, Steve Harris wrote: > FWIW, I think the "not changing any code" thing is a blind, someone, > somewhere has to change some code if you want new behaviour*. To me the > critical thing is not that, but that a display function or whatever only > solves half the problem. You would also like the app to be able to > "understand" the control value and it's units. But I said that allready :) > > * though not if you don't which can be more of an advantage than you'd > think. What worries me is that LV2 is *not* going to solve the problem that DR raised w.r.t. my "Moog" filter plugins. IIRC the control law is : f = pow (2, v) * frequency_of_middle_C or some such, where v is the parameter value. So the relation v->f is *exponential* (not logarithmic). Now in a sophisticated soft-synth, the control port could be connected to either: 1. another module: In that case the host needs to know the relation above. 2. a GUI widget: This may want to display the frequency either in musical terms, or in Hz. The relation widget_pos->v should be linear, while the relation displayed_frequency->v is logarithmic, using the inverse relation of the one above. 3. a MIDI controller: Since we are controlling a frequency, it would make sense to use MIDI note numbers. So the host needs to know that v = (n - 60) / 12.0f; 4. an OSC path: Here we would probably want the plain frequency as the OSC parameter value. So how are we going to tell this to the host ? I'm sure LV2 can _represent_ all of this, but representation is not the same as meaning. For the host to understand it, either - it has a degree in music science and DSP, - the meaning of the tags used is predefined by some standard. The latter is missing, and once it is defined the need for an 'open' representation format no longer exists. -- FA Follie! Follie! Delirio vano e' questo! From S.W.Harris at ecs.soton.ac.uk Mon Jun 19 18:25:52 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Mon Jun 19 18:26:15 2006 Subject: [linux-audio-dev] LADSPA Extension for Extra GUI Data In-Reply-To: <20060619215843.GD5899@linux-1.site> References: <20060619180343.307d9kslps8400gc@webmail.technetium.net.au> <1150739727.9290.10.camel@localhost.localdomain> <20060619213404.GB9308@login.ecs.soton.ac.uk> <20060619215843.GD5899@linux-1.site> Message-ID: <20060619222552.GC9308@login.ecs.soton.ac.uk> On Mon, Jun 19, 2006 at 11:58:43PM +0200, Fons Adriaensen wrote: > On Mon, Jun 19, 2006 at 10:34:05PM +0100, Steve Harris wrote: > > > FWIW, I think the "not changing any code" thing is a blind, someone, > > somewhere has to change some code if you want new behaviour*. To me the > > critical thing is not that, but that a display function or whatever only > > solves half the problem. You would also like the app to be able to > > "understand" the control value and it's units. But I said that allready :) > > > > * though not if you don't which can be more of an advantage than you'd > > think. > > What worries me is that LV2 is *not* going to solve the problem that > DR raised w.r.t. my "Moog" filter plugins. This particualr one I'm not worried about, as it's a know one, its all the subtle things noones realised yet, something like a plugin that does its delay in 24ths of a beat or something. > IIRC the control law is : > > f = pow (2, v) * frequency_of_middle_C > > or some such, where v is the parameter value. So the relation v->f is > *exponential* (not logarithmic). Sure, the LADSPA LOG hint couldn't deal with this meaningfully anyway. > So how are we going to tell this to the host ? > I'm sure LV2 can _represent_ all of this, but representation is > not the same as meaning. For the host to understand it, either > > - it has a degree in music science and DSP, > > - the meaning of the tags used is predefined by some standard. Or both if you really mess up :) > The latter is missing, and once it is defined the need for > an 'open' representation format no longer exists. That's more-or-less true, but you can apply that argument repeatedly forever. I have many plugins that I would prefer to work this way, but LADSPA makes it tricky if you want to interoperate with most hosts. Consequenctly, I have given it some though. The representation I was thinking of was something like: :somePort lv2:unit unit:octavePitch ; lv2:baseFreq 264.0 . It's not beyond the realms of the possible to describe the mathematical relationship between the octave pitch unit and Hz, but it's probably excessive. Some organic chemists use an RDF schema that expresses conversions bewteen crazy chemical units, but I think its overkill for crazy DSP units. We only really care about frequency[/time] and ampltiude anyway ;) - Steve From fons.adriaensen at skynet.be Mon Jun 19 18:57:43 2006 From: fons.adriaensen at skynet.be (Fons Adriaensen) Date: Mon Jun 19 18:57:51 2006 Subject: [linux-audio-dev] LADSPA Extension for Extra GUI Data In-Reply-To: <20060619222552.GC9308@login.ecs.soton.ac.uk> References: <20060619180343.307d9kslps8400gc@webmail.technetium.net.au> <1150739727.9290.10.camel@localhost.localdomain> <20060619213404.GB9308@login.ecs.soton.ac.uk> <20060619215843.GD5899@linux-1.site> <20060619222552.GC9308@login.ecs.soton.ac.uk> Message-ID: <20060619225743.GF5899@linux-1.site> On Mon, Jun 19, 2006 at 11:25:52PM +0100, Steve Harris wrote: > On Mon, Jun 19, 2006 at 11:58:43PM +0200, Fons Adriaensen wrote: > > > What worries me is that LV2 is *not* going to solve the problem that > > DR raised w.r.t. my "Moog" filter plugins. > > This particualr one I'm not worried about, as it's a know one, its all the > subtle things noones realised yet, something like a plugin that does its > delay in 24ths of a beat or something. Aaarrrrrggghhh :-) > > So the relation v->f is *exponential* (not logarithmic). > > Sure, the LADSPA LOG hint couldn't deal with this meaningfully anyway. Not a problem. AFAIK, the hints do not describe the v->f mapping, but rather the one between the widget and v. It's plain linear in this case. > > - it has a degree in music science and DSP, > > - the meaning of the tags used is predefined by some standard. > > Or both if you really mess up :) I'd love a plugin host with a degree... > :somePort lv2:unit unit:octavePitch ; > lv2:baseFreq 264.0 . > > It's not beyond the realms of the possible to describe the mathematical > relationship between the octave pitch unit and Hz, but it's probably > excessive. A well-designed set of tags like the ones you show above would probably solve 99.9% of all cases. But you can't expect anyone to dream that up in a day. Which leads me to my main gripe with LV2: it was defined much too fast. In a normal RFC process, you present the problem, give interested parties at least a month to consider it and write something that exceeds the quality of a whim, and then take at least as much time to study the results and comment on them before anything is decided. -- FA Follie! Follie! Delirio vano e' questo! From loki.davison at gmail.com Mon Jun 19 19:05:33 2006 From: loki.davison at gmail.com (Loki Davison) Date: Mon Jun 19 19:05:43 2006 Subject: [linux-audio-dev] Re: LADSPA Extension for Extra GUI Data In-Reply-To: <20060619184425.GB5899@linux-1.site> References: <4495CAFF.9030403@technetium.net.au> <20060619100456.GA7336@charly.SWORD> <20060619121501.GA837@bth05w.ABSp.alcatel.be> <1150739354.9290.5.camel@localhost.localdomain> <20060619184425.GB5899@linux-1.site> Message-ID: On 6/20/06, Fons Adriaensen wrote: > On Mon, Jun 19, 2006 at 01:49:14PM -0400, Dave Robillard wrote: > > On Mon, 2006-06-19 at 14:15 +0200, Alfons Adriaensen wrote: > > > > All of them fake. > > > > Fake like the countless bug reports I get about your filter plugins not > > working because they take some silly arbitrary unit instead of Hz for > > cutoff frequency? > > If you mean the "Moog" filters, it's not arbitrary, but 1/octave as for > everything in AMS, for which they were written. > > I never had a bug report for this, rather the opposite. > And why then should *you* be getting them ? > > If OTOH you mean the 4-band parametric, it does take frequency control > values in Hz (and gains in dB). > > All this doesn't change the fact that the rationale I commented on > *is* fake, whatever the qualities of LV2 (which I do not even deny). > > -- > FA > > Follie! Follie! Delirio vano e' questo! > Because people actually use them in Om, because people actually use Om unlike certain other modulars. volt per octave is pretty damn obscure in a computer program.... If i wanted to have a cutoff at concert A what the hell is that in volts per octave? Loki From paul at linuxaudiosystems.com Mon Jun 19 20:44:39 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Mon Jun 19 20:44:20 2006 Subject: [linux-audio-dev] LADSPA Extension for Extra GUI Data In-Reply-To: <20060619225743.GF5899@linux-1.site> References: <20060619180343.307d9kslps8400gc@webmail.technetium.net.au> <1150739727.9290.10.camel@localhost.localdomain> <20060619213404.GB9308@login.ecs.soton.ac.uk> <20060619215843.GD5899@linux-1.site> <20060619222552.GC9308@login.ecs.soton.ac.uk> <20060619225743.GF5899@linux-1.site> Message-ID: <1150764279.8703.120.camel@localhost.localdomain> On Tue, 2006-06-20 at 00:57 +0200, Fons Adriaensen wrote: > > It's not beyond the realms of the possible to describe the mathematical > > relationship between the octave pitch unit and Hz, but it's probably > > excessive. > > A well-designed set of tags like the ones you show above would > probably solve 99.9% of all cases. But you can't expect anyone > to dream that up in a day. Which leads me to my main gripe with > LV2: it was defined much too fast. In a normal RFC process, you > present the problem, give interested parties at least a month > to consider it and write something that exceeds the quality of > a whim, and then take at least as much time to study the results > and comment on them before anything is decided. two points: 1) i think the LV2 scheme is designed to leave the "tag" namespace open, separating the basic design (plugin vs. metadata) from any specific metadata definition. this means that agreement is only needed on the infrastructure for the plugin/metadata design, not on what the metadata looks like. you can still have your month or two to figure out the correct metadata namespace. 2) LADSPA "v2" has floundered for more than a year since the previous LAC BoF. i commend rather than criticize swh for stepping up doing something, because otherwise nothing would ever have been done. From loki.davison at gmail.com Mon Jun 19 23:48:48 2006 From: loki.davison at gmail.com (Loki Davison) Date: Mon Jun 19 23:48:58 2006 Subject: [linux-audio-dev] Re: LADSPA Extension for Extra GUI Data In-Reply-To: <44966EDE.8030509@technetium.net.au> References: <44966EDE.8030509@technetium.net.au> Message-ID: On 6/19/06, Jez Kabanov wrote: > > > > The idea itself isn't stupid, but the implementation is.. let's say less > > than wise. > > > > (Consider my personal blatant bias, but...) I'd suggest taking a look at > > LV2. There is a data file you can add all this information to (whatever > > information you want to), without defining any APIs, changing any host > > code, etc, etc. > > > > You definitely shouldn't have to break binary compatibility of things > > just to add some hints for hosts, this is the problem LV2 is meant to > > solve... > > > > -DR- > while i'm no expert in this area, i'm having some trouble understanding > your rationale. > > how is it breaking binary compatibility? > is binary compatibility even an issue? > > shouldn't the host just look for the plugin and load it and check for > the existence of a symbol, > if it exists then call it, otherwise it doesn't and everything is just > as it was. > > the host never need know anything about the binary structure of the > plugin except to know that there's a function called "ladspa_descriptor", > adding ladgui certainly doesn't stop old hosts from loading and using > the plugin, > > i've modified nekobee to use ladgui and it runs exactly as it used to in > an unmodified rosegarden, > so how is binary compatibilty an issue? > > whereas LV2 breaks compatibilty with old plugins (this seems like more > of an issue to me), adds a lot of complexity and requires the host to > use an additional liblv2 library. > > - Jez > Noticed you mentioned dssi gui's here. I'm interested in adding some kind of dssi wrapper to khagan so gui's built in khagan can be used for dssi's easily. It's on the todo for the next release http://openfacts.berlios.de/index-en.phtml?title=Khagan_Todo however since i wrote the todo i've got a full time job programming python and my interest in touching a computer has waned and i spend my limited spare time with my lovely washburn bass and 70's pawn shop acoustic. If you'd like to add this kind of thing to khagan for dssi's and maybe lv2 plugins that could be quite interesting. Loki From S.W.Harris at ecs.soton.ac.uk Tue Jun 20 03:31:59 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Tue Jun 20 03:32:19 2006 Subject: [linux-audio-dev] LADSPA Extension for Extra GUI Data In-Reply-To: <20060619225743.GF5899@linux-1.site> References: <20060619180343.307d9kslps8400gc@webmail.technetium.net.au> <1150739727.9290.10.camel@localhost.localdomain> <20060619213404.GB9308@login.ecs.soton.ac.uk> <20060619215843.GD5899@linux-1.site> <20060619222552.GC9308@login.ecs.soton.ac.uk> <20060619225743.GF5899@linux-1.site> Message-ID: <20060620073159.GA18633@login.ecs.soton.ac.uk> On Tue, Jun 20, 2006 at 12:57:43 +0200, Fons Adriaensen wrote: > > :somePort lv2:unit unit:octavePitch ; > > lv2:baseFreq 264.0 . > > > > It's not beyond the realms of the possible to describe the mathematical > > relationship between the octave pitch unit and Hz, but it's probably > > excessive. > > A well-designed set of tags like the ones you show above would > probably solve 99.9% of all cases. But you can't expect anyone > to dream that up in a day. Which leads me to my main gripe with > LV2: it was defined much too fast. In a normal RFC process, you > present the problem, give interested parties at least a month > to consider it and write something that exceeds the quality of > a whim, and then take at least as much time to study the results > and comment on them before anything is decided. I hope you dont have that impression, LV2 is not finalised, I tried to make sure I had "draft" and "provisional" in the text, but I guess I wasn't sufficiently clear, it is very much still up for discussion. My feeling is that it is somewhere around the Last Call stage in W3C speak. l-a-d fortunatly not having a formal standards process ;) Also, the units stuff I alluded to obove is not, and will not be part of the LV2 1.0 spec, it will come soon after and live as an extension. My plan was to crib from the scientific communities work on representing unit values in RDF, write an early draft and post it here. It is somewhat orthogonal to LV2 itsself, so if someone else with more time feels motivated to work on it, please do. The situation with LV2 is that I have ported most of my LADSPA plugins (to verify there were no blatant problems) to a version of the draft, and we now have 2-3 partial host implementations of the current draft. That doesn't cover the requirements of reference implementations to my satisfaction. So, just to be clear, nothing has been decided. The purpose of the website it to encourage discussion. - Steve From S.W.Harris at ecs.soton.ac.uk Tue Jun 20 03:35:15 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Tue Jun 20 03:35:34 2006 Subject: [linux-audio-dev] Re: LADSPA Extension for Extra GUI Data In-Reply-To: References: <4495CAFF.9030403@technetium.net.au> <20060619100456.GA7336@charly.SWORD> <20060619121501.GA837@bth05w.ABSp.alcatel.be> <1150739354.9290.5.camel@localhost.localdomain> <20060619184425.GB5899@linux-1.site> Message-ID: <20060620073515.GB18633@login.ecs.soton.ac.uk> On Tue, Jun 20, 2006 at 09:05:33 +1000, Loki Davison wrote: > Because people actually use them in Om, because people actually use Om > unlike certain other modulars. volt per octave is pretty damn obscure > in a computer program.... If i wanted to have a cutoff at concert A > what the hell is that in volts per octave?S Zero typically. I have to take issue with this, 1.0f per octave is the natural way to preresent things like filter cutoff in a modular. It's what makes the great modular systems so easy to work with. - Steve From S.W.Harris at ecs.soton.ac.uk Tue Jun 20 03:51:14 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Tue Jun 20 03:51:44 2006 Subject: [linux-audio-dev] LV2 update Message-ID: <20060620075114.GC18633@login.ecs.soton.ac.uk> There's been little news on the LV2 front here recently, all the disucssion seems to have taken place on IRC, so a quick update: Theres now a website: http://lv2plug.in/ as of a couple od days ago, thanks to Thorsten Wilms which has links to drafts of the C header file and RDF/Turtle schema. Please read the formal specs and comment. Following discussion on the l-a-u list and hard work by a lot of people there's a logo. Please don't discuss the logo except to praise it ;) choosing one was quite involved. Various generic forms (black on white etc.) will be availble on the website in due course. TODO list: * Finalise the technical aspect of the spec, get interested parties to confirm that it meets thier needs (or at least doesn't prevent them). * Write human language specification to go with .h and .ttl explaining how to use the spec, conventions etc. * Make sure there's a reasonable set of reference implementations and examples. * Test the extension mechanisms. * Publish final spec, have tea and cakes etc. - Steve From S.W.Harris at ecs.soton.ac.uk Tue Jun 20 04:12:16 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Tue Jun 20 04:12:43 2006 Subject: [linux-audio-dev] LV2 plugin porting experience Message-ID: <20060620081216.GD18633@login.ecs.soton.ac.uk> I thought it might be of interest to other plugin developers to learn what my experiences were of porting my LADSPA plugins to the LV2 draft. As some of you may know the primary source for my plugins is a wierd XML format, so porting that was fiddly, but didn't involve much manual effort, "just" coding a handful of XSLT sheets. However I ported a couple by hand to get a feel for it, and basically it comes down to deleting the constants and runAdding method from the ladspa .c file, sedding some struct names and replacing occurances of LADSPA_Data with float (except the last argument to connectPort, which is a void *). It may be possible to do it automatically with a cpp/m4 hack, or a perl script or something, but I doubt its worth the effort. Writing the turtle is a little more involved, but I'm sure some enterprising person can write a program to generate .ttl from existing LADSPA .so's, then it will be a case of adding any additional data you want to express by hand. Writing the Makefile was pretty tricky, as the plugin data and code all ends up in a plugin directory, but it wasn't too bad once I figured out how best to layout the source. I decided not to use automake/autoonf/ ibtool as I felt it caused more probems than it solved with LADSPA. The Makefile would have been less critical if I didn't have quite so many plugins; I didn't want to recurse into every plugin directory, which is the obvious thing to do. - Steve From drobilla at connect.carleton.ca Tue Jun 20 09:39:30 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Tue Jun 20 09:39:37 2006 Subject: [linux-audio-dev] LV2 update In-Reply-To: <20060620075114.GC18633@login.ecs.soton.ac.uk> References: <20060620075114.GC18633@login.ecs.soton.ac.uk> Message-ID: <1150810770.2424.43.camel@localhost.localdomain> On Tue, 2006-06-20 at 08:51 +0100, Steve Harris wrote: > There's been little news on the LV2 front here recently, all the disucssion > seems to have taken place on IRC, so a quick update: > > Theres now a website: http://lv2plug.in/ as of a couple od days ago, > thanks to Thorsten Wilms which has links to drafts of the C header file > and RDF/Turtle schema. Please read the formal specs and comment. > > Following discussion on the l-a-u list and hard work by a lot of people > there's a logo. Please don't discuss the logo except to praise it ;) > choosing one was quite involved. Various generic forms (black on white > etc.) will be availble on the website in due course. > > TODO list: > * Finalise the technical aspect of the spec, get interested parties to > confirm that it meets thier needs (or at least doesn't prevent them). > > * Write human language specification to go with .h and .ttl explaining > how to use the spec, conventions etc. > > * Make sure there's a reasonable set of reference implementations and > examples. > > * Test the extension mechanisms. > > * Publish final spec, have tea and cakes etc. * Figure out what to do about plugin latency I think plugins with latency should be required to provide latency information to a control output port (like the convention for LADSPA). The best way to do this IMO is to list the port in the RDF file, since reserving a port symbol is pretty dirty and un LV2ey.. there's probably other 'special' ports that will come along due to extensions, and reserving their symbols is a bad slippery slope to step on to. I can make the plugin validating host check the latency primitively (eg run a single sample through the buffer) and fail if it isn't reported correctly, so we're sure the LADSPA latency woes are gone. -DR- From S.W.Harris at ecs.soton.ac.uk Tue Jun 20 10:26:24 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Tue Jun 20 10:26:52 2006 Subject: [linux-audio-dev] LV2 update In-Reply-To: <1150810770.2424.43.camel@localhost.localdomain> References: <20060620075114.GC18633@login.ecs.soton.ac.uk> <1150810770.2424.43.camel@localhost.localdomain> Message-ID: <20060620142624.GH18633@login.ecs.soton.ac.uk> On Tue, Jun 20, 2006 at 09:39:30 -0400, Dave Robillard wrote: > I can make the plugin validating host check the latency primitively (eg > run a single sample through the buffer) and fail if it isn't reported > correctly, so we're sure the LADSPA latency woes are gone. What if it's a delay line? I think you have to reply on the concience of plugin programmers to get it right. - Steve From paul at linuxaudiosystems.com Tue Jun 20 10:58:42 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Tue Jun 20 11:00:38 2006 Subject: [linux-audio-dev] LV2 update In-Reply-To: <20060620142624.GH18633@login.ecs.soton.ac.uk> References: <20060620075114.GC18633@login.ecs.soton.ac.uk> <1150810770.2424.43.camel@localhost.localdomain> <20060620142624.GH18633@login.ecs.soton.ac.uk> Message-ID: <1150815522.8703.140.camel@localhost.localdomain> On Tue, 2006-06-20 at 15:26 +0100, Steve Harris wrote: > On Tue, Jun 20, 2006 at 09:39:30 -0400, Dave Robillard wrote: > > I can make the plugin validating host check the latency primitively (eg > > run a single sample through the buffer) and fail if it isn't reported > > correctly, so we're sure the LADSPA latency woes are gone. > > What if it's a delay line? I think you have to reply on the concience of > plugin programmers to get it right. we could require plugins that delay the signal but are not latent to have the required port (which would report zero) From drobilla at connect.carleton.ca Tue Jun 20 13:46:01 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Tue Jun 20 13:46:09 2006 Subject: [linux-audio-dev] LV2 update In-Reply-To: <20060620142624.GH18633@login.ecs.soton.ac.uk> References: <20060620075114.GC18633@login.ecs.soton.ac.uk> <1150810770.2424.43.camel@localhost.localdomain> <20060620142624.GH18633@login.ecs.soton.ac.uk> Message-ID: <1150825561.15826.0.camel@localhost.localdomain> On Tue, 2006-06-20 at 15:26 +0100, Steve Harris wrote: > On Tue, Jun 20, 2006 at 09:39:30 -0400, Dave Robillard wrote: > > I can make the plugin validating host check the latency primitively (eg > > run a single sample through the buffer) and fail if it isn't reported > > correctly, so we're sure the LADSPA latency woes are gone. > > What if it's a delay line? I think you have to reply on the concience of > plugin programmers to get it right. Hmm. Good point. :/ -DR- From drobilla at connect.carleton.ca Tue Jun 20 13:50:46 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Tue Jun 20 13:50:56 2006 Subject: [linux-audio-dev] LV2 update In-Reply-To: <1150815522.8703.140.camel@localhost.localdomain> References: <20060620075114.GC18633@login.ecs.soton.ac.uk> <1150810770.2424.43.camel@localhost.localdomain> <20060620142624.GH18633@login.ecs.soton.ac.uk> <1150815522.8703.140.camel@localhost.localdomain> Message-ID: <1150825846.15826.4.camel@localhost.localdomain> On Tue, 2006-06-20 at 10:58 -0400, Paul Davis wrote: > On Tue, 2006-06-20 at 15:26 +0100, Steve Harris wrote: > > On Tue, Jun 20, 2006 at 09:39:30 -0400, Dave Robillard wrote: > > > I can make the plugin validating host check the latency primitively (eg > > > run a single sample through the buffer) and fail if it isn't reported > > > correctly, so we're sure the LADSPA latency woes are gone. > > > > What if it's a delay line? I think you have to reply on the concience of > > plugin programmers to get it right. > > we could require plugins that delay the signal but are not latent to > have the required port (which would report zero) Hm, yeah, that would at least allow the verifier to check that plugins without a latency port aren't latent, which is nice (and that's the main problem anyway) -DR- From v2 at iki.fi Tue Jun 20 14:37:37 2006 From: v2 at iki.fi (Sampo Savolainen) Date: Tue Jun 20 14:38:35 2006 Subject: [linux-audio-dev] LV2 update In-Reply-To: <1150815522.8703.140.camel@localhost.localdomain> References: <20060620075114.GC18633@login.ecs.soton.ac.uk> <1150810770.2424.43.camel@localhost.localdomain> <20060620142624.GH18633@login.ecs.soton.ac.uk> <1150815522.8703.140.camel@localhost.localdomain> Message-ID: <1150828658.6275.11.camel@puppeli> On Tue, 2006-06-20 at 10:58 -0400, Paul Davis wrote: > On Tue, 2006-06-20 at 15:26 +0100, Steve Harris wrote: > > On Tue, Jun 20, 2006 at 09:39:30 -0400, Dave Robillard wrote: > > > I can make the plugin validating host check the latency primitively (eg > > > run a single sample through the buffer) and fail if it isn't reported > > > correctly, so we're sure the LADSPA latency woes are gone. > > > > What if it's a delay line? I think you have to reply on the concience of > > plugin programmers to get it right. > > we could require plugins that delay the signal but are not latent to > have the required port (which would report zero) Still a bit hackish for my tastes. The plugin reporting it's latency all by it self is the-right-thing-to-do (tm). If hosts need to measure the latency, it gets hairy. The hosts would need to take measurements every time a plugin parameter changes, etc.. Let's just standardize an extension for latency ports after the release of LV2. And let's do it FAST, so that most plugin writers will be porting their plugins with the extension in place. -- Sampo Savolainen From drobilla at connect.carleton.ca Tue Jun 20 14:46:37 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Tue Jun 20 14:46:50 2006 Subject: [linux-audio-dev] LV2 update In-Reply-To: <1150828658.6275.11.camel@puppeli> References: <20060620075114.GC18633@login.ecs.soton.ac.uk> <1150810770.2424.43.camel@localhost.localdomain> <20060620142624.GH18633@login.ecs.soton.ac.uk> <1150815522.8703.140.camel@localhost.localdomain> <1150828658.6275.11.camel@puppeli> Message-ID: <1150829197.15826.7.camel@localhost.localdomain> On Tue, 2006-06-20 at 21:37 +0300, Sampo Savolainen wrote: > On Tue, 2006-06-20 at 10:58 -0400, Paul Davis wrote: > > On Tue, 2006-06-20 at 15:26 +0100, Steve Harris wrote: > > > On Tue, Jun 20, 2006 at 09:39:30 -0400, Dave Robillard wrote: > > > > I can make the plugin validating host check the latency primitively (eg > > > > run a single sample through the buffer) and fail if it isn't reported > > > > correctly, so we're sure the LADSPA latency woes are gone. > > > > > > What if it's a delay line? I think you have to reply on the concience of > > > plugin programmers to get it right. > > > > we could require plugins that delay the signal but are not latent to > > have the required port (which would report zero) > > Still a bit hackish for my tastes. The plugin reporting it's latency all > by it self is the-right-thing-to-do (tm). If hosts need to measure the > latency, it gets hairy. The hosts would need to take measurements every > time a plugin parameter changes, etc.. > > Let's just standardize an extension for latency ports after the release > of LV2. And let's do it FAST, so that most plugin writers will be > porting their plugins with the extension in place. I think this should be included in the spec, since it's devastating when plugins don't adhere. I believe Steve agrees with me (Steve?) -DR- From S.W.Harris at ecs.soton.ac.uk Tue Jun 20 15:27:56 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Tue Jun 20 15:28:42 2006 Subject: [linux-audio-dev] LV2 update In-Reply-To: <1150829197.15826.7.camel@localhost.localdomain> References: <20060620075114.GC18633@login.ecs.soton.ac.uk> <1150810770.2424.43.camel@localhost.localdomain> <20060620142624.GH18633@login.ecs.soton.ac.uk> <1150815522.8703.140.camel@localhost.localdomain> <1150828658.6275.11.camel@puppeli> <1150829197.15826.7.camel@localhost.localdomain> Message-ID: <20060620192756.GL18633@login.ecs.soton.ac.uk> On Tue, Jun 20, 2006 at 02:46:37 -0400, Dave Robillard wrote: > > Let's just standardize an extension for latency ports after the release > > of LV2. And let's do it FAST, so that most plugin writers will be > > porting their plugins with the extension in place. > > I think this should be included in the spec, since it's devastating when > plugins don't adhere. I believe Steve agrees with me (Steve?) It doesnt need to be an extension really, as it was common practice in LADSPA, just pick a URI for the hint and put it in the schema. lv2:latencySamples anyone? - Steve From paul at linuxaudiosystems.com Tue Jun 20 17:44:18 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Tue Jun 20 17:44:00 2006 Subject: [linux-audio-dev] libsndfile stuff In-Reply-To: <200606160910.00114.ben@glw.com> References: <20060616130602.430E31D1B3E7@music.columbia.edu> <200606160910.00114.ben@glw.com> Message-ID: <1150839858.8703.159.camel@localhost.localdomain> svn should once again have working (better than before the libsndfile changes) support for tape tracks. what a total pain this has been, but i think the end result is worth it - a standard library shared with other apps. let me know if you have issues with it. it may not work with existing sessions that have old BWF files in them - still checking on this here. i will check SMPTE offset tonight, and then i'm back where i was 10 days ago, finally :( From pieterp at joow.be Tue Jun 20 18:21:44 2006 From: pieterp at joow.be (Pieter Palmers) Date: Tue Jun 20 18:21:56 2006 Subject: [linux-audio-dev] [REQUEST] test the influence of linux1394 kernel drivers on scheduling latency Message-ID: <449874F8.6070904@joow.be> Hi all, This weekend I've discovered a (serious) kernel scheduling latency issue with the current ieee1394 kernel drivers. Before I submit something about this to lkml, I'd like some more tests. I've been able to reproduce this on two different machines, so I suspect that this is a more general problem. The problem summary is that running ieee1394 ISO traffic can cause scheduling latency spikes up to 1ms, even for RT threads with higher priority. I've written a simple test suite that can be used to reproduce this behavior. The only thing needed is a firewire host controller (no firewire devices). I'd appreciate it if some people would try the test so that I can have an overview of the problem. Of course, this applies mostly to people running an -RT patched kernel. You can find the test suite here: http://freebob.sourceforge.net/old/ieee1394-latencytest.tar.gz see the README for details. Please report the maximum latency you get and the kernel/hardware you're running. Many thanks, Pieter Palmers FreeBoB developer From rlrevell at joe-job.com Tue Jun 20 18:28:18 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Tue Jun 20 18:28:30 2006 Subject: [linux-audio-dev] Re: [Jackit-devel] [REQUEST] test the influence of linux1394 kernel drivers on scheduling latency In-Reply-To: <449874F8.6070904@joow.be> References: <449874F8.6070904@joow.be> Message-ID: <1150842498.2754.186.camel@mindpipe> On Wed, 2006-06-21 at 00:21 +0200, Pieter Palmers wrote: > Hi all, > > This weekend I've discovered a (serious) kernel scheduling latency issue > with the current ieee1394 kernel drivers. Before I submit something > about this to lkml, I'd like some more tests. I've been able to > reproduce this on two different machines, so I suspect that this is a > more general problem. > > The problem summary is that running ieee1394 ISO traffic can cause > scheduling latency spikes up to 1ms, even for RT threads with higher > priority. > Latency tracer output please? Use 2.6.16 with this patch: http://people.redhat.com/mingo/latency-tracing-patches/latency-tracing-v2.6.16.patch Lee From kjetil at ccrma.stanford.edu Tue Jun 20 19:40:38 2006 From: kjetil at ccrma.stanford.edu (Kjetil S. Matheussen) Date: Tue Jun 20 19:41:14 2006 Subject: [linux-audio-dev] [ANN] jack_capture V0.2.4 Message-ID: jack_capture is a small program to capture whatever sound is going out to your speakers into a file without every having to patch jack connections, fiddle around with fileformats, or set options on the argument line. This is the program I always wanted to have for jack, but no one made. So here it is. http://ccrma.stanford.edu/~kjetil/src/ Changes 0.2.3 -> 0.2.4: *Give message to stderr during recording (not only after) if any overruns occur. *Do not delete file after recording if any overruns have occured. (stupid jackreq code #$!@$) *Increased default buffer size from 0.5M to 2M. From pieterp at joow.be Wed Jun 21 04:42:18 2006 From: pieterp at joow.be (Pieter Palmers) Date: Wed Jun 21 04:42:29 2006 Subject: [linux-audio-dev] Re: [Jackit-devel] [REQUEST] test the influence of linux1394 kernel drivers on scheduling latency In-Reply-To: <1150842498.2754.186.camel@mindpipe> References: <449874F8.6070904@joow.be> <1150842498.2754.186.camel@mindpipe> Message-ID: <4499066A.7050503@joow.be> Lee Revell wrote: >On Wed, 2006-06-21 at 00:21 +0200, Pieter Palmers wrote: > > >>Hi all, >> >>This weekend I've discovered a (serious) kernel scheduling latency issue >>with the current ieee1394 kernel drivers. Before I submit something >>about this to lkml, I'd like some more tests. I've been able to >>reproduce this on two different machines, so I suspect that this is a >>more general problem. >> >>The problem summary is that running ieee1394 ISO traffic can cause >>scheduling latency spikes up to 1ms, even for RT threads with higher >>priority. >> >> >> > >Latency tracer output please? > >Use 2.6.16 with this patch: > >http://people.redhat.com/mingo/latency-tracing-patches/latency-tracing-v2.6.16.patch > > > I've tried using the latency tracer, but I was unable to get any other results than the system timer (or what extactly was it called) at about 20us. Nothing from the ieee1394 stack showed up. I probably need some usage explanation because the stuff I find googling around seems to be out of date. Or at least it does not provide the info I need to get usefull output. But that could be me. Greets, Pieter BTW: should you have a firewire card, try it for yourself. After all, that saves you the explanation, and I'm pretty confident that it will be present on other machines too. From pieterp at joow.be Wed Jun 21 13:20:30 2006 From: pieterp at joow.be (Pieter Palmers) Date: Wed Jun 21 13:20:53 2006 Subject: [linux-audio-dev] Re: [Freebob-devel] [REQUEST] test the influence of linux1394 kernel drivers on scheduling latency In-Reply-To: <44996FDF.7010407@s5r6.in-berlin.de> References: <449874F8.6070904@joow.be> <44996FDF.7010407@s5r6.in-berlin.de> Message-ID: <44997FDE.8000009@joow.be> Stefan Richter wrote: > Pieter Palmers wrote: >> The problem summary is that running ieee1394 ISO traffic can cause >> scheduling latency spikes up to 1ms, even for RT threads with higher >> priority. > > Do your patches to lower CPU utilization show any influence? Not tested yet. I have a hunch that the removal of the dummy read might improve the situation. But I haven't investigated this yet. > > Do you get 1394 bus resets while ieee1394stress is running? (You could > e.g. print raw1394_get_generation(handle) when it starts and when it exits.) As far as I can tell there are no bus resets, but I'll check. Pieter From nettings at folkwang-hochschule.de Thu Jun 22 13:14:30 2006 From: nettings at folkwang-hochschule.de (Joern Nettingsmeier) Date: Thu Jun 22 13:15:07 2006 Subject: [linux-audio-dev] [admin] linux-audio-* maintainer wanted... Message-ID: <449ACFF6.9050501@folkwang-hochschule.de> hi guys! due to post-academic stress syndrome (read: i'm getting a real job ;), i would like to resign from being maintainer of the linux-audio-* lists. lately i haven't been able to keep up with the lists as much as i would have liked to, and i feel it's time for new people to take over. if you'd like to volunteer, holler now :) i'm leaving on a four-week iceland trip in about a week, and if no-one has expressed their interest by then, i would be very glad if somebody could at least step forward to tend to the lists for a month or so... as an added bonus, there is also the job of cleaning up the old lad.linuxaudio.org page, throwing out all the obsolete stuff (i.e. everything except the subscription information and the contrib/ section) and maybe linking to all the excellent documentation efforts elsewhere :) i hope to stay in contact with the linux audio community in the future, and i will definitely do some volunteer work for next year's linux audio conference in berlin, but my life has moved away from studio work to live audio engineering, systems administration and (ugh) web content management... all the best, j?rn -- j?rn nettingsmeier home://germany/45128 essen/lortzingstr. 11/ http://spunk.dnsalias.org phone://+49/201/491621 if you are a free (as in "free speech") software developer and you happen to be travelling near my home, drop me a line and come round for a free (as in "free beer") beer. :-D From jwoithe at physics.adelaide.edu.au Thu Jun 22 20:14:15 2006 From: jwoithe at physics.adelaide.edu.au (Jonathan Woithe) Date: Thu Jun 22 20:05:50 2006 Subject: [linux-audio-dev] Re: [Freebob-devel] [REQUEST] test the influence of linux1394 kernel drivers on scheduling latency In-Reply-To: from "freebob-devel-request@lists.sourceforge.net" at Jun 22, 2006 12:08:49 PM Message-ID: <200606230014.k5N0EFJ8005690@auster.physics.adelaide.edu.au> Pieter Palmers wrote: > This weekend I've discovered a (serious) kernel scheduling latency issue > with the current ieee1394 kernel drivers. Before I submit something > about this to lkml, I'd like some more tests. I've been able to > reproduce this on two different machines, so I suspect that this is a > more general problem. I ran the tests quickly on my firewire development machine overnight. First I started the latency monitor and left it run for about 10 minutes while I did other things, including accessing a USB stick. I then started the ieee1394 stress tester; almost immediately the monitor noted maximum latencies of the order of 1 ms (compared to tens of microseconds when the stress tester wasn't running). The output is blow. > ./latency_histogram -p 80 -n 128 -t 1 -s 1 Histogram size: 128 bins, bin size: 1us, last bin: 128us aquiring RT scheduling with priority 80 ... getting cpu speed... 67547857.763 Hz (67.548 MHz) Sleeping for 1us between timer reads... Running, press CTRL-C to stop... (+) New maximum: 62 cycles, 0.917868 (-) New minimum: 62 cycles, 0.917868 (-) New minimum: 58 cycles, 0.858650 (+) New maximum: 298 cycles, 4.411687 (+) New maximum: 43475 cycles, 643.617747 (+) New maximum: 48239 cycles, 714.145520 (+) New maximum: 52924 cycles, 783.503752 (+) New maximum: 131949 cycles, 1953.415021 (+) New maximum: 170136 cycles, 2518.747532 # of iterations: 243335 max. difference: 170136 cycles, 2518.747532us min. difference: 58 cycles, 0.858650us avg. difference: 66 cycles, 0.989601us Histogram --------- =< 1us: 33 1us : 243285 2us : 9 3us : 1 4us : 3 5us : 2 6us : 1 7us : 1 ... >= 128us: 33 The "New maximum: 298 cycles" appeared very soon after the stress tester was started, with the ones below it following soon after. Despite what the log says, this was running a 2.0 GHz "Dothan" Centrino CPU. Kernel was 2.6.16-rt25, distro was Slackware 10.2. Both the stress tester and the monitor were run with RT privilege access. The firewire interface used has a TI OHCI chipset. I apologise that the run was particularly short and that therefore the statistics aren't particularly good, but it does seem to confirm the observations you made on your machine. The large latencies only occur when the stress tester is running. Regards jonathan From rlrevell at joe-job.com Thu Jun 22 20:12:05 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Thu Jun 22 20:12:04 2006 Subject: [linux-audio-dev] Re: [Freebob-devel] [REQUEST] test the influence of linux1394 kernel drivers on scheduling latency In-Reply-To: <200606230014.k5N0EFJ8005690@auster.physics.adelaide.edu.au> References: <200606230014.k5N0EFJ8005690@auster.physics.adelaide.edu.au> Message-ID: <1151021526.17952.19.camel@mindpipe> On Fri, 2006-06-23 at 09:44 +0930, Jonathan Woithe wrote: > > Despite what the log says, this was running a 2.0 GHz "Dothan" > Centrino CPU. Kernel was 2.6.16-rt25, distro was Slackware 10.2. Both > the stress tester and the monitor were run with RT privilege access. > The firewire interface used has a TI OHCI chipset. > > I apologise that the run was particularly short and that therefore the > statistics aren't particularly good, but it does seem to confirm the > observations you made on your machine. The large latencies only occur > when the stress tester is running. What if you run the latency tester at RT priority 99? Testing at 80 is not particularly useful. If anything else is running at 99, what happens if you lower those other processes to 98? What processes do you have running at RT priority 80 or above? Does the Firewire stack do a lot of its work in timers? Lee From jwoithe at physics.adelaide.edu.au Thu Jun 22 20:49:56 2006 From: jwoithe at physics.adelaide.edu.au (Jonathan Woithe) Date: Thu Jun 22 20:41:05 2006 Subject: [linux-audio-dev] Re: [Freebob-devel] [REQUEST] test the In-Reply-To: <1151021526.17952.19.camel@mindpipe> from "Lee Revell" at Jun 22, 2006 08:12:05 PM Message-ID: <200606230049.k5N0nuhw007732@auster.physics.adelaide.edu.au> Hi Lee > On Fri, 2006-06-23 at 09:44 +0930, Jonathan Woithe wrote: > > Despite what the log says, this was running a 2.0 GHz "Dothan" > > Centrino CPU. Kernel was 2.6.16-rt25, distro was Slackware 10.2. Both > > the stress tester and the monitor were run with RT privilege access. > > The firewire interface used has a TI OHCI chipset. > > > > I apologise that the run was particularly short and that therefore the > > statistics aren't particularly good, but it does seem to confirm the > > observations you made on your machine. The large latencies only occur > > when the stress tester is running. > > What if you run the latency tester at RT priority 99? Testing at 80 is > not particularly useful. Ok, I'll try at the higher number. I didn't have much time on this overnight so I just ran it according to the instructions given in the README file. I haven't had time to analyse the details. > If anything else is running at 99, what happens if you lower those other > processes to 98? > What processes do you have running at RT priority 80 or above? At the time I ran the tests there were no other usermode processes running at any RT priority. Only the latency analyser itself and the ieee stress tester had elevated RT priorities. Also the system hasn't had priorities of kernel things tuned on startup - the system is a bog-standard 2.6.16-rt25 running as booted. The system as a whole was unloaded too; I had X running with fvwm2 and some xterms running shells but that was about it. > Does the Firewire stack do a lot of its work in timers? Don't know - I'll have to check. Regards jonathan From rlrevell at joe-job.com Thu Jun 22 20:55:26 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Thu Jun 22 20:55:41 2006 Subject: [linux-audio-dev] Re: [Freebob-devel] [REQUEST] test the In-Reply-To: <200606230049.k5N0nuhw007732@auster.physics.adelaide.edu.au> References: <200606230049.k5N0nuhw007732@auster.physics.adelaide.edu.au> Message-ID: <1151024127.17952.28.camel@mindpipe> On Fri, 2006-06-23 at 10:19 +0930, Jonathan Woithe wrote: > At the time I ran the tests there were no other usermode processes > running at any RT priority. Only the latency analyser itself and the > ieee stress tester had elevated RT priorities. Also the system hasn't > had priorities of kernel things tuned on startup - the system is a > bog-standard 2.6.16-rt25 running as booted. In the -rt kernel IRQ handlers run as user processes with realtime priority. You have to use ps to check. Lee From jwoithe at physics.adelaide.edu.au Thu Jun 22 21:16:33 2006 From: jwoithe at physics.adelaide.edu.au (Jonathan Woithe) Date: Thu Jun 22 21:07:51 2006 Subject: [linux-audio-dev] Re: [Freebob-devel] [REQUEST] test the In-Reply-To: <1151024127.17952.28.camel@mindpipe> from "Lee Revell" at Jun 22, 2006 08:55:26 PM Message-ID: <200606230116.k5N1GXqV009862@auster.physics.adelaide.edu.au> > On Fri, 2006-06-23 at 10:19 +0930, Jonathan Woithe wrote: > > At the time I ran the tests there were no other usermode processes > > running at any RT priority. Only the latency analyser itself and the > > ieee stress tester had elevated RT priorities. Also the system hasn't > > had priorities of kernel things tuned on startup - the system is a > > bog-standard 2.6.16-rt25 running as booted. > > In the -rt kernel IRQ handlers run as user processes with realtime > priority. You have to use ps to check. I see. I'll check. Note that in this case I haven't done any tuning, so the priorities of the kernel IRQ handlers will be whatever an RT kernel sets them to by default. Regards jonathan From smcameron at yahoo.com Fri Jun 23 00:34:29 2006 From: smcameron at yahoo.com (Stephen Cameron) Date: Fri Jun 23 00:34:54 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] Recording ADAT inputs on RME hammerfall 9636/52 Message-ID: <20060623043429.58173.qmail@web33010.mail.mud.yahoo.com> Well, mixed results tonight. I was able to get some sound to go across the ADAT cables from the PC to the AW4416. But not good sound. On the bright side, I think I more or less understand connecting things up with jack, ecasound, and so on. On the bad side, so far it's not working too well. I monitored things with "jackmeter" and this meter registered peaks near 0dB for the stuff I was playing with ecasound, and pretty high levels for the most part. On the AW4416, the levels were registering between -30dB and -48dB. I guess I don't understand how ADAT works. I was under the impression the signal going across the cables was digital -- and so to get a reduction in levels like that, I would expect some digital numbers would have to go from being big numbers to being small numbers, which seems unlikely thing to happen to numbers encoded as pulses going down a cable. So I conclude I don't know how ADAT works, except it's not as I imagined it did. Oh, and besides a drastic loss of signal level, the signal was distorted strangely. Hard to describe. This may be due to xruns... I haven't got things to work without xruns yet, but that shouldn't cause a drop in levels, right? Just kind of choppiness, dropouts, crappy sound, right? Transfering from the AW4416 to the PC did not work at all. on capture_1 and capture_2, I got very low level white noise apparently. Are those the s/pdif ports? On the other channels input was dead silence. I tried both ADAT ports on the RME board, with similar results on each. I tried swapping the two ADAT cables in case one of the cables was bad... this did not seem to make a difference. Maybe the RME just transmits harder than the Yamaha, so it's signal makes it across (just barely, crossing the finish line at -48dB) while the yamaha's signal dies. I did change the RME's frequency to 44.1kHz in qjackctl's setup window. Maybe there are some clues in here: [root@zuul R15]# cat /proc/asound/R15/rme9652 RME Digi9636 (Rev 1.5) (Card #2) Buffers: capture f6a00000 playback f6400000 IRQ: 10 Registers bus: 0xea000000 VM: 0xf88a2000 Control register: 48029 Latency: 1024 samples (2 periods of 4096 bytes) Hardware pointer (frames): 1024 Passthru: no Clock mode: autosync Pref. sync source: ADAT1 ADAT1 Input source: ADAT1 optical IEC958 input: Internal IEC958 output: Coaxial only IEC958 quality: Consumer IEC958 emphasis: off IEC958 Dolby: off IEC958 sample rate: error flag set ADAT Sample rate: 44100Hz ADAT1: No Lock ADAT2: Sync ADAT3: No Lock Timecode signal: no Punch Status: 1: off 2: off 3: off 4: off 5: off 6: off 7: off 8: off 9: off 10: off 11: off 12: off 13: off 14: off 15: off 16: off 17: off 18: off __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From wingo at pobox.com Fri Jun 23 03:41:45 2006 From: wingo at pobox.com (Andy Wingo) Date: Fri Jun 23 03:41:56 2006 Subject: [linux-audio-dev] [admin] linux-audio-* maintainer wanted... In-Reply-To: <449ACFF6.9050501@folkwang-hochschule.de> References: <449ACFF6.9050501@folkwang-hochschule.de> Message-ID: <1151048505.14993.1.camel@localhost.localdomain> Hi Joern, On Thu, 2006-06-22 at 19:14 +0200, Joern Nettingsmeier wrote: > due to post-academic stress syndrome (read: i'm getting a real job ;), i > would like to resign from being maintainer of the linux-audio-* lists. Thanks for all the fish! -- Andy Wingo http://wingolog.org/ From pieterp at joow.be Fri Jun 23 06:12:16 2006 From: pieterp at joow.be (Pieter Palmers) Date: Fri Jun 23 06:12:53 2006 Subject: [linux-audio-dev] Re: [Freebob-devel] [REQUEST] test the influence of linux1394 kernel drivers on scheduling latency In-Reply-To: <1151021526.17952.19.camel@mindpipe> References: <200606230014.k5N0EFJ8005690@auster.physics.adelaide.edu.au> <1151021526.17952.19.camel@mindpipe> Message-ID: <449BBE80.1020004@joow.be> Lee Revell wrote: >On Fri, 2006-06-23 at 09:44 +0930, Jonathan Woithe wrote: > > >>Despite what the log says, this was running a 2.0 GHz "Dothan" >>Centrino CPU. Kernel was 2.6.16-rt25, distro was Slackware 10.2. Both >>the stress tester and the monitor were run with RT privilege access. >>The firewire interface used has a TI OHCI chipset. >> >>I apologise that the run was particularly short and that therefore the >>statistics aren't particularly good, but it does seem to confirm the >>observations you made on your machine. The large latencies only occur >>when the stress tester is running. >> >> > >What if you run the latency tester at RT priority 99? Testing at 80 is >not particularly useful. > > Why not? If the 1394 test user thread has a lower priority, and the ohci1394 irq priority is also lower, there is no reason for the latency tester to be preempted by them. >If anything else is running at 99, what happens if you lower those other >processes to 98? > > I'll have to recheck, but if I remember correcly I have done this experiment. The only thing at 99 is the system timer. I tried giving it a lower priority than the latency test thread, which didn't change anything. Pieter From rlrevell at joe-job.com Fri Jun 23 16:39:40 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Fri Jun 23 16:40:02 2006 Subject: [linux-audio-dev] Re: [Freebob-devel] [REQUEST] test the influence of linux1394 kernel drivers on scheduling latency In-Reply-To: <449BBE80.1020004@joow.be> References: <200606230014.k5N0EFJ8005690@auster.physics.adelaide.edu.au> <1151021526.17952.19.camel@mindpipe> <449BBE80.1020004@joow.be> Message-ID: <1151095180.2931.25.camel@mindpipe> On Fri, 2006-06-23 at 12:12 +0200, Pieter Palmers wrote: > Lee Revell wrote: > > >On Fri, 2006-06-23 at 09:44 +0930, Jonathan Woithe wrote: > > > > > >>Despite what the log says, this was running a 2.0 GHz "Dothan" > >>Centrino CPU. Kernel was 2.6.16-rt25, distro was Slackware 10.2. Both > >>the stress tester and the monitor were run with RT privilege access. > >>The firewire interface used has a TI OHCI chipset. > >> > >>I apologise that the run was particularly short and that therefore the > >>statistics aren't particularly good, but it does seem to confirm the > >>observations you made on your machine. The large latencies only occur > >>when the stress tester is running. > >> > >> > > > >What if you run the latency tester at RT priority 99? Testing at 80 is > >not particularly useful. > > > > > Why not? > > If the 1394 test user thread has a lower priority, and the ohci1394 irq > priority is also lower, there is no reason for the latency tester to be > preempted by them. > Because as you stated below the system timer runs at a higher priority by default. I wanted to rule out preemption by the system timer thread. > >If anything else is running at 99, what happens if you lower those other > >processes to 98? > > > > > I'll have to recheck, but if I remember correcly I have done this > experiment. The only thing at 99 is the system timer. I tried giving it > a lower priority than the latency test thread, which didn't change anything. > OK thanks, that answers my question. > Pieter > From t_w_ at freenet.de Sat Jun 24 05:23:59 2006 From: t_w_ at freenet.de (Thorsten Wilms) Date: Sat Jun 24 05:24:22 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] [admin] linux-audio-* maintainer wanted... In-Reply-To: <449ACFF6.9050501@folkwang-hochschule.de> References: <449ACFF6.9050501@folkwang-hochschule.de> Message-ID: <20060624092359.GA7310@charly.SWORD> On Thu, Jun 22, 2006 at 07:14:30PM +0200, Joern Nettingsmeier wrote: > > due to post-academic stress syndrome (read: i'm getting a real job ;), i > would like to resign from being maintainer of the linux-audio-* lists. > lately i haven't been able to keep up with the lists as much as i would > have liked to, and i feel it's time for new people to take over. Congrats and thank you for your work :) What exactly does maintainership of the lists encompass? > as an added bonus, there is also the job of cleaning up the old > lad.linuxaudio.org page, throwing out all the obsolete stuff (i.e. > everything except the subscription information and the contrib/ section) > and maybe linking to all the excellent documentation efforts elsewhere :) Now this I might be interested in. --- Thorsten Wilms From pieterp at joow.be Sat Jun 24 07:50:53 2006 From: pieterp at joow.be (Pieter Palmers) Date: Sat Jun 24 07:51:19 2006 Subject: [linux-audio-dev] Re: [Freebob-devel] [REQUEST] test the influence of linux1394 kernel drivers on scheduling latency In-Reply-To: <1151095180.2931.25.camel@mindpipe> References: <200606230014.k5N0EFJ8005690@auster.physics.adelaide.edu.au> <1151021526.17952.19.camel@mindpipe> <449BBE80.1020004@joow.be> <1151095180.2931.25.camel@mindpipe> Message-ID: <449D271D.9090704@joow.be> Lee Revell wrote: > On Fri, 2006-06-23 at 12:12 +0200, Pieter Palmers wrote: > >>> If anything else is running at 99, what happens if you lower those other >>> processes to 98? >>> >>> >> I'll have to recheck, but if I remember correcly I have done this >> experiment. The only thing at 99 is the system timer. I tried giving it >> a lower priority than the latency test thread, which didn't change anything. >> > > OK thanks, that answers my question. > I found one problem at this point, which is in the latency test application itself. Apparently it doesn't acquire the RT priority correctly. My mistake. When trying with rtc_wakeup I get about 40us max. Which is more what I'd expect. I'm going to investigate this further anyway, because I'm not really convinced yet. In one of my previous sessions, rtc_wakeup also showed large latency values. TBC Greets, Pieter From nettings at folkwang-hochschule.de Sat Jun 24 11:10:16 2006 From: nettings at folkwang-hochschule.de (Joern Nettingsmeier) Date: Sat Jun 24 11:10:29 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] [admin] linux-audio-* maintainer wanted... In-Reply-To: <20060624092359.GA7310@charly.SWORD> References: <449ACFF6.9050501@folkwang-hochschule.de> <20060624092359.GA7310@charly.SWORD> Message-ID: <449D55D8.5020905@folkwang-hochschule.de> Thorsten Wilms wrote: > On Thu, Jun 22, 2006 at 07:14:30PM +0200, Joern Nettingsmeier wrote: >> due to post-academic stress syndrome (read: i'm getting a real job ;), i >> would like to resign from being maintainer of the linux-audio-* lists. >> lately i haven't been able to keep up with the lists as much as i would >> have liked to, and i feel it's time for new people to take over. > > Congrats and thank you for your work :) > > > What exactly does maintainership of the lists encompass? basically moderation of linux-audio-announce and helping people who have problems with their accounts. the latter has become a great problem lately, because the admin adresses are being drowned in spam :( but basically it's all about handling mailman, which has a neat and friendly web interface. but some extra effort spent on spam filtering would certainly ease the job in the long run... >> as an added bonus, there is also the job of cleaning up the old >> lad.linuxaudio.org page, throwing out all the obsolete stuff (i.e. >> everything except the subscription information and the contrib/ section) >> and maybe linking to all the excellent documentation efforts elsewhere :) > > Now this I might be interested in. cool. the old page plain sucks, if you want to take over, that's great. send me an ssh key in a private mail if you want. however i need to talk to ico bukvic before giving somebody access, since he owns the box... -- j?rn nettingsmeier home://germany/45128 essen/lortzingstr. 11/ http://spunk.dnsalias.org phone://+49/201/491621 if you are a free (as in "free speech") software developer and you happen to be travelling near my home, drop me a line and come round for a free (as in "free beer") beer. :-D From a at gaydenko.com Sat Jun 24 11:15:38 2006 From: a at gaydenko.com (Andrew Gaydenko) Date: Sat Jun 24 11:16:03 2006 Subject: [linux-audio-dev] IR FFT smoothing Message-ID: <200606241915.38534@goldspace.net> Hi! Trying to understand some magic with Ipmulse Response, FFT and so on, I'm playing with scipy, matplotlib (and python as new language for me as a bonus). Concrete IR was got with help of DRC (rec_imp, saying more strictly). Currently I have got this frequency response graph: http://gaydenko.com/mix/needSmooth.png And the question is: what is common way to smooth the result? Some offtopic apps has something like "1/24, ..., 1/3 octave smoothing". What does it mean? Andrew From fons.adriaensen at skynet.be Sat Jun 24 11:30:00 2006 From: fons.adriaensen at skynet.be (Fons Adriaensen) Date: Sat Jun 24 11:29:54 2006 Subject: [linux-audio-dev] IR FFT smoothing In-Reply-To: <200606241915.38534@goldspace.net> References: <200606241915.38534@goldspace.net> Message-ID: <20060624153000.GA5950@linux-1.site> On Sat, Jun 24, 2006 at 07:15:38PM +0400, Andrew Gaydenko wrote: > And the question is: what is common way to smooth the result? Some offtopic apps has > something like "1/24, ..., 1/3 octave smoothing". What does it mean? Lowpass (linear phase) filtering of the response. Or windowing the IR which is equivalent. If you window the IR, you get a constant resolution over the entire range of the FR. To get a variable rate such as 1/3 oct, you need frequency dependent windowing - the window gets shorter as frequency rises. It's not easy to do right (one of the reasons why aliki still isn't finished). IIRC DRC can produce such plots if you ask it nicely. -- FA Follie! Follie! Delirio vano e' questo! From t_w_ at freenet.de Sat Jun 24 11:51:19 2006 From: t_w_ at freenet.de (Thorsten Wilms) Date: Sat Jun 24 11:51:27 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] [admin] linux-audio-* maintainer wanted... In-Reply-To: <449D55D8.5020905@folkwang-hochschule.de> References: <449ACFF6.9050501@folkwang-hochschule.de> <20060624092359.GA7310@charly.SWORD> <449D55D8.5020905@folkwang-hochschule.de> Message-ID: <20060624155119.GB7310@charly.SWORD> On Sat, Jun 24, 2006 at 05:10:16PM +0200, Joern Nettingsmeier wrote: > >What exactly does maintainership of the lists encompass? > > basically moderation of linux-audio-announce and helping people who have > problems with their accounts. the latter has become a great problem > lately, because the admin adresses are being drowned in spam :( > > but basically it's all about handling mailman, which has a neat and > friendly web interface. but some extra effort spent on spam filtering > would certainly ease the job in the long run... If it was only moderation ... not knowing that much about email and leaving all spam handling to my free-mail providers, I'm not the right one for this job > >>as an added bonus, there is also the job of cleaning up the old > >>lad.linuxaudio.org page, throwing out all the obsolete stuff (i.e. > >>everything except the subscription information and the contrib/ section) > >>and maybe linking to all the excellent documentation efforts elsewhere :) > > > >Now this I might be interested in. > > cool. the old page plain sucks, if you want to take over, that's great. > send me an ssh key in a private mail if you want. however i need to talk > to ico bukvic before giving somebody access, since he owns the box... Ok. Will do. I will most likely work a bit more for the theming of http://lau.linuxaudio.org and then take care of this one. --- Thorsten Wilms From a at gaydenko.com Sat Jun 24 12:03:54 2006 From: a at gaydenko.com (Andrew Gaydenko) Date: Sat Jun 24 12:04:19 2006 Subject: [linux-audio-dev] IR FFT smoothing In-Reply-To: <20060624153000.GA5950@linux-1.site> References: <200606241915.38534@goldspace.net> <20060624153000.GA5950@linux-1.site> Message-ID: <200606242003.54834@goldspace.net> ======= On Saturday 24 June 2006 19:30, Fons Adriaensen wrote: ======= ..... Lowpass (linear phase) filtering of the response. Or windowing the IR which is equivalent. If you window the IR, you get a constant resolution over the entire range of the FR. To get a variable rate such as 1/3 oct, you need frequency dependent windowing - the window gets shorter as frequency rises. It's not easy to do right (one of the reasons why aliki still isn't finished). IIRC DRC can produce such plots if you ask it nicely. -- FA Follie! Follie! Delirio vano e' questo! ======================================================================== Hi, Fons! I have got from DRC mailing list a suggestion to play with octave scripts. After some thinking I have decided to play with python as such funny games potentially may be more usefull for me (probably it's my mistake :-)). Thanks, I'll think what does windowing mean. Happy aliking! Andrew From pshirkey at boosthardware.com Sat Jun 24 13:21:50 2006 From: pshirkey at boosthardware.com (Patrick Shirkey) Date: Sat Jun 24 13:23:07 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] [admin] linux-audio-* maintainer wanted... In-Reply-To: <20060624155119.GB7310@charly.SWORD> References: <449ACFF6.9050501@folkwang-hochschule.de> <20060624092359.GA7310@charly.SWORD> <449D55D8.5020905@folkwang-hochschule.de> <20060624155119.GB7310@charly.SWORD> Message-ID: <449D74AE.9080309@boosthardware.com> Thorsten Wilms wrote: > > Ok. Will do. > I will most likely work a bit more for the theming of > http://lau.linuxaudio.org and then take care of this one. > Hi Thorsten, What can I do to assist you with this procedure? I will endeavor to facilitate your every need for css compliant markup. Feel free to shoot me a mail with any questions you may have or details that need resolving. Warmest regards. -- Patrick Shirkey A member of your Boost Hardware team. We are passionate about serving your needs. Working hard to create the kind of website that is indicative of the current status of Linux Audio Software. ====================================================================== This message is subject to the following terms and conditions if you received it unneccesarily then please refrain from taking advantage of the information for political purposes or industrial espionage. if you have received this email in error please be aware that it is confidential information intended purely for the coercion of the individual it is in reply to. ====================================================================== Heheheh. Hook, line and sinker... Cheers. -- Patrick Shirkey - Boost Hardware Ltd. Http://www.boosthardware.com Http://lau.linuxaudio.org - The Linux Audio Users guide ======================================== "Anything your mind can see you can manifest physically, then it will become reality" - Macka B From t_w_ at freenet.de Sat Jun 24 14:31:16 2006 From: t_w_ at freenet.de (Thorsten Wilms) Date: Sat Jun 24 14:31:37 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] [admin] linux-audio-* maintainer wanted... In-Reply-To: <449D74AE.9080309@boosthardware.com> References: <449ACFF6.9050501@folkwang-hochschule.de> <20060624092359.GA7310@charly.SWORD> <449D55D8.5020905@folkwang-hochschule.de> <20060624155119.GB7310@charly.SWORD> <449D74AE.9080309@boosthardware.com> Message-ID: <20060624183116.GD7310@charly.SWORD> On Sun, Jun 25, 2006 at 12:21:50AM +0700, Patrick Shirkey wrote: > What can I do to assist you with this procedure? I will endeavor to > facilitate your every need for css compliant markup. > > Feel free to shoot me a mail with any questions you may have or details > that need resolving. Heh, thanks :) I would like create a new mockup for http://lau.linuxaudio.org/faq first. Then there's the question wether the whole lau.linuxaudio.org should be the wiki. Even if not, the theming should be consistent. If lad.linuxaudio.org is changed to be all about the list ... perhaps the mainpages of both should be similar and both feature the mailing lists first, followed by links to the wiki with FAQ and all. A bit soon for technical details, but I'm for XHTML strict (or transitional if it must be). -- Thorsten Wilms From pshirkey at boosthardware.com Sat Jun 24 14:49:50 2006 From: pshirkey at boosthardware.com (Patrick Shirkey) Date: Sat Jun 24 14:51:07 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] [admin] linux-audio-* maintainer wanted... In-Reply-To: <449D55D8.5020905@folkwang-hochschule.de> References: <449ACFF6.9050501@folkwang-hochschule.de> <20060624092359.GA7310@charly.SWORD> <449D55D8.5020905@folkwang-hochschule.de> Message-ID: <449D894E.7050702@boosthardware.com> Joern Nettingsmeier wrote: > Thorsten Wilms wrote: >> On Thu, Jun 22, 2006 at 07:14:30PM +0200, Joern Nettingsmeier wrote: >>> due to post-academic stress syndrome (read: i'm getting a real job ;), i >>> would like to resign from being maintainer of the linux-audio-* lists. >>> lately i haven't been able to keep up with the lists as much as i would >>> have liked to, and i feel it's time for new people to take over. >> >> Congrats and thank you for your work :) >> >> >> What exactly does maintainership of the lists encompass? > > basically moderation of linux-audio-announce and helping people who have > problems with their accounts. the latter has become a great problem > lately, because the admin adresses are being drowned in spam :( > > but basically it's all about handling mailman, which has a neat and > friendly web interface. but some extra effort spent on spam filtering > would certainly ease the job in the long run... > >>> as an added bonus, there is also the job of cleaning up the old >>> lad.linuxaudio.org page, throwing out all the obsolete stuff (i.e. >>> everything except the subscription information and the contrib/ >>> section) and maybe linking to all the excellent documentation efforts >>> elsewhere :) >> >> Now this I might be interested in. > > cool. the old page plain sucks, if you want to take over, that's great. > send me an ssh key in a private mail if you want. however i need to talk > to ico bukvic before giving somebody access, since he owns the box... > > Hi Joern, Congrats and hope you don't disappear for too long. How long do we have to get last minute updates in before you disappear? For example on the lau mailing list there is this info: http://music.columbia.edu/mailman/listinfo/linux-audio-user --------- For more information, please refer to the Linux Audio Development homepage at http://www.linuxdj.com/audio/lad, especially the LAU subscription page --------- Do you mind changing it to: For more information, please refer to the Linux Audio Development homepage at http://lau.linuxaudio.org --------- Cheers. -- Patrick Shirkey - Boost Hardware Ltd. Http://www.boosthardware.com Http://lau.linuxaudio.org - The Linux Audio Users guide ======================================== "Anything your mind can see you can manifest physically, then it will become reality" - Macka B From pshirkey at boosthardware.com Sat Jun 24 15:02:33 2006 From: pshirkey at boosthardware.com (Patrick Shirkey) Date: Sat Jun 24 15:03:51 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] [admin] linux-audio-* maintainer wanted... In-Reply-To: <20060624183116.GD7310@charly.SWORD> References: <449ACFF6.9050501@folkwang-hochschule.de> <20060624092359.GA7310@charly.SWORD> <449D55D8.5020905@folkwang-hochschule.de> <20060624155119.GB7310@charly.SWORD> <449D74AE.9080309@boosthardware.com> <20060624183116.GD7310@charly.SWORD> Message-ID: <449D8C49.8000403@boosthardware.com> Thorsten Wilms wrote: > On Sun, Jun 25, 2006 at 12:21:50AM +0700, Patrick Shirkey wrote: > >> What can I do to assist you with this procedure? I will endeavor to >> facilitate your every need for css compliant markup. >> >> Feel free to shoot me a mail with any questions you may have or details >> that need resolving. > > Heh, thanks :) > > I would like create a new mockup for http://lau.linuxaudio.org/faq first. > Then there's the question wether the whole lau.linuxaudio.org should > be the wiki. Even if not, the theming should be consistent. > At this point I would prefer not to wiki the entire subdomain. However a consistent them for sites are are under lau.linuxaudio.org would be nice. The hard part is to make the content accessible without making it cheesy or boring and I would like to keep the index page layout for that page. If you can come up with a bold and striking theme that incorporates into the current layout while also feeding into the wiki then it would be really great. However whatever you come up with is gonna be worthwhile I'm sure. I'm a great fan of css zen garden so your palette is very broad at the moment. The color scheme I have been working with is white, gold and silver which was deemed acceptable to a number of people a few years ago when I asked here and on lau. > If lad.linuxaudio.org is changed to be all about the list ... > perhaps the mainpages of both should be similar and both feature > the mailing lists first, followed by links to the wiki with FAQ > and all. I have a prominent link on the LAU Guide to the mailing list but it could be made more prominent. I think it would be nice to keep a certain level of separation as the LAD info generally appeals to different people from the lau info and requires a different mindset to grok/participate. Cheers. -- Patrick Shirkey - Boost Hardware Ltd. Http://www.boosthardware.com Http://lau.linuxaudio.org - The Linux Audio Users guide ======================================== "Anything your mind can see you can manifest physically, then it will become reality" - Macka B From james at dis-dot-dat.net Sat Jun 24 18:26:12 2006 From: james at dis-dot-dat.net (james@dis-dot-dat.net) Date: Sat Jun 24 18:26:16 2006 Subject: [linux-audio-dev] What valgrind says Message-ID: <20060624222612.GC10261@fitz.Belkin> Hi peeps. I've just been running an app through valgrind and I'm getting a few of these: ==11955== Syscall param write(buf) points to uninitialised byte(s) ==11955== at 0x4D51BDB: (within /lib64/libpthread-2.4.so) ==11955== by 0x4B27CDD: (within /usr/lib64/libjack.so.0.0.23) ==11955== by 0x4B29434: jack_deactivate (in /usr/lib64/libjack.so.0.0.23) ==11955== by 0x4B2945F: jack_client_close (in /usr/lib64/libjack.so.0.0.23) ==11955== by 0x40402F: jackpart_close() (jackPart.cc:86) ==11955== by 0x40235F: mainLoop() (sampleplayer.cpp:438) ==11955== by 0x40237B: main (sampleplayer.cpp:444) ==11955== Address 0x7FEFFE934 is on thread 1's stack I can't see anything wrong on my part, so I thought I'd check with people who know more than I before I tear my program apart. I also get them coming from jack_port_register, jack_activate and jack_connect. Any ideas? James From paul at linuxaudiosystems.com Sat Jun 24 20:04:02 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Sat Jun 24 20:03:38 2006 Subject: [linux-audio-dev] What valgrind says In-Reply-To: <20060624222612.GC10261@fitz.Belkin> References: <20060624222612.GC10261@fitz.Belkin> Message-ID: <1151193842.10221.99.camel@localhost.localdomain> On Sat, 2006-06-24 at 23:26 +0100, james@dis-dot-dat.net wrote: > Hi peeps. > > I've just been running an app through valgrind and I'm getting a few > of these: > > ==11955== Syscall param write(buf) points to uninitialised byte(s) > ==11955== at 0x4D51BDB: (within /lib64/libpthread-2.4.so) > ==11955== by 0x4B27CDD: (within /usr/lib64/libjack.so.0.0.23) > ==11955== by 0x4B29434: jack_deactivate (in > /usr/lib64/libjack.so.0.0.23) > ==11955== by 0x4B2945F: jack_client_close (in > /usr/lib64/libjack.so.0.0.23) > ==11955== by 0x40402F: jackpart_close() (jackPart.cc:86) > ==11955== by 0x40235F: mainLoop() (sampleplayer.cpp:438) > ==11955== by 0x40237B: main (sampleplayer.cpp:444) > ==11955== Address 0x7FEFFE934 is on thread 1's stack > > > I can't see anything wrong on my part, so I thought I'd check with > people who know more than I before I tear my program apart. > > I also get them coming from jack_port_register, jack_activate and > jack_connect. they don't matter. they are the result of writing a byte to a FIFO to wake up an(other) client. the contents of the byte do not make any difference at any point. --p From mle+la at mega-nerd.com Sat Jun 24 20:29:56 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Sat Jun 24 20:30:06 2006 Subject: [Jackit-devel] [linux-audio-dev] What valgrind says In-Reply-To: <1151193842.10221.99.camel@localhost.localdomain> References: <20060624222612.GC10261@fitz.Belkin> <1151193842.10221.99.camel@localhost.localdomain> Message-ID: <20060625102956.ab42acb6.mle+la@mega-nerd.com> Paul Davis wrote: > they don't matter. they are the result of writing a byte to a FIFO to > wake up an(other) client. the contents of the byte do not make any > difference at any point. Regardless of whether this is a bug or not it would be really nice if this could be fixed. Fixing it means that other people valgrinding their apps which use the Jack libs don't see warnings about Jack. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "Christianity has a nasty habit of ignoring the major problems of our time, including overpopulation and exhaustion of resources, because they aren't mentioned in the Bible." -- Paula L. Craig -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "War is deceit." -- Islam's prophet Mohammed (Hadith 4:268) From james at dis-dot-dat.net Sat Jun 24 20:43:57 2006 From: james at dis-dot-dat.net (james@dis-dot-dat.net) Date: Sat Jun 24 20:44:07 2006 Subject: [linux-audio-dev] What valgrind says In-Reply-To: <1151193842.10221.99.camel@localhost.localdomain> References: <20060624222612.GC10261@fitz.Belkin> <1151193842.10221.99.camel@localhost.localdomain> Message-ID: <20060625004357.GD10261@fitz.Belkin> On Sat, 24 Jun, 2006 at 08:04PM -0400, Paul Davis spake thus: > On Sat, 2006-06-24 at 23:26 +0100, james@dis-dot-dat.net wrote: > > Hi peeps. > > > > I've just been running an app through valgrind and I'm getting a few > > of these: > > > > ==11955== Syscall param write(buf) points to uninitialised byte(s) > > ==11955== at 0x4D51BDB: (within /lib64/libpthread-2.4.so) > > ==11955== by 0x4B27CDD: (within /usr/lib64/libjack.so.0.0.23) > > ==11955== by 0x4B29434: jack_deactivate (in > > /usr/lib64/libjack.so.0.0.23) > > ==11955== by 0x4B2945F: jack_client_close (in > > /usr/lib64/libjack.so.0.0.23) > > ==11955== by 0x40402F: jackpart_close() (jackPart.cc:86) > > ==11955== by 0x40235F: mainLoop() (sampleplayer.cpp:438) > > ==11955== by 0x40237B: main (sampleplayer.cpp:444) > > ==11955== Address 0x7FEFFE934 is on thread 1's stack > > > > > > I can't see anything wrong on my part, so I thought I'd check with > > people who know more than I before I tear my program apart. > > > > I also get them coming from jack_port_register, jack_activate and > > jack_connect. > > they don't matter. they are the result of writing a byte to a FIFO to > wake up an(other) client. the contents of the byte do not make any > difference at any point. Okey dokey. Cheers. James From drobilla at connect.carleton.ca Sun Jun 25 01:52:45 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sun Jun 25 01:52:52 2006 Subject: [linux-audio-dev] LADSPA Extension for Extra GUI Data In-Reply-To: <20060619225743.GF5899@linux-1.site> References: <20060619180343.307d9kslps8400gc@webmail.technetium.net.au> <1150739727.9290.10.camel@localhost.localdomain> <20060619213404.GB9308@login.ecs.soton.ac.uk> <20060619215843.GD5899@linux-1.site> <20060619222552.GC9308@login.ecs.soton.ac.uk> <20060619225743.GF5899@linux-1.site> Message-ID: <1151214765.15405.57.camel@localhost.localdomain> On Tue, 2006-06-20 at 00:57 +0200, Fons Adriaensen wrote: > On Mon, Jun 19, 2006 at 11:25:52PM +0100, Steve Harris wrote: > A well-designed set of tags like the ones you show above would > probably solve 99.9% of all cases. But you can't expect anyone > to dream that up in a day. Which leads me to my main gripe with > LV2: it was defined much too fast. In a normal RFC process, you > present the problem, give interested parties at least a month > to consider it and write something that exceeds the quality of > a whim, and then take at least as much time to study the results > and comment on them before anything is decided. Sorry, but you're _really_ missing the whole point here, Fons. Noone expects anyone to be able to dream up something like the units definition in a day - that's the whole point! We don't _have_ to bicker and argue on a mailing list for days on end about some units definition problem that's completely orthogonal to the plugin specification itself. If the spec had to wait on every single thing that everybody wanted in it, it'd be waiting forever (See: GMPI). You are free to go through a formalized RFC process to define such a thing if you want. You're also free to just bang out a quick one in 5 minutes that gets the information you need in there. A few people already have extensions up their sleeve. LV2 doesn't need to wait on them, because "extensions" have no influence on the spec at all. RDF data can always be "extended" with other RDF data (eg your units information) - there is no possibility for "clashes" or anything like that. (I use quotes because these terms aren't really good descriptions of what's happening) As for giving "interested parties" a chance to weigh in, as Steve said the spec is still completely open to discussion. You are confused abut the scope of the spec itself though - there are a few things to discuss, but not many. The reason LV2 came about so quickly is because it's just LADSPA, translated into a saner extensible format, more or less verbatim. There's not much to weigh in about because noone's added anything new - just the ability to add something new in the future without breaking anything. Which is all we need... -DR- From drobilla at connect.carleton.ca Sun Jun 25 02:01:48 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sun Jun 25 02:02:02 2006 Subject: [linux-audio-dev] Re: LADSPA Extension for Extra GUI Data In-Reply-To: <20060620073515.GB18633@login.ecs.soton.ac.uk> References: <4495CAFF.9030403@technetium.net.au> <20060619100456.GA7336@charly.SWORD> <20060619121501.GA837@bth05w.ABSp.alcatel.be> <1150739354.9290.5.camel@localhost.localdomain> <20060619184425.GB5899@linux-1.site> <20060620073515.GB18633@login.ecs.soton.ac.uk> Message-ID: <1151215308.15405.66.camel@localhost.localdomain> On Tue, 2006-06-20 at 08:35 +0100, Steve Harris wrote: > On Tue, Jun 20, 2006 at 09:05:33 +1000, Loki Davison wrote: > > Because people actually use them in Om, because people actually use Om > > unlike certain other modulars. volt per octave is pretty damn obscure > > in a computer program.... If i wanted to have a cutoff at concert A > > what the hell is that in volts per octave?S > > Zero typically. I have to take issue with this, 1.0f per octave is the > natural way to preresent things like filter cutoff in a modular. It's what > makes the great modular systems so easy to work with. Nonsense. As a numerical unit it has no meaning whatsoever, and the unit actually used has no bearing on the user interface provided (which should of course be exponential). The only sane unit for frequency is Hz. As Loki said, if I want a cutoff at concert A, I (like any musician) know that's 440Hz. Whatever arbitrary ugly real number it is in "V/Oct As Defined By AMS" is not something I or anyone else cares to know. Any table of frequencies, or math app, or damn near _anything_ that deals with frequencies will present it in Hz. If you can come up with a real reason why this arbitrary "AMS V/Oct" makes any sense in a _digital_ modular, I'd like to hear it. Anyway, Hz is the SI unit for frequency. Beat that. :P -DR- From S.W.Harris at ecs.soton.ac.uk Sun Jun 25 13:57:47 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Sun Jun 25 13:58:19 2006 Subject: [linux-audio-dev] Re: LADSPA Extension for Extra GUI Data In-Reply-To: <1151215308.15405.66.camel@localhost.localdomain> References: <4495CAFF.9030403@technetium.net.au> <20060619100456.GA7336@charly.SWORD> <20060619121501.GA837@bth05w.ABSp.alcatel.be> <1150739354.9290.5.camel@localhost.localdomain> <20060619184425.GB5899@linux-1.site> <20060620073515.GB18633@login.ecs.soton.ac.uk> <1151215308.15405.66.camel@localhost.localdomain> Message-ID: <20060625175747.GA12668@login.ecs.soton.ac.uk> On Sun, Jun 25, 2006 at 02:01:48 -0400, Dave Robillard wrote: > On Tue, 2006-06-20 at 08:35 +0100, Steve Harris wrote: > > On Tue, Jun 20, 2006 at 09:05:33 +1000, Loki Davison wrote: > > > Because people actually use them in Om, because people actually use Om > > > unlike certain other modulars. volt per octave is pretty damn obscure > > > in a computer program.... If i wanted to have a cutoff at concert A > > > what the hell is that in volts per octave?S > > > > Zero typically. I have to take issue with this, 1.0f per octave is the > > natural way to preresent things like filter cutoff in a modular. It's what > > makes the great modular systems so easy to work with. > > Nonsense. As a numerical unit it has no meaning whatsoever, and the > unit actually used has no bearing on the user interface provided (which > should of course be exponential). It has a very specific meaning, +1.0 is +1.0 octaves. > The only sane unit for frequency is Hz. As Loki said, if I want a > cutoff at concert A, I (like any musician) know that's 440Hz. Whatever > arbitrary ugly real number it is in "V/Oct As Defined By AMS" is not > something I or anyone else cares to know. Any table of frequencies, or > math app, or damn near _anything_ that deals with frequencies will > present it in Hz. If you can come up with a real reason why this > arbitrary "AMS V/Oct" makes any sense in a _digital_ modular, I'd like > to hear it. It's all about modulation, if I connect a [-1.0, 1.0] sine LFO to a cutoff modulation input then I want it to modulate up and down by N octaves, not N Hz, frequency-linearly symmetric modulations sound wrong. My favourite (digital) modular filters have a centre frequnecy (shown in Hz, expoentialy scaled control) and a modulation input that modulates in octaves. You want the modulation to be musically relevent, and the most musically useful unit for pitch is octaves :) Humans aren't SI sadly. I agree that describing it as volts is a bit odd, but it instantly makes people like me feel at home. There's not reason why a digital modular neds units for its modulation sources. It's just real numbers. - Steve From drobilla at connect.carleton.ca Sun Jun 25 16:21:20 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sun Jun 25 16:21:40 2006 Subject: [linux-audio-dev] Re: LADSPA Extension for Extra GUI Data In-Reply-To: <20060625175747.GA12668@login.ecs.soton.ac.uk> References: <4495CAFF.9030403@technetium.net.au> <20060619100456.GA7336@charly.SWORD> <20060619121501.GA837@bth05w.ABSp.alcatel.be> <1150739354.9290.5.camel@localhost.localdomain> <20060619184425.GB5899@linux-1.site> <20060620073515.GB18633@login.ecs.soton.ac.uk> <1151215308.15405.66.camel@localhost.localdomain> <20060625175747.GA12668@login.ecs.soton.ac.uk> Message-ID: <1151266880.16229.8.camel@localhost.localdomain> On Sun, 2006-06-25 at 18:57 +0100, Steve Harris wrote: > On Sun, Jun 25, 2006 at 02:01:48 -0400, Dave Robillard wrote: > > On Tue, 2006-06-20 at 08:35 +0100, Steve Harris wrote: > > > On Tue, Jun 20, 2006 at 09:05:33 +1000, Loki Davison wrote: > > > > Because people actually use them in Om, because people actually use Om > > > > unlike certain other modulars. volt per octave is pretty damn obscure > > > > in a computer program.... If i wanted to have a cutoff at concert A > > > > what the hell is that in volts per octave?S > > > > > > Zero typically. I have to take issue with this, 1.0f per octave is the > > > natural way to preresent things like filter cutoff in a modular. It's what > > > makes the great modular systems so easy to work with. > > > > Nonsense. As a numerical unit it has no meaning whatsoever, and the > > unit actually used has no bearing on the user interface provided (which > > should of course be exponential). > > It has a very specific meaning, +1.0 is +1.0 octaves. so 2.0 is.. um... well, 2 octaves above.. uh, something... ;) > > The only sane unit for frequency is Hz. As Loki said, if I want a > > cutoff at concert A, I (like any musician) know that's 440Hz. Whatever > > arbitrary ugly real number it is in "V/Oct As Defined By AMS" is not > > something I or anyone else cares to know. Any table of frequencies, or > > math app, or damn near _anything_ that deals with frequencies will > > present it in Hz. If you can come up with a real reason why this > > arbitrary "AMS V/Oct" makes any sense in a _digital_ modular, I'd like > > to hear it. > > It's all about modulation, if I connect a [-1.0, 1.0] sine LFO to a cutoff > modulation input then I want it to modulate up and down by N octaves, not > N Hz, frequency-linearly symmetric modulations sound wrong. My favourite > (digital) modular filters have a centre frequnecy (shown in Hz, expoentialy > scaled control) and a modulation input that modulates in octaves. > > You want the modulation to be musically relevent, and the most musically > useful unit for pitch is octaves :) Humans aren't SI sadly. > > I agree that describing it as volts is a bit odd, but it instantly makes > people like me feel at home. There's not reason why a digital modular neds > units for its modulation sources. It's just real numbers. This is true, but there are other cases when you want a real, meaningful frequency to do something with (using the same plugin). Eg lowpass all frequencies above 800Hz. Someone working on a DAW definitely doesn't want to deal with this meaningless V/Oct unit. Of course, in a modular you can convert Hz frequencies to VOct frequencies, and in a DAW you can convert VOct frequencies to Hz, but in both cases it's a user nuisance, so it needs to be automatic. My gripe isn't with the unit itself, so much as in the current situation with LADSPA it's a really, really huge PITA to have a mess of twisty little units, all alike. Of course LV2 will let us solve this, and the frequency unit can in both cases be kept entirely transparent by the host (if you want), making the actual unit used by a plugin just an optimization as it should be (skipping the conversion step). -DR- From drobilla at connect.carleton.ca Sun Jun 25 16:30:40 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sun Jun 25 16:30:52 2006 Subject: [linux-audio-dev] LADSPA Extension for Extra GUI Data In-Reply-To: <44966EDE.8030509@technetium.net.au> References: <20060619180343.307d9kslps8400gc@webmail.technetium.net.au> <44966EDE.8030509@technetium.net.au> Message-ID: <1151267440.16229.16.camel@localhost.localdomain> On Mon, 2006-06-19 at 19:31 +1000, Jez Kabanov wrote: > > > > The idea itself isn't stupid, but the implementation is.. let's say less > > than wise. > > > > (Consider my personal blatant bias, but...) I'd suggest taking a look at > > LV2. There is a data file you can add all this information to (whatever > > information you want to), without defining any APIs, changing any host > > code, etc, etc. > > > > You definitely shouldn't have to break binary compatibility of things > > just to add some hints for hosts, this is the problem LV2 is meant to > > solve... > > > > -DR- > while i'm no expert in this area, i'm having some trouble understanding > your rationale. > > how is it breaking binary compatibility? > is binary compatibility even an issue? > > shouldn't the host just look for the plugin and load it and check for > the existence of a symbol, > if it exists then call it, otherwise it doesn't and everything is just > as it was. > > the host never need know anything about the binary structure of the > plugin except to know that there's a function called "ladspa_descriptor", > adding ladgui certainly doesn't stop old hosts from loading and using > the plugin, > > i've modified nekobee to use ladgui and it runs exactly as it used to in > an unmodified rosegarden, > so how is binary compatibilty an issue? > > whereas LV2 breaks compatibilty with old plugins (this seems like more > of an issue to me), adds a lot of complexity and requires the host to > use an additional liblv2 library. Basically all you've added is port grouping. Sure, there's no binary breakage now - no kidding, you havn't had to change anything yet. All you've done is added a bunch of metadata that has no reason to be in binary code at all, but you've done it in a way that's going to break horribly as soon as you try to add something. Plus, it's completely useless for GUIs in a separate process, while LV2 is not (it's just a data file, anything can load it, it's not even architechture dependent). Just my two cents, but definitely not the right thing. -DR- From drobilla at connect.carleton.ca Sun Jun 25 16:34:45 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sun Jun 25 16:34:55 2006 Subject: [Jackit-devel] [linux-audio-dev] What valgrind says In-Reply-To: <20060625102956.ab42acb6.mle+la@mega-nerd.com> References: <20060624222612.GC10261@fitz.Belkin> <1151193842.10221.99.camel@localhost.localdomain> <20060625102956.ab42acb6.mle+la@mega-nerd.com> Message-ID: <1151267685.16229.18.camel@localhost.localdomain> On Sun, 2006-06-25 at 10:29 +1000, Erik de Castro Lopo wrote: > Paul Davis wrote: > > > they don't matter. they are the result of writing a byte to a FIFO to > > wake up an(other) client. the contents of the byte do not make any > > difference at any point. > > > Regardless of whether this is a bug or not it would be really > nice if this could be fixed. Fixing it means that other people > valgrinding their apps which use the Jack libs don't see warnings > about Jack. ++ The last thing we need is MORE valgrind warnings.. -DR- From rlrevell at joe-job.com Sun Jun 25 16:49:21 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Sun Jun 25 16:49:30 2006 Subject: [Jackit-devel] [linux-audio-dev] What valgrind says In-Reply-To: <1151267685.16229.18.camel@localhost.localdomain> References: <20060624222612.GC10261@fitz.Belkin> <1151193842.10221.99.camel@localhost.localdomain> <20060625102956.ab42acb6.mle+la@mega-nerd.com> <1151267685.16229.18.camel@localhost.localdomain> Message-ID: <1151268562.2931.268.camel@mindpipe> On Sun, 2006-06-25 at 16:34 -0400, Dave Robillard wrote: > On Sun, 2006-06-25 at 10:29 +1000, Erik de Castro Lopo wrote: > > Paul Davis wrote: > > > > > they don't matter. they are the result of writing a byte to a FIFO to > > > wake up an(other) client. the contents of the byte do not make any > > > difference at any point. > > > > > > Regardless of whether this is a bug or not it would be really > > nice if this could be fixed. Fixing it means that other people > > valgrinding their apps which use the Jack libs don't see warnings > > about Jack. > > ++ > > The last thing we need is MORE valgrind warnings.. I have not looked closely at the code, but could it be considered an information leak if you're using a byte of unitialized data? Lee From mle+la at mega-nerd.com Sun Jun 25 16:55:40 2006 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Sun Jun 25 16:55:50 2006 Subject: [Jackit-devel] [linux-audio-dev] What valgrind says In-Reply-To: <1151268562.2931.268.camel@mindpipe> References: <20060624222612.GC10261@fitz.Belkin> <1151193842.10221.99.camel@localhost.localdomain> <20060625102956.ab42acb6.mle+la@mega-nerd.com> <1151267685.16229.18.camel@localhost.localdomain> <1151268562.2931.268.camel@mindpipe> Message-ID: <20060626065540.3d084b53.mle+la@mega-nerd.com> Lee Revell wrote: > I have not looked closely at the code, but could it be considered an > information leak if you're using a byte of unitialized data? If that data is an automatic (ie stack) variable, then yes. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "We must not forget that Allah's rules have to be established in all lands." -- Imam Muzammil H. Siddiqi of the Islamic Society of North America From fons.adriaensen at skynet.be Sun Jun 25 17:40:53 2006 From: fons.adriaensen at skynet.be (Fons Adriaensen) Date: Sun Jun 25 17:40:35 2006 Subject: [linux-audio-dev] Re: LADSPA Extension for Extra GUI Data In-Reply-To: <20060625175747.GA12668@login.ecs.soton.ac.uk> References: <4495CAFF.9030403@technetium.net.au> <20060619100456.GA7336@charly.SWORD> <20060619121501.GA837@bth05w.ABSp.alcatel.be> <1150739354.9290.5.camel@localhost.localdomain> <20060619184425.GB5899@linux-1.site> <20060620073515.GB18633@login.ecs.soton.ac.uk> <1151215308.15405.66.camel@localhost.localdomain> <20060625175747.GA12668@login.ecs.soton.ac.uk> Message-ID: <20060625214053.GA5940@linux-1.site> On Sun, Jun 25, 2006 at 06:57:47PM +0100, Steve Harris wrote: > I agree that describing it as volts is a bit odd, but it instantly makes > people like me feel at home. There's not reason why a digital modular neds > units for its modulation sources. It's just real numbers. I never mentioned 'volts'. -- FA Follie! Follie! Delirio vano e' questo! From pieterp at joow.be Sun Jun 25 19:08:07 2006 From: pieterp at joow.be (Pieter Palmers) Date: Sun Jun 25 19:08:25 2006 Subject: [linux-audio-dev] ieee1394 deadlock on RT kernels Message-ID: <449F1757.3080207@joow.be> Hi, We are experiencing 'soft' deadlocks when running our code (Freebob, i.e. userspace lib for firewire audio) on RT kernels. After a few seconds, I get a kernel panic message that signals a soft lockup. The problems occur when an ISO stream (receive and/or transmit) is shut down in a SCHED_FIFO thread. More precisely when running the freebob jackd backend in real-time mode. And even more precise: they only seem to occur when jackd is shut down. There are no problems when jackd is run without RT scheduling. I havent been able to reproduce this with other test programs that are shutting down streams in a SCHED_FIFO thread. printk() debugging point to the tasklet_kill() call in ohci1349_unregister_iso_tasklet (drivers/ieee1394/ohci1394.c), that doesn't seem to return. For experiment, i've put a tasklet_disable before the tasklet_kill, and that causes the soft lockup to be due to the tasklet_disable. I would like to ask if anyone has a clue why this is happening. The only thing I can come up with is that jackd is stopped by a CTRL-C, and that the stream shutdown happens in signal handler context, which somehow interacts with the tasklet_kill. But I don't have the time now to dig into this, so for a change I ask for advice early instead of first banging my head against the wall for some days :). Thx, Pieter Palmers From rlrevell at joe-job.com Sun Jun 25 19:11:57 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Sun Jun 25 19:11:56 2006 Subject: [linux-audio-dev] ieee1394 deadlock on RT kernels In-Reply-To: <449F1757.3080207@joow.be> References: <449F1757.3080207@joow.be> Message-ID: <1151277118.2931.272.camel@mindpipe> On Mon, 2006-06-26 at 01:08 +0200, Pieter Palmers wrote: > Hi, > > We are experiencing 'soft' deadlocks when running our code (Freebob, > i.e. userspace lib for firewire audio) on RT kernels. After a few > seconds, I get a kernel panic message that signals a soft lockup. > Can we see the kernel panic message? ;-) Lee > The problems occur when an ISO stream (receive and/or transmit) is shut > down in a SCHED_FIFO thread. More precisely when running the freebob > jackd backend in real-time mode. And even more precise: they only seem > to occur when jackd is shut down. There are no problems when jackd is > run without RT scheduling. > > I havent been able to reproduce this with other test programs that are > shutting down streams in a SCHED_FIFO thread. > > printk() debugging point to the tasklet_kill() call in > ohci1349_unregister_iso_tasklet (drivers/ieee1394/ohci1394.c), that > doesn't seem to return. For experiment, i've put a tasklet_disable > before the tasklet_kill, and that causes the soft lockup to be due to > the tasklet_disable. > > I would like to ask if anyone has a clue why this is happening. The only > thing I can come up with is that jackd is stopped by a CTRL-C, and that > the stream shutdown happens in signal handler context, which somehow > interacts with the tasklet_kill. But I don't have the time now to dig > into this, so for a change I ask for advice early instead of first > banging my head against the wall for some days :). > > Thx, > > Pieter Palmers > > From drobilla at connect.carleton.ca Sun Jun 25 21:23:08 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sun Jun 25 21:23:18 2006 Subject: [Jackit-devel] [linux-audio-dev] What valgrind says In-Reply-To: <1151268562.2931.268.camel@mindpipe> References: <20060624222612.GC10261@fitz.Belkin> <1151193842.10221.99.camel@localhost.localdomain> <20060625102956.ab42acb6.mle+la@mega-nerd.com> <1151267685.16229.18.camel@localhost.localdomain> <1151268562.2931.268.camel@mindpipe> Message-ID: <1151284988.16229.22.camel@localhost.localdomain> On Sun, 2006-06-25 at 16:49 -0400, Lee Revell wrote: > On Sun, 2006-06-25 at 16:34 -0400, Dave Robillard wrote: > > On Sun, 2006-06-25 at 10:29 +1000, Erik de Castro Lopo wrote: > > > Paul Davis wrote: > > > > > > > they don't matter. they are the result of writing a byte to a FIFO to > > > > wake up an(other) client. the contents of the byte do not make any > > > > difference at any point. > > > > > > > > > Regardless of whether this is a bug or not it would be really > > > nice if this could be fixed. Fixing it means that other people > > > valgrinding their apps which use the Jack libs don't see warnings > > > about Jack. > > > > ++ > > > > The last thing we need is MORE valgrind warnings.. > > I have not looked closely at the code, but could it be considered an > information leak if you're using a byte of unitialized data? If you ask me using a byte of uninitialized data is an error, period (even if technically the value of that byte isn't relevant, as in this case). Uninitialized /anything/ is just asking for trouble... -DR- From S.W.Harris at ecs.soton.ac.uk Mon Jun 26 04:04:20 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Mon Jun 26 04:04:49 2006 Subject: [linux-audio-dev] Re: LADSPA Extension for Extra GUI Data In-Reply-To: <1151266880.16229.8.camel@localhost.localdomain> References: <4495CAFF.9030403@technetium.net.au> <20060619100456.GA7336@charly.SWORD> <20060619121501.GA837@bth05w.ABSp.alcatel.be> <1150739354.9290.5.camel@localhost.localdomain> <20060619184425.GB5899@linux-1.site> <20060620073515.GB18633@login.ecs.soton.ac.uk> <1151215308.15405.66.camel@localhost.localdomain> <20060625175747.GA12668@login.ecs.soton.ac.uk> <1151266880.16229.8.camel@localhost.localdomain> Message-ID: <20060626080420.GA24958@login.ecs.soton.ac.uk> On Sun, Jun 25, 2006 at 04:21:20 -0400, Dave Robillard wrote: > > It's all about modulation, if I connect a [-1.0, 1.0] sine LFO to a cutoff > > modulation input then I want it to modulate up and down by N octaves, not > > N Hz, frequency-linearly symmetric modulations sound wrong. My favourite > > (digital) modular filters have a centre frequnecy (shown in Hz, expoentialy > > scaled control) and a modulation input that modulates in octaves. > > > > You want the modulation to be musically relevent, and the most musically > > useful unit for pitch is octaves :) Humans aren't SI sadly. > > > > I agree that describing it as volts is a bit odd, but it instantly makes > > people like me feel at home. There's not reason why a digital modular neds > > units for its modulation sources. It's just real numbers. > > This is true, but there are other cases when you want a real, meaningful > frequency to do something with (using the same plugin). Eg lowpass all > frequencies above 800Hz. Someone working on a DAW definitely doesn't > want to deal with this meaningless V/Oct unit. That's why I said you have a centre frequency control, that's set in Hz. > Of course, in a modular you can convert Hz frequencies to VOct > frequencies, and in a DAW you can convert VOct frequencies to Hz, but in > both cases it's a user nuisance, so it needs to be automatic. My gripe > isn't with the unit itself, so much as in the current situation with > LADSPA it's a really, really huge PITA to have a mess of twisty little > units, all alike. Yes, but neccesary, unless your hosts all understand the semantics of pitch/frequency and are willing to do lots of pow() based conversions. > Of course LV2 will let us solve this, and the frequency unit can in both > cases be kept entirely transparent by the host (if you want), making the > actual unit used by a plugin just an optimization as it should be > (skipping the conversion step). s/will/could/, I'm not yet convinced that it's appropriate. My preference would still be for a Hz centre control and a (high rate) modulation input. If there's a sane representation in RDF for a single port to do both things well, then I'm all for it, but I'm scpetical. - Steve From S.W.Harris at ecs.soton.ac.uk Mon Jun 26 04:05:17 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Mon Jun 26 04:06:36 2006 Subject: [linux-audio-dev] Re: LADSPA Extension for Extra GUI Data In-Reply-To: <20060625214053.GA5940@linux-1.site> References: <4495CAFF.9030403@technetium.net.au> <20060619100456.GA7336@charly.SWORD> <20060619121501.GA837@bth05w.ABSp.alcatel.be> <1150739354.9290.5.camel@localhost.localdomain> <20060619184425.GB5899@linux-1.site> <20060620073515.GB18633@login.ecs.soton.ac.uk> <1151215308.15405.66.camel@localhost.localdomain> <20060625175747.GA12668@login.ecs.soton.ac.uk> <20060625214053.GA5940@linux-1.site> Message-ID: <20060626080517.GB24958@login.ecs.soton.ac.uk> On Sun, Jun 25, 2006 at 11:40:53 +0200, Fons Adriaensen wrote: > On Sun, Jun 25, 2006 at 06:57:47PM +0100, Steve Harris wrote: > > > I agree that describing it as volts is a bit odd, but it instantly makes > > people like me feel at home. There's not reason why a digital modular neds > > units for its modulation sources. It's just real numbers. > > I never mentioned 'volts'. Sorry, that was Dave then. I still feel at home with v/octave though :) - Steve From S.W.Harris at ecs.soton.ac.uk Mon Jun 26 04:07:11 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Mon Jun 26 04:08:14 2006 Subject: [linux-audio-dev] LADSPA Extension for Extra GUI Data In-Reply-To: <1151267440.16229.16.camel@localhost.localdomain> References: <20060619180343.307d9kslps8400gc@webmail.technetium.net.au> <44966EDE.8030509@technetium.net.au> <1151267440.16229.16.camel@localhost.localdomain> Message-ID: <20060626080711.GC24958@login.ecs.soton.ac.uk> On Sun, Jun 25, 2006 at 04:30:40 -0400, Dave Robillard wrote: > Basically all you've added is port grouping. Sure, there's no binary > breakage now - no kidding, you havn't had to change anything yet. All > you've done is added a bunch of metadata that has no reason to be in > binary code at all, but you've done it in a way that's going to break > horribly as soon as you try to add something. No, it also adds rendering of port values. Though that is somewhat limited. > Plus, it's completely useless for GUIs in a separate process, while LV2 > is not (it's just a data file, anything can load it, it's not even > architechture dependent). > > Just my two cents, but definitely not the right thing. That's possibly a bit harsh. I think it's reasonable to say that based on our experiences of LADSPA we know that's not the best way to go. - Steve From pieterp at joow.be Mon Jun 26 04:11:30 2006 From: pieterp at joow.be (Pieter Palmers) Date: Mon Jun 26 04:12:28 2006 Subject: [linux-audio-dev] ieee1394 deadlock on RT kernels In-Reply-To: <1151277118.2931.272.camel@mindpipe> References: <449F1757.3080207@joow.be> <1151277118.2931.272.camel@mindpipe> Message-ID: <449F96B2.1000807@joow.be> Lee Revell wrote: >On Mon, 2006-06-26 at 01:08 +0200, Pieter Palmers wrote: > > >>Hi, >> >>We are experiencing 'soft' deadlocks when running our code (Freebob, >>i.e. userspace lib for firewire audio) on RT kernels. After a few >>seconds, I get a kernel panic message that signals a soft lockup. >> >> > >Can we see the kernel panic message? ;-) > > > no :p. I'm sorry for being a jerk, but I'm not going to type over that message just so that you can confirm that it indeed is a 'soft lockup' (or whatever it is called exactly) and that it occurs in the ohci1394_iso_unregister_tasklet. You'll have to take my word on it. If you need some specific part of the kernel message, you can get it. Tell me what you wqant and why, that way I can learn something from it. Pieter From S.W.Harris at ecs.soton.ac.uk Mon Jun 26 04:14:30 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Mon Jun 26 04:15:02 2006 Subject: [Freebob-devel] [linux-audio-dev] ieee1394 deadlock on RT kernels In-Reply-To: <449F96B2.1000807@joow.be> References: <449F1757.3080207@joow.be> <1151277118.2931.272.camel@mindpipe> <449F96B2.1000807@joow.be> Message-ID: <20060626081430.GD24958@login.ecs.soton.ac.uk> On Mon, Jun 26, 2006 at 10:11:30 +0200, Pieter Palmers wrote: > >Can we see the kernel panic message? ;-) > > > no :p. I'm sorry for being a jerk, but I'm not going to type over that > message just so that you can confirm that it indeed is a 'soft lockup' > (or whatever it is called exactly) and that it occurs in the > ohci1394_iso_unregister_tasklet. You'll have to take my word on it. If > you need some specific part of the kernel message, you can get it. Tell > me what you wqant and why, that way I can learn something from it. Was it not written to /var/log/messages? - Steve From fons.adriaensen at alcatelaleniaspace.com Mon Jun 26 07:53:13 2006 From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen) Date: Mon Jun 26 07:53:26 2006 Subject: [linux-audio-dev] LADSPA Extension for Extra GUI Data In-Reply-To: <20060626080711.GC24958@login.ecs.soton.ac.uk> References: <20060619180343.307d9kslps8400gc@webmail.technetium.net.au> <44966EDE.8030509@technetium.net.au> <1151267440.16229.16.camel@localhost.localdomain> <20060626080711.GC24958@login.ecs.soton.ac.uk> Message-ID: <20060626115312.GB3363@bth05w.ABSp.alcatel.be> On Mon, Jun 26, 2006 at 09:07:11AM +0100, Steve Harris wrote: > On Sun, Jun 25, 2006 at 04:30:40 -0400, Dave Robillard wrote: > > > Plus, it's completely useless for GUIs in a separate process, while LV2 > > is not (it's just a data file, anything can load it, it's not even > > architechture dependent). > > > > Just my two cents, but definitely not the right thing. > > That's possibly a bit harsh. I think it's reasonable to say that based on > our experiences of LADSPA we know that's not the best way to go. If the GUI is in a separate process and connected by e.g. OSC, it could as well be on a machine that doesn't have the plugin files. Or that has a different version of them (for perfectly good reasons). To ensure consistency the GUI should get its plugin descriptions from the host anyway. This works even with POL (Plain Old Ladspa). -- FA Follie! Follie! Delirio vano e' questo! From S.W.Harris at ecs.soton.ac.uk Mon Jun 26 08:19:21 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Mon Jun 26 08:20:04 2006 Subject: [linux-audio-dev] LADSPA Extension for Extra GUI Data In-Reply-To: <20060626115312.GB3363@bth05w.ABSp.alcatel.be> References: <20060619180343.307d9kslps8400gc@webmail.technetium.net.au> <44966EDE.8030509@technetium.net.au> <1151267440.16229.16.camel@localhost.localdomain> <20060626080711.GC24958@login.ecs.soton.ac.uk> <20060626115312.GB3363@bth05w.ABSp.alcatel.be> Message-ID: <20060626121921.GA27513@login.ecs.soton.ac.uk> On Mon, Jun 26, 2006 at 01:53:13 +0200, Alfons Adriaensen wrote: > On Mon, Jun 26, 2006 at 09:07:11AM +0100, Steve Harris wrote: > > > On Sun, Jun 25, 2006 at 04:30:40 -0400, Dave Robillard wrote: > > > > > Plus, it's completely useless for GUIs in a separate process, while LV2 > > > is not (it's just a data file, anything can load it, it's not even > > > architechture dependent). > > > > > > Just my two cents, but definitely not the right thing. > > > > That's possibly a bit harsh. I think it's reasonable to say that based on > > our experiences of LADSPA we know that's not the best way to go. > > If the GUI is in a separate process and connected by e.g. OSC, it > could as well be on a machine that doesn't have the plugin files. > Or that has a different version of them (for perfectly good reasons). > To ensure consistency the GUI should get its plugin descriptions from > the host anyway. This works even with POL (Plain Old Ladspa). True enough, but with POL if the frontend and backend mahcines are different architectures or operating systems then you have a problem. - Steve From fons.adriaensen at alcatelaleniaspace.com Mon Jun 26 09:03:30 2006 From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen) Date: Mon Jun 26 09:03:38 2006 Subject: [linux-audio-dev] LADSPA Extension for Extra GUI Data In-Reply-To: <20060626121921.GA27513@login.ecs.soton.ac.uk> References: <20060619180343.307d9kslps8400gc@webmail.technetium.net.au> <44966EDE.8030509@technetium.net.au> <1151267440.16229.16.camel@localhost.localdomain> <20060626080711.GC24958@login.ecs.soton.ac.uk> <20060626115312.GB3363@bth05w.ABSp.alcatel.be> <20060626121921.GA27513@login.ecs.soton.ac.uk> Message-ID: <20060626130329.GC3363@bth05w.ABSp.alcatel.be> On Mon, Jun 26, 2006 at 01:19:21PM +0100, Steve Harris wrote: > On Mon, Jun 26, 2006 at 01:53:13 +0200, Alfons Adriaensen wrote: > > > If the GUI is in a separate process and connected by e.g. OSC, it > > could as well be on a machine that doesn't have the plugin files. > > Or that has a different version of them (for perfectly good reasons). > > To ensure consistency the GUI should get its plugin descriptions from > > the host anyway. This works even with POL (Plain Old Ladspa). > > True enough, but with POL if the frontend and backend mahcines are different > architectures or operating systems then you have a problem. If send the raw binary data, yes, that's Inviting Trouble (IT). But if it's correctly OSC encoded there shouldn't be a problem. Anyway I guess a host would not use the raw LADSPA data, but a rather a more general format that it could use to describe its internal modules or other plugin formats as well. The GUI doesn't need to know if a module is built-in, LADSPA, LV2, or any other format. One more reason for not having it read the LV2 itself. -- FA Follie! Follie! Delirio vano e' questo! From pieterp at joow.be Mon Jun 26 10:51:13 2006 From: pieterp at joow.be (Pieter Palmers) Date: Mon Jun 26 10:51:17 2006 Subject: [linux-audio-dev] ieee1394 deadlock on RT kernels In-Reply-To: <1151330936.2872.129.camel@grayson> References: <449F1757.3080207@joow.be> <1151277118.2931.272.camel@mindpipe> <449F96B2.1000807@joow.be> <1151330936.2872.129.camel@grayson> Message-ID: <449FF461.908@joow.be> Ben Collins wrote: > On Mon, 2006-06-26 at 10:11 +0200, Pieter Palmers wrote: >> Lee Revell wrote: >> >>> On Mon, 2006-06-26 at 01:08 +0200, Pieter Palmers wrote: >>> >>> >>>> Hi, >>>> >>>> We are experiencing 'soft' deadlocks when running our code (Freebob, >>>> i.e. userspace lib for firewire audio) on RT kernels. After a few >>>> seconds, I get a kernel panic message that signals a soft lockup. >>>> >>>> >>> Can we see the kernel panic message? ;-) >>> >> no :p. I'm sorry for being a jerk, but I'm not going to type over that >> message just so that you can confirm that it indeed is a 'soft lockup' >> (or whatever it is called exactly) and that it occurs in the >> ohci1394_iso_unregister_tasklet. You'll have to take my word on it. If >> you need some specific part of the kernel message, you can get it. Tell >> me what you wqant and why, that way I can learn something from it. > > Take damn a digital photo. I'm sorry for being a jerk, but I'm not going > to debug an oops blind :P I'm sorry for my previous response... a monday-morning-bad-temper-leave-me-alone one that was very non-constructive. On top of that it is quite stupid to ask for help and at the same time claim "you'll have to take my word on it". Please accept my apologies. > > Seriously, if you are going to ask for help, be prepared to provide the > info requested, or plan on getting little to no help. > Of course. My monday-morning bad temper is over by now, and I hope I didn't transfer it to any of you. I'll provide the panic, one way or another. Again, I apologize, Pieter From jack.oquin at gmail.com Mon Jun 26 11:16:50 2006 From: jack.oquin at gmail.com (Jack O'Quin) Date: Mon Jun 26 11:16:58 2006 Subject: [Jackit-devel] [linux-audio-dev] What valgrind says In-Reply-To: <1151284988.16229.22.camel@localhost.localdomain> References: <20060624222612.GC10261@fitz.Belkin> <1151193842.10221.99.camel@localhost.localdomain> <20060625102956.ab42acb6.mle+la@mega-nerd.com> <1151267685.16229.18.camel@localhost.localdomain> <1151268562.2931.268.camel@mindpipe> <1151284988.16229.22.camel@localhost.localdomain> Message-ID: On 6/25/06, Dave Robillard wrote: > On Sun, 2006-06-25 at 16:49 -0400, Lee Revell wrote: > > On Sun, 2006-06-25 at 16:34 -0400, Dave Robillard wrote: > > > On Sun, 2006-06-25 at 10:29 +1000, Erik de Castro Lopo wrote: > > > > Regardless of whether this is a bug or not it would be really > > > > nice if this could be fixed. Fixing it means that other people > > > > valgrinding their apps which use the Jack libs don't see warnings > > > > about Jack. > > > > > > ++ > > > > > > The last thing we need is MORE valgrind warnings.. > > > > I have not looked closely at the code, but could it be considered an > > information leak if you're using a byte of unitialized data? > > If you ask me using a byte of uninitialized data is an error, period > (even if technically the value of that byte isn't relevant, as in this > case). > > Uninitialized /anything/ is just asking for trouble... libjack seems OK already, but there was an unitialied char written by jackd. I fixed that and committed it as [0.102.18]. I don't have valgrind set up correctly on my new laptop. Could one of you please update to the latest SVN version and verify whether this fixes that warning message? -- joq From rlrevell at joe-job.com Mon Jun 26 11:29:55 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Mon Jun 26 11:30:12 2006 Subject: [linux-audio-dev] ieee1394 deadlock on RT kernels In-Reply-To: <449FF461.908@joow.be> References: <449F1757.3080207@joow.be> <1151277118.2931.272.camel@mindpipe> <449F96B2.1000807@joow.be> <1151330936.2872.129.camel@grayson> <449FF461.908@joow.be> Message-ID: <1151335796.26257.48.camel@mindpipe> On Mon, 2006-06-26 at 16:51 +0200, Pieter Palmers wrote: > Ben Collins wrote: > > On Mon, 2006-06-26 at 10:11 +0200, Pieter Palmers wrote: > >> Lee Revell wrote: Can we please use "Reply to All" for all followups, as is the convention in kernel development? It's annoying to follow a thread when some of it is in my Inbox, some is on LAD, and some apparently was mailed privately ;-) Lee From rlrevell at joe-job.com Mon Jun 26 11:57:30 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Mon Jun 26 11:57:50 2006 Subject: [linux-audio-dev] ieee1394 deadlock on RT kernels In-Reply-To: <449FF461.908@joow.be> References: <449F1757.3080207@joow.be> <1151277118.2931.272.camel@mindpipe> <449F96B2.1000807@joow.be> <1151330936.2872.129.camel@grayson> <449FF461.908@joow.be> Message-ID: <1151337451.26257.62.camel@mindpipe> On Mon, 2006-06-26 at 16:51 +0200, Pieter Palmers wrote: > > Of course. My monday-morning bad temper is over by now, and I hope I > didn't transfer it to any of you. I'll provide the panic, one way or > another. > Can you reproduce the problem on a non-RT kernel? Lee From _ at whats-your.name Mon Jun 26 14:05:37 2006 From: _ at whats-your.name (carmen) Date: Mon Jun 26 14:05:36 2006 Subject: [linux-audio-dev] LADSPA Extension for Extra GUI Data In-Reply-To: <20060626130329.GC3363@bth05w.ABSp.alcatel.be> References: <20060619180343.307d9kslps8400gc@webmail.technetium.net.au> <44966EDE.8030509@technetium.net.au> <1151267440.16229.16.camel@localhost.localdomain> <20060626080711.GC24958@login.ecs.soton.ac.uk> <20060626115312.GB3363@bth05w.ABSp.alcatel.be> <20060626121921.GA27513@login.ecs.soton.ac.uk> <20060626130329.GC3363@bth05w.ABSp.alcatel.be> Message-ID: <20060626180537.GS2312@replic.net> > > > To ensure consistency the GUI should get its plugin descriptions from > > > the host anyway. This works even with POL (Plain Old Ladspa). > rather a more general format that it could use to describe its > internal modules or other plugin formats as well. The GUI doesn't in theory, this (client-readable metadata) shouldnt be a selling point. i mean if most hosts provided a nice API to query for plugin parameters. most don't.. it would be great for people to be able to make controllers for plugins, without the author of RoseGarden or Seq24 needing to ad some OM-style OSC-query-of-plugin-namespace .. From pieterp at joow.be Mon Jun 26 15:05:28 2006 From: pieterp at joow.be (Pieter Palmers) Date: Mon Jun 26 15:05:44 2006 Subject: [linux-audio-dev] ieee1394 deadlock on RT kernels In-Reply-To: <1151337451.26257.62.camel@mindpipe> References: <449F1757.3080207@joow.be> <1151277118.2931.272.camel@mindpipe> <449F96B2.1000807@joow.be> <1151330936.2872.129.camel@grayson> <449FF461.908@joow.be> <1151337451.26257.62.camel@mindpipe> Message-ID: <44A02FF8.3030901@joow.be> Lee Revell wrote: > On Mon, 2006-06-26 at 16:51 +0200, Pieter Palmers wrote: >> >> Of course. My monday-morning bad temper is over by now, and I hope I >> didn't transfer it to any of you. I'll provide the panic, one way or >> another. >> > > Can you reproduce the problem on a non-RT kernel? > No, it only occurs with RT kernels, and only with those configured for PREEMPT_RT. If I use PREEMPT_DESKTOP, there is no problem. (with threaded IRQ's etc... only switched over the preemption level in the kernel config). I've uploaded the photo's of the panic here: http://freebob.sourceforge.net/old/img_3378.jpg (without flash) http://freebob.sourceforge.net/old/img_3377.jpg (with flash) both are of suboptimal quality unfortunately, but all info is readable on one or the other. Greets & thanks, Pieter From rlrevell at joe-job.com Mon Jun 26 15:24:22 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Mon Jun 26 15:31:29 2006 Subject: [linux-audio-dev] ieee1394 deadlock on RT kernels In-Reply-To: <44A02FF8.3030901@joow.be> References: <449F1757.3080207@joow.be> <1151277118.2931.272.camel@mindpipe> <449F96B2.1000807@joow.be> <1151330936.2872.129.camel@grayson> <449FF461.908@joow.be> <1151337451.26257.62.camel@mindpipe> <44A02FF8.3030901@joow.be> Message-ID: <1151349863.26257.123.camel@mindpipe> On Mon, 2006-06-26 at 21:05 +0200, Pieter Palmers wrote: > Lee Revell wrote: > > On Mon, 2006-06-26 at 16:51 +0200, Pieter Palmers wrote: > >> > >> Of course. My monday-morning bad temper is over by now, and I hope I > >> didn't transfer it to any of you. I'll provide the panic, one way or > >> another. > >> > > > > Can you reproduce the problem on a non-RT kernel? > > > > No, it only occurs with RT kernels, and only with those configured for > PREEMPT_RT. If I use PREEMPT_DESKTOP, there is no problem. (with > threaded IRQ's etc... only switched over the preemption level in the > kernel config). > > I've uploaded the photo's of the panic here: > http://freebob.sourceforge.net/old/img_3378.jpg (without flash) > http://freebob.sourceforge.net/old/img_3377.jpg (with flash) > > both are of suboptimal quality unfortunately, but all info is readable > on one or the other. Can you add debug printk's before and after tasklet_kill() in ohci1394_unregister_iso_tasklet to see where it locks up? Lee From pieterp at joow.be Mon Jun 26 15:44:08 2006 From: pieterp at joow.be (Pieter Palmers) Date: Mon Jun 26 15:44:22 2006 Subject: [linux-audio-dev] ieee1394 deadlock on RT kernels In-Reply-To: <1151349863.26257.123.camel@mindpipe> References: <449F1757.3080207@joow.be> <1151277118.2931.272.camel@mindpipe> <449F96B2.1000807@joow.be> <1151330936.2872.129.camel@grayson> <449FF461.908@joow.be> <1151337451.26257.62.camel@mindpipe> <44A02FF8.3030901@joow.be> <1151349863.26257.123.camel@mindpipe> Message-ID: <44A03908.3050803@joow.be> Lee Revell wrote: > On Mon, 2006-06-26 at 21:05 +0200, Pieter Palmers wrote: >> Lee Revell wrote: >>> On Mon, 2006-06-26 at 16:51 +0200, Pieter Palmers wrote: >>>> >>>> Of course. My monday-morning bad temper is over by now, and I hope I >>>> didn't transfer it to any of you. I'll provide the panic, one way or >>>> another. >>>> >>> Can you reproduce the problem on a non-RT kernel? >>> >> No, it only occurs with RT kernels, and only with those configured for >> PREEMPT_RT. If I use PREEMPT_DESKTOP, there is no problem. (with >> threaded IRQ's etc... only switched over the preemption level in the >> kernel config). >> >> I've uploaded the photo's of the panic here: >> http://freebob.sourceforge.net/old/img_3378.jpg (without flash) >> http://freebob.sourceforge.net/old/img_3377.jpg (with flash) >> >> both are of suboptimal quality unfortunately, but all info is readable >> on one or the other. > > Can you add debug printk's before and after tasklet_kill() in > ohci1394_unregister_iso_tasklet to see where it locks up? > That's the first thing I did: the printk before tasklet_kill succeeds, the one right after the tasklet_kill doesn't. Pieter From rlrevell at joe-job.com Mon Jun 26 15:57:51 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Mon Jun 26 15:58:50 2006 Subject: [linux-audio-dev] ieee1394 deadlock on RT kernels In-Reply-To: <44A03908.3050803@joow.be> References: <449F1757.3080207@joow.be> <1151277118.2931.272.camel@mindpipe> <449F96B2.1000807@joow.be> <1151330936.2872.129.camel@grayson> <449FF461.908@joow.be> <1151337451.26257.62.camel@mindpipe> <44A02FF8.3030901@joow.be> <1151349863.26257.123.camel@mindpipe> <44A03908.3050803@joow.be> Message-ID: <1151351871.26257.132.camel@mindpipe> On Mon, 2006-06-26 at 21:44 +0200, Pieter Palmers wrote: > Lee Revell wrote: > > On Mon, 2006-06-26 at 21:05 +0200, Pieter Palmers wrote: > >> Lee Revell wrote: > >>> On Mon, 2006-06-26 at 16:51 +0200, Pieter Palmers wrote: > >>>> > >>>> Of course. My monday-morning bad temper is over by now, and I hope I > >>>> didn't transfer it to any of you. I'll provide the panic, one way or > >>>> another. > >>>> > >>> Can you reproduce the problem on a non-RT kernel? > >>> > >> No, it only occurs with RT kernels, and only with those configured for > >> PREEMPT_RT. If I use PREEMPT_DESKTOP, there is no problem. (with > >> threaded IRQ's etc... only switched over the preemption level in the > >> kernel config). > >> > >> I've uploaded the photo's of the panic here: > >> http://freebob.sourceforge.net/old/img_3378.jpg (without flash) > >> http://freebob.sourceforge.net/old/img_3377.jpg (with flash) > >> > >> both are of suboptimal quality unfortunately, but all info is readable > >> on one or the other. > > > > Can you add debug printk's before and after tasklet_kill() in > > ohci1394_unregister_iso_tasklet to see where it locks up? > > > That's the first thing I did: the printk before tasklet_kill succeeds, > the one right after the tasklet_kill doesn't. OK that's what I suspected. It seems that the -rt patch changes tasklet_kill: Unpatched 2.6.17: void tasklet_kill(struct tasklet_struct *t) { if (in_interrupt()) printk("Attempt to kill tasklet from interrupt\n"); while (test_and_set_bit(TASKLET_STATE_SCHED, &t->state)) { do yield(); while (test_bit(TASKLET_STATE_SCHED, &t->state)); } tasklet_unlock_wait(t); clear_bit(TASKLET_STATE_SCHED, &t->state); } 2.6.17-rt: void tasklet_kill(struct tasklet_struct *t) { if (in_interrupt()) printk("Attempt to kill tasklet from interrupt\n"); while (test_and_set_bit(TASKLET_STATE_SCHED, &t->state)) { do msleep(1); while (test_bit(TASKLET_STATE_SCHED, &t->state)); } tasklet_unlock_wait(t); clear_bit(TASKLET_STATE_SCHED, &t->state); } You should ask Ingo & the other -rt developers what the intent of this change was. Obviously it loops forever waiting for the state bit to change. Lee From rlrevell at joe-job.com Mon Jun 26 16:15:00 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Mon Jun 26 16:15:08 2006 Subject: [linux-audio-dev] ieee1394 deadlock on RT kernels In-Reply-To: <44A03908.3050803@joow.be> References: <449F1757.3080207@joow.be> <1151277118.2931.272.camel@mindpipe> <449F96B2.1000807@joow.be> <1151330936.2872.129.camel@grayson> <449FF461.908@joow.be> <1151337451.26257.62.camel@mindpipe> <44A02FF8.3030901@joow.be> <1151349863.26257.123.camel@mindpipe> <44A03908.3050803@joow.be> Message-ID: <1151352901.26257.141.camel@mindpipe> On Mon, 2006-06-26 at 21:44 +0200, Pieter Palmers wrote: > Lee Revell wrote: > > On Mon, 2006-06-26 at 21:05 +0200, Pieter Palmers wrote: > >> Lee Revell wrote: > >>> On Mon, 2006-06-26 at 16:51 +0200, Pieter Palmers wrote: > >>>> > >>>> Of course. My monday-morning bad temper is over by now, and I hope I > >>>> didn't transfer it to any of you. I'll provide the panic, one way or > >>>> another. > >>>> > >>> Can you reproduce the problem on a non-RT kernel? > >>> > >> No, it only occurs with RT kernels, and only with those configured for > >> PREEMPT_RT. If I use PREEMPT_DESKTOP, there is no problem. (with > >> threaded IRQ's etc... only switched over the preemption level in the > >> kernel config). > >> > >> I've uploaded the photo's of the panic here: > >> http://freebob.sourceforge.net/old/img_3378.jpg (without flash) > >> http://freebob.sourceforge.net/old/img_3377.jpg (with flash) > >> > >> both are of suboptimal quality unfortunately, but all info is readable > >> on one or the other. > > > > Can you add debug printk's before and after tasklet_kill() in > > ohci1394_unregister_iso_tasklet to see where it locks up? > > > That's the first thing I did: the printk before tasklet_kill succeeds, > the one right after the tasklet_kill doesn't. Actually the problem might not be the change to tasklet_kill() but the change to tasklet_unlock_wait(). include/linux/interrupt.h: #if defined(CONFIG_SMP) || defined(CONFIG_PREEMPT_RT) static inline void tasklet_unlock_wait(struct tasklet_struct *t) { while (test_bit(TASKLET_STATE_RUN, &(t)->state)) { barrier(); } } #else # define tasklet_unlock_wait(t) do { } while (0) Can you add a printk before that while loop? Lee From jef at synthedit.com Mon Jun 26 16:29:21 2006 From: jef at synthedit.com (Jeff McClintock) Date: Mon Jun 26 16:29:46 2006 Subject: [linux-audio-dev] LADSPA Extension for Extra GUI Data In-Reply-To: <20060626201514.359DD1F06CA7@music.columbia.edu> References: <20060626201514.359DD1F06CA7@music.columbia.edu> Message-ID: <44A043A1.2050704@synthedit.com> > it would be great for people to be able to make controllers for plugins, without the author of RoseGarden or Seq24 needing to ad some OM-style OSC-query-of-plugin-namespace In my mind every plugin parameter should be automatable, therefore every parameter update should be visible to the host ...therefore every plugin GUI should connect to the host (not directly to the plugin)...therefore to support such GUIs every host *SHOULD* provide some kind of query-of-plugin-namespace. Jeff > Message: 3 > Date: Mon, 26 Jun 2006 18:05:37 +0000 > From: carmen <_@whats-your.name> > Subject: Re: [linux-audio-dev] LADSPA Extension for Extra GUI Data > To: linux-audio-dev@music.columbia.edu > Message-ID: <20060626180537.GS2312@replic.net> > Content-Type: text/plain; charset=us-ascii > > >>>>To ensure consistency the GUI should get its plugin descriptions from >>>>the host anyway. This works even with POL (Plain Old Ladspa). > > >>rather a more general format that it could use to describe its >>internal modules or other plugin formats as well. The GUI doesn't > > > in theory, this (client-readable metadata) shouldnt be a selling point. i mean if most hosts provided a nice API to query for plugin parameters. most don't.. > > it would be great for people to be able to make controllers for plugins, without the author of RoseGarden or Seq24 needing to ad some OM-style OSC-query-of-plugin-namespace > > .. > > From pieterp at joow.be Mon Jun 26 16:35:09 2006 From: pieterp at joow.be (Pieter Palmers) Date: Mon Jun 26 16:36:12 2006 Subject: [Freebob-devel] [linux-audio-dev] ieee1394 deadlock on RT kernels In-Reply-To: <1151351871.26257.132.camel@mindpipe> References: <449F1757.3080207@joow.be> <1151277118.2931.272.camel@mindpipe> <449F96B2.1000807@joow.be> <1151330936.2872.129.camel@grayson> <449FF461.908@joow.be> <1151337451.26257.62.camel@mindpipe> <44A02FF8.3030901@joow.be> <1151349863.26257.123.camel@mindpipe> <44A03908.3050803@joow.be> <1151351871.26257.132.camel@mindpipe> Message-ID: <44A044FD.6020201@joow.be> Lee Revell wrote: > On Mon, 2006-06-26 at 21:44 +0200, Pieter Palmers wrote: >> Lee Revell wrote: >>> On Mon, 2006-06-26 at 21:05 +0200, Pieter Palmers wrote: >>>> Lee Revell wrote: >>>>> On Mon, 2006-06-26 at 16:51 +0200, Pieter Palmers wrote: >>>>>> >>>>>> Of course. My monday-morning bad temper is over by now, and I hope I >>>>>> didn't transfer it to any of you. I'll provide the panic, one way or >>>>>> another. >>>>>> >>>>> Can you reproduce the problem on a non-RT kernel? >>>>> >>>> No, it only occurs with RT kernels, and only with those configured for >>>> PREEMPT_RT. If I use PREEMPT_DESKTOP, there is no problem. (with >>>> threaded IRQ's etc... only switched over the preemption level in the >>>> kernel config). >>>> >>>> I've uploaded the photo's of the panic here: >>>> http://freebob.sourceforge.net/old/img_3378.jpg (without flash) >>>> http://freebob.sourceforge.net/old/img_3377.jpg (with flash) >>>> >>>> both are of suboptimal quality unfortunately, but all info is readable >>>> on one or the other. >>> Can you add debug printk's before and after tasklet_kill() in >>> ohci1394_unregister_iso_tasklet to see where it locks up? >>> >> That's the first thing I did: the printk before tasklet_kill succeeds, >> the one right after the tasklet_kill doesn't. > > OK that's what I suspected. > > It seems that the -rt patch changes tasklet_kill: > > Unpatched 2.6.17: > > void tasklet_kill(struct tasklet_struct *t) > { > if (in_interrupt()) > printk("Attempt to kill tasklet from interrupt\n"); > > while (test_and_set_bit(TASKLET_STATE_SCHED, &t->state)) { > do > yield(); > while (test_bit(TASKLET_STATE_SCHED, &t->state)); > } > tasklet_unlock_wait(t); > clear_bit(TASKLET_STATE_SCHED, &t->state); > } > > 2.6.17-rt: > > void tasklet_kill(struct tasklet_struct *t) > { > if (in_interrupt()) > printk("Attempt to kill tasklet from interrupt\n"); > > while (test_and_set_bit(TASKLET_STATE_SCHED, &t->state)) { > do > msleep(1); > while (test_bit(TASKLET_STATE_SCHED, &t->state)); > } > tasklet_unlock_wait(t); > clear_bit(TASKLET_STATE_SCHED, &t->state); > } > > You should ask Ingo & the other -rt developers what the intent of this > change was. Obviously it loops forever waiting for the state bit to > change. > because you are not allowed to yield() in an RT context? I wish I had been a little more elaborate on my initial mail, as it would have saved us some time, and communication troubles (on my part that is). I already spotted the msleep() change in the patch, and I already tried reverting it. That gives you a nice new panic message, something like 'BUG: yield()'ing in ...'. I'm wondering why a patched, but not 'complete preemption' configured kernel works fine. This change is present in them too, so it probably has something to do with the msleep() implementation. Another strange thing is: why doesn't the tasklet finish, so that it can be 'unscheduled'? I have my IRQ priorities higher than any other RT threads, so I would expect that the tasklet can finish. Or is tasklet_kill not-preemtible? that would be very strange as I would expect that busy waiting on something in a non-preemptible code path on a single-cpu system always deadlocks. Greets, Pieter From rlrevell at joe-job.com Mon Jun 26 17:05:31 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Mon Jun 26 17:05:26 2006 Subject: [Freebob-devel] [linux-audio-dev] ieee1394 deadlock on RT kernels In-Reply-To: <44A044FD.6020201@joow.be> References: <449F1757.3080207@joow.be> <1151277118.2931.272.camel@mindpipe> <449F96B2.1000807@joow.be> <1151330936.2872.129.camel@grayson> <449FF461.908@joow.be> <1151337451.26257.62.camel@mindpipe> <44A02FF8.3030901@joow.be> <1151349863.26257.123.camel@mindpipe> <44A03908.3050803@joow.be> <1151351871.26257.132.camel@mindpipe> <44A044FD.6020201@joow.be> Message-ID: <1151355932.26257.144.camel@mindpipe> On Mon, 2006-06-26 at 22:35 +0200, Pieter Palmers wrote: > because you are not allowed to yield() in an RT context? > > I wish I had been a little more elaborate on my initial mail, as it > would have saved us some time, and communication troubles (on my part > that is). I already spotted the msleep() change in the patch, and I > already tried reverting it. That gives you a nice new panic message, > something like 'BUG: yield()'ing in ...'. > > I'm wondering why a patched, but not 'complete preemption' configured > kernel works fine. This change is present in them too, so it probably > has something to do with the msleep() implementation. Because I suspect that the change to tasklet_unlock_wait() was actually responsible. Did you add a printk() yet as I suggested in my last mail? Once you add a printk to verify that it hangs in the while loop in tasklet_unlock_wait() I think you have enough information for a bug report. Lee From james at dis-dot-dat.net Mon Jun 26 19:05:43 2006 From: james at dis-dot-dat.net (james@dis-dot-dat.net) Date: Mon Jun 26 19:05:56 2006 Subject: [Jackit-devel] [linux-audio-dev] What valgrind says In-Reply-To: References: <20060624222612.GC10261@fitz.Belkin> <1151193842.10221.99.camel@localhost.localdomain> <20060625102956.ab42acb6.mle+la@mega-nerd.com> <1151267685.16229.18.camel@localhost.localdomain> <1151268562.2931.268.camel@mindpipe> <1151284988.16229.22.camel@localhost.localdomain> Message-ID: <20060626230543.GG10261@fitz.Belkin> On Mon, 26 Jun, 2006 at 10:16AM -0500, Jack O'Quin spake thus: > On 6/25/06, Dave Robillard wrote: > >On Sun, 2006-06-25 at 16:49 -0400, Lee Revell wrote: > >> On Sun, 2006-06-25 at 16:34 -0400, Dave Robillard wrote: > >> > On Sun, 2006-06-25 at 10:29 +1000, Erik de Castro Lopo wrote: > >> > > Regardless of whether this is a bug or not it would be really > >> > > nice if this could be fixed. Fixing it means that other people > >> > > valgrinding their apps which use the Jack libs don't see warnings > >> > > about Jack. > >> > > >> > ++ > >> > > >> > The last thing we need is MORE valgrind warnings.. > >> > >> I have not looked closely at the code, but could it be considered an > >> information leak if you're using a byte of unitialized data? > > > >If you ask me using a byte of uninitialized data is an error, period > >(even if technically the value of that byte isn't relevant, as in this > >case). > > > >Uninitialized /anything/ is just asking for trouble... > > libjack seems OK already, but there was an unitialied char > written by jackd. I fixed that and committed it as [0.102.18]. > > I don't have valgrind set up correctly on my new laptop. Could > one of you please update to the latest SVN version and verify > whether this fixes that warning message? OK, since I brought it up I thought I'd better test it out. Sorry, but I still get the same problem. Compiling from the raw SVN-delivered source instead of emerging it might have given a bit of a hint, though. Valgrind is now able to give the location inside jack that the error occurs: client.c, line 240 I've attached a log from valgrind (includes my own debugging output, easily ignored). Hope that helps! James -------------- next part -------------- ==514== Memcheck, a memory error detector. ==514== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==514== Using LibVEX rev 1606, a library for dynamic binary translation. ==514== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==514== Using valgrind-3.2.0, a dynamic binary instrumentation framework. ==514== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==514== --514-- Command line --514-- ./sampleplayer --514-- Startup, with flags: --514-- --leak-check=full --514-- -v --514-- --show-reachable=yes --514-- Contents of /proc/version: --514-- Linux version 2.6.17-rc1-mm2 (root@fitz) (gcc version 3.4.6 (Gentoo 3.4.6, ssp-3.4.5-1.0, pie-8.7.9)) #3 SMP PREEMPT Sat Apr 15 23:37:59 BST 2006 --514-- Arch and hwcaps: AMD64, amd64-sse2 --514-- Valgrind library directory: /usr/lib64/valgrind --514-- Reading syms from /home/james/code/sampleplayer/src/sampleplayer/sampleplayer (0x400000) --514-- Reading syms from /lib64/ld-2.4.so (0x4000000) --514-- Reading syms from /usr/lib64/valgrind/amd64-linux/memcheck (0x38000000) --514-- object doesn't have a symbol table --514-- object doesn't have a dynamic symbol table --514-- Reading suppressions file: /usr/lib64/valgrind/default.supp --514-- Reading syms from /usr/lib64/valgrind/amd64-linux/vgpreload_core.so (0x491C000) --514-- object doesn't have a symbol table --514-- Reading syms from /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so (0x4A1D000) --514-- object doesn't have a symbol table --514-- REDIR: 0x4012EB0 (index) redirected to 0x4A209D0 (index) --514-- REDIR: 0x4013060 (strcmp) redirected to 0x4A20EE0 (strcmp) --514-- REDIR: 0x4013370 (strlen) redirected to 0x4A20C40 (strlen) --514-- Reading syms from /usr/local/lib64/libjack.so.0.0.23 (0x4B23000) --514-- Reading syms from /usr/lib64/liblo.so.0.6.0 (0x4C3D000) --514-- object doesn't have a symbol table --514-- Reading syms from /lib64/libpthread-2.4.so (0x4D47000) --514-- Reading syms from /usr/lib64/libsndfile.so.1.0.16 (0x4E5D000) --514-- object doesn't have a symbol table --514-- Reading syms from /usr/lib64/libsamplerate.so.0.1.1 (0x4FB2000) --514-- object doesn't have a symbol table --514-- Reading syms from /usr/lib64/gcc/x86_64-pc-linux-gnu/3.4.6/libstdc++.so.6.0.3 (0x50CE000) --514-- object doesn't have a symbol table --514-- Reading syms from /lib64/libm-2.4.so (0x52BE000) --514-- object doesn't have a symbol table --514-- Reading syms from /lib64/libgcc_s.so.1 (0x5416000) --514-- object doesn't have a symbol table --514-- Reading syms from /lib64/libc-2.4.so (0x5521000) --514-- object doesn't have a symbol table ==514== Warning: zero-sized CIE/FDE but not at section end in DWARF2 CFI reading --514-- Reading syms from /lib64/libdl-2.4.so (0x574D000) --514-- object doesn't have a symbol table --514-- Reading syms from /usr/lib64/libFLAC.so.7.0.0 (0x5851000) --514-- object doesn't have a symbol table --514-- REDIR: 0x55931A0 (memset) redirected to 0x4A21420 (memset) --514-- REDIR: 0x5594CC0 (memcpy) redirected to 0x4A20F70 (memcpy) --514-- REDIR: 0x55924E0 (rindex) redirected to 0x4A208D0 (rindex) --514-- REDIR: 0x5591480 (strlen) redirected to 0x4A20C00 (strlen) --514-- REDIR: 0x5590960 (strcpy) redirected to 0x4A20C60 (strcpy) --514-- REDIR: 0x517D360 (operator new(unsigned long)) redirected to 0x4A1EEF0 (operator new(unsigned long)) Made mixer --514-- REDIR: 0x558CB70 (malloc) redirected to 0x4A1EA60 (malloc) connecting with liblo --514-- REDIR: 0x558C820 (calloc) redirected to 0x4A202D0 (calloc) --514-- REDIR: 0x5592B40 (memchr) redirected to 0x4A20F40 (memchr) --514-- REDIR: 0x5595980 (strchrnul) redirected to 0x4A214A0 (strchrnul) --514-- REDIR: 0x558B2E0 (free) redirected to 0x4A1F880 (free) --514-- REDIR: 0x5590640 (strcmp) redirected to 0x4A20EB0 (strcmp) --514-- REDIR: 0x5593BF0 (stpcpy) redirected to 0x4A21180 (stpcpy) --514-- Reading syms from /lib64/libnss_files-2.4.so (0x5A84000) --514-- object doesn't have a symbol table --514-- REDIR: 0xFFFFFFFFFF600000 (???) redirected to 0x38027BD3 (???) --514-- REDIR: 0x55918B0 (strncmp) redirected to 0x4A20E60 (strncmp) --514-- REDIR: 0x5591C60 (strncpy) redirected to 0x4A20D40 (strncpy) --514-- REDIR: 0x5590490 (index) redirected to 0x4A20990 (index) --514-- REDIR: 0x5595890 (rawmemchr) redirected to 0x4A214C0 (rawmemchr) --514-- Reading syms from /lib64/libnss_dns-2.4.so (0x5B8F000) --514-- object doesn't have a symbol table --514-- Reading syms from /lib64/libresolv-2.4.so (0x5C94000) --514-- object doesn't have a symbol table opening jackpart --514-- REDIR: 0x55902D0 (strcat) redirected to 0x4A209F0 (strcat) ==514== Syscall param write(buf) points to uninitialised byte(s) ==514== at 0x4D52BDB: (within /lib64/libpthread-2.4.so) ==514== by 0x4B2846D: oop_client_deliver_request (client.c:240) ==514== by 0x4B2B9DF: jack_port_register (port.c:425) ==514== by 0x404774: jackpart_open(char const*, bool) (jackPart.cc:112) ==514== by 0x4023C4: mainLoop() (sampleplayer.cpp:454) ==514== by 0x40250B: main (sampleplayer.cpp:497) ==514== Address 0x7FEFFE914 is on thread 1's stack ==514== ==514== Syscall param write(buf) points to uninitialised byte(s) ==514== at 0x4D52BDB: (within /lib64/libpthread-2.4.so) ==514== by 0x4B2846D: oop_client_deliver_request (client.c:240) ==514== by 0x4B299B5: jack_activate (client.c:1820) ==514== by 0x404787: jackpart_open(char const*, bool) (jackPart.cc:113) ==514== by 0x4023C4: mainLoop() (sampleplayer.cpp:454) ==514== by 0x40250B: main (sampleplayer.cpp:497) ==514== Address 0x7FEFFE934 is on thread 1's stack ==514== ==514== Syscall param write(buf) points to uninitialised byte(s) ==514== at 0x4D52BDB: (within /lib64/libpthread-2.4.so) ==514== by 0x4B2846D: oop_client_deliver_request (client.c:240) ==514== by 0x4B2A416: jack_connect (client.c:1966) ==514== by 0x40484A: jackpart_open(char const*, bool) (jackPart.cc:130) ==514== by 0x4023C4: mainLoop() (sampleplayer.cpp:454) ==514== by 0x40250B: main (sampleplayer.cpp:497) ==514== Address 0x7FEFFE934 is on thread 1's stack setting audio callback entering idle loop Asked to load: /home/james/code/sampleplayer/sounds/kick1.wav into slot 0 --514-- REDIR: 0x517D490 (operator new[](unsigned long)) redirected to 0x4A1F450 (operator new[](unsigned long)) converting from SR: 44100 to: 48000 1.08844 New length: 16671 --514-- REDIR: 0x517C130 (operator delete(void*)) redirected to 0x4A1FBF0 (operator delete(void*)) deleting tmpdata --514-- REDIR: 0x517C170 (operator delete[](void*)) redirected to 0x4A20010 (operator delete[](void*)) deleting srcdata deleting sfinfo Done. Asked to load: /home/james/code/sampleplayer/sounds/snare1.wav into slot 1 converting from SR: 44100 to: 48000 1.08844 New length: 46712 deleting tmpdata deleting srcdata deleting sfinfo Done. Asked to load: /home/james/code/sampleplayer/sounds/hat.wav into slot 2 converting from SR: 44100 to: 48000 1.08844 New length: 1359 deleting tmpdata deleting srcdata deleting sfinfo Done. Asked to load: /home/james/code/sampleplayer/sounds/pad1.wav with explicit envelope into slot 3 converting from SR: 44100 to: 48000 1.08844 New length: 271058 --514-- REDIR: 0x5593040 (memmove) redirected to 0x4A21450 (memmove) deleting tmpdata deleting srcdata deleting sfinfo Done. Asked to play slot 3 at vol: 1 Asked to play slot 0 at vol: 0.9 Asked to play slot 2 at vol: 0.9 Asked to play slot 2 at vol: 0.9 Asked to play slot 1 at vol: 0.9 Asked to play slot 2 at vol: 0.9 Asked to play slot 2 at vol: 0.9 Asked to play slot 3 at vol: 1 Asked to play slot 2 at vol: 0.9 Asked to play slot 2 at vol: 0.9 Asked to play slot 0 at vol: 0.9 Asked to play slot 1 at vol: 0.9 Asked to play slot 2 at vol: 0.9 Asked to play slot 2 at vol: 0.9 Asked to play slot 3 at vol: 1 Asked to play slot 0 at vol: 0.9 Asked to play slot 2 at vol: 0.9 Asked to play slot 2 at vol: 0.9 Asked to play slot 1 at vol: 0.9 Asked to play slot 2 at vol: 0.9 Asked to play slot 2 at vol: 0.9 Asked to play slot 3 at vol: 1 Asked to play slot 2 at vol: 0.9 Got OSC quit ==514== ==514== Syscall param write(buf) points to uninitialised byte(s) ==514== at 0x4D52BDB: (within /lib64/libpthread-2.4.so) ==514== by 0x4B2846D: oop_client_deliver_request (client.c:240) ==514== by 0x4B29B24: jack_deactivate (client.c:1834) ==514== by 0x4B29B4F: jack_client_close (client.c:1847) ==514== by 0x404683: jackpart_close() (jackPart.cc:88) ==514== by 0x402425: mainLoop() (sampleplayer.cpp:477) ==514== by 0x40250B: main (sampleplayer.cpp:497) ==514== Address 0x7FEFFE934 is on thread 1's stack --514-- Discarding syms at 0x5A84000-0x5B8F000 in /lib64/libnss_files-2.4.so due to munmap() --514-- Discarding syms at 0x5B8F000-0x5C94000 in /lib64/libnss_dns-2.4.so due to munmap() --514-- Discarding syms at 0x5C94000-0x5DA7000 in /lib64/libresolv-2.4.so due to munmap() ==514== ==514== ERROR SUMMARY: 9 errors from 4 contexts (suppressed: 4 from 1) ==514== ==514== 1 errors in context 1 of 4: ==514== Syscall param write(buf) points to uninitialised byte(s) ==514== at 0x4D52BDB: (within /lib64/libpthread-2.4.so) ==514== by 0x4B2846D: oop_client_deliver_request (client.c:240) ==514== by 0x4B29B24: jack_deactivate (client.c:1834) ==514== by 0x4B29B4F: jack_client_close (client.c:1847) ==514== by 0x404683: jackpart_close() (jackPart.cc:88) ==514== by 0x402425: mainLoop() (sampleplayer.cpp:477) ==514== by 0x40250B: main (sampleplayer.cpp:497) ==514== Address 0x7FEFFE934 is on thread 1's stack ==514== ==514== 1 errors in context 2 of 4: ==514== Syscall param write(buf) points to uninitialised byte(s) ==514== at 0x4D52BDB: (within /lib64/libpthread-2.4.so) ==514== by 0x4B2846D: oop_client_deliver_request (client.c:240) ==514== by 0x4B299B5: jack_activate (client.c:1820) ==514== by 0x404787: jackpart_open(char const*, bool) (jackPart.cc:113) ==514== by 0x4023C4: mainLoop() (sampleplayer.cpp:454) ==514== by 0x40250B: main (sampleplayer.cpp:497) ==514== Address 0x7FEFFE934 is on thread 1's stack ==514== ==514== 1 errors in context 3 of 4: ==514== Syscall param write(buf) points to uninitialised byte(s) ==514== at 0x4D52BDB: (within /lib64/libpthread-2.4.so) ==514== by 0x4B2846D: oop_client_deliver_request (client.c:240) ==514== by 0x4B2B9DF: jack_port_register (port.c:425) ==514== by 0x404774: jackpart_open(char const*, bool) (jackPart.cc:112) ==514== by 0x4023C4: mainLoop() (sampleplayer.cpp:454) ==514== by 0x40250B: main (sampleplayer.cpp:497) ==514== Address 0x7FEFFE914 is on thread 1's stack ==514== ==514== 6 errors in context 4 of 4: ==514== Syscall param write(buf) points to uninitialised byte(s) ==514== at 0x4D52BDB: (within /lib64/libpthread-2.4.so) ==514== by 0x4B2846D: oop_client_deliver_request (client.c:240) ==514== by 0x4B2A416: jack_connect (client.c:1966) ==514== by 0x40484A: jackpart_open(char const*, bool) (jackPart.cc:130) ==514== by 0x4023C4: mainLoop() (sampleplayer.cpp:454) ==514== by 0x40250B: main (sampleplayer.cpp:497) ==514== Address 0x7FEFFE934 is on thread 1's stack --514-- --514-- supp: 4 Fedora-Core-5-hack3-ld24 ==514== ==514== IN SUMMARY: 9 errors from 4 contexts (suppressed: 4 from 1) ==514== ==514== malloc/free: in use at exit: 616 bytes in 4 blocks. ==514== malloc/free: 624 allocs, 620 frees, 8,930,770 bytes allocated. ==514== ==514== searching for pointers to 4 not-freed blocks. ==514== checked 9,203,136 bytes. ==514== ==514== ==514== 16 bytes in 1 blocks are still reachable in loss record 1 of 3 ==514== at 0x4A1EAC7: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==514== by 0x517C6A3: __cxa_get_globals (in /usr/lib64/gcc/x86_64-pc-linux-gnu/3.4.6/libstdc++.so.6.0.3) ==514== by 0x517C4A8: std::uncaught_exception() (in /usr/lib64/gcc/x86_64-pc-linux-gnu/3.4.6/libstdc++.so.6.0.3) ==514== by 0x51534F4: std::basic_ostream >& std::operator<< >(std::basic_ostream >&, char const*) (in /usr/lib64/gcc/x86_64-pc-linux-gnu/3.4.6/libstdc++.so.6.0.3) ==514== by 0x40374C: SP_Mixer::SP_Mixer() (sampleplayer.cpp:297) ==514== by 0x40256F: __static_initialization_and_destruction_0(int, int) (sampleplayer.cpp:351) ==514== by 0x4025CC: _GLOBAL__I_DEBUG (sampleplayer.cpp:561) ==514== by 0x4049E5: (within /home/james/code/sampleplayer/src/sampleplayer/sampleplayer) ==514== by 0x4017F2: (within /home/james/code/sampleplayer/src/sampleplayer/sampleplayer) ==514== ==514== ==514== 56 bytes in 1 blocks are still reachable in loss record 2 of 3 ==514== at 0x4A1EAC7: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==514== by 0x400AD45: _dl_map_object_deps (in /lib64/ld-2.4.so) ==514== by 0x400FBD6: dl_open_worker (in /lib64/ld-2.4.so) ==514== by 0x400C274: _dl_catch_error (in /lib64/ld-2.4.so) ==514== by 0x401036E: _dl_open (in /lib64/ld-2.4.so) ==514== by 0x560D45F: (within /lib64/libc-2.4.so) ==514== by 0x400C274: _dl_catch_error (in /lib64/ld-2.4.so) ==514== by 0x560D3F1: (within /lib64/libc-2.4.so) ==514== by 0x560D507: __libc_dlopen_mode (in /lib64/libc-2.4.so) ==514== by 0x4D545EB: pthread_cancel_init (in /lib64/libpthread-2.4.so) ==514== by 0x4D51297: pthread_cancel (in /lib64/libpthread-2.4.so) ==514== by 0x4B29CC7: jack_client_close (client.c:1869) ==514== ==514== ==514== 544 bytes in 2 blocks are possibly lost in loss record 3 of 3 ==514== at 0x4A2033A: calloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==514== by 0x400EB39: allocate_dtv (in /lib64/ld-2.4.so) ==514== by 0x400EE2D: _dl_allocate_tls (in /lib64/ld-2.4.so) ==514== by 0x4D4DADA: pthread_create@@GLIBC_2.2.5 (in /lib64/libpthread-2.4.so) ==514== by 0x4C44525: lo_server_thread_start (in /usr/lib64/liblo.so.0.6.0) ==514== by 0x4023A6: mainLoop() (sampleplayer.cpp:452) ==514== by 0x40250B: main (sampleplayer.cpp:497) ==514== ==514== LEAK SUMMARY: ==514== definitely lost: 0 bytes in 0 blocks. ==514== possibly lost: 544 bytes in 2 blocks. ==514== still reachable: 72 bytes in 2 blocks. ==514== suppressed: 0 bytes in 0 blocks. --514-- memcheck: sanity checks: 1976 cheap, 80 expensive --514-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use --514-- memcheck: auxmaps: 0 searches, 0 comparisons --514-- memcheck: SMs: n_issued = 180 (2880k, 2M) --514-- memcheck: SMs: n_deissued = 117 (1872k, 1M) --514-- memcheck: SMs: max_noaccess = 524287 (8388592k, 8191M) --514-- memcheck: SMs: max_undefined = 43 (688k, 0M) --514-- memcheck: SMs: max_defined = 439 (7024k, 6M) --514-- memcheck: SMs: max_non_DSM = 127 (2032k, 1M) --514-- memcheck: max sec V bit nodes: 5 (0k, 0M) --514-- memcheck: set_sec_vbits8 calls: 9 (new: 5, updates: 4) --514-- memcheck: max shadow mem size: 6176k, 6M --514-- translate: fast SP updates identified: 5,861 ( 86.5%) --514-- translate: generic_known SP updates identified: 667 ( 9.8%) --514-- translate: generic_unknown SP updates identified: 245 ( 3.6%) --514-- tt/tc: 15,452 tt lookups requiring 16,393 probes --514-- tt/tc: 15,452 fast-cache updates, 8 flushes --514-- transtab: new 6,884 (162,845 -> 2,894,077; ratio 177:10) [0 scs] --514-- transtab: dumped 0 (0 -> ??) --514-- transtab: discarded 423 (9,277 -> ??) --514-- scheduler: 104,912,667 jumps (bb entries). --514-- scheduler: 1,976/26,349 major/minor sched events. --514-- sanity: 1977 cheap, 80 expensive checks. --514-- exectx: 30,011 lists, 193 contexts (avg 0 per list) --514-- exectx: 1,257 searches, 1,381 full compares (1,098 per 1000) --514-- exectx: 2 cmp2, 17 cmp4, 0 cmpAll From drobilla at connect.carleton.ca Mon Jun 26 21:38:15 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Mon Jun 26 21:38:22 2006 Subject: [linux-audio-dev] LADSPA Extension for Extra GUI Data In-Reply-To: <20060626130329.GC3363@bth05w.ABSp.alcatel.be> References: <20060619180343.307d9kslps8400gc@webmail.technetium.net.au> <44966EDE.8030509@technetium.net.au> <1151267440.16229.16.camel@localhost.localdomain> <20060626080711.GC24958@login.ecs.soton.ac.uk> <20060626115312.GB3363@bth05w.ABSp.alcatel.be> <20060626121921.GA27513@login.ecs.soton.ac.uk> <20060626130329.GC3363@bth05w.ABSp.alcatel.be> Message-ID: <1151372295.4795.10.camel@localhost.localdomain> On Mon, 2006-06-26 at 15:03 +0200, Alfons Adriaensen wrote: > On Mon, Jun 26, 2006 at 01:19:21PM +0100, Steve Harris wrote: > > > On Mon, Jun 26, 2006 at 01:53:13 +0200, Alfons Adriaensen wrote: > > > > > If the GUI is in a separate process and connected by e.g. OSC, it > > > could as well be on a machine that doesn't have the plugin files. > > > Or that has a different version of them (for perfectly good reasons). > > > To ensure consistency the GUI should get its plugin descriptions from > > > the host anyway. This works even with POL (Plain Old Ladspa). > > > > True enough, but with POL if the frontend and backend mahcines are different > > architectures or operating systems then you have a problem. > > If send the raw binary data, yes, that's Inviting Trouble (IT). > But if it's correctly OSC encoded there shouldn't be a problem. > Anyway I guess a host would not use the raw LADSPA data, but a > rather a more general format that it could use to describe its > internal modules or other plugin formats as well. The GUI doesn't > need to know if a module is built-in, LADSPA, LV2, or any other > format. One more reason for not having it read the LV2 itself. As the author of such a host, I can tell you it's definitely an absolute godsend to be able to have the client read the data file directly. -DR- From jack.oquin at gmail.com Mon Jun 26 22:07:19 2006 From: jack.oquin at gmail.com (Jack O'Quin) Date: Mon Jun 26 22:07:34 2006 Subject: [Jackit-devel] [linux-audio-dev] What valgrind says In-Reply-To: <20060626230543.GG10261@fitz.Belkin> References: <20060624222612.GC10261@fitz.Belkin> <1151193842.10221.99.camel@localhost.localdomain> <20060625102956.ab42acb6.mle+la@mega-nerd.com> <1151267685.16229.18.camel@localhost.localdomain> <1151268562.2931.268.camel@mindpipe> <1151284988.16229.22.camel@localhost.localdomain> <20060626230543.GG10261@fitz.Belkin> Message-ID: On 6/26/06, james@dis-dot-dat.net wrote: > On Mon, 26 Jun, 2006 at 10:16AM -0500, Jack O'Quin spake thus: > > libjack seems OK already, but there was an unitialied char > > written by jackd. I fixed that and committed it as [0.102.18]. > > > > I don't have valgrind set up correctly on my new laptop. Could > > one of you please update to the latest SVN version and verify > > whether this fixes that warning message? > > OK, since I brought it up I thought I'd better test it out. Sorry, > but I still get the same problem. > > Compiling from the raw SVN-delivered source instead of emerging it > might have given a bit of a hint, though. Valgrind is now able to > give the location inside jack that the error occurs: client.c, line > 240 > > I've attached a log from valgrind (includes my own debugging output, > easily ignored). OK, I see it now. All those uninitialized write complaints are due to the fact that jack_request_t is a union. Most requests don't need (or want) to fill in all the bytes, just the ones that matter for that RequestType. There are jack_request_t structs used all over the place. The only solution I can think of that would make valgrind happy would be to initialize them all to zeroes before filling them in. While that would eliminate these complaints, I have some doubts that we really want to make all those changes. There is some risk of introducing real bugs while fixing them. Those valgrind warnings really *are* annoying, of course. -- joq From drobilla at connect.carleton.ca Mon Jun 26 22:42:57 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Mon Jun 26 22:43:22 2006 Subject: [linux-audio-dev] LADSPA Extension for Extra GUI Data In-Reply-To: <20060626180537.GS2312@replic.net> References: <20060619180343.307d9kslps8400gc@webmail.technetium.net.au> <44966EDE.8030509@technetium.net.au> <1151267440.16229.16.camel@localhost.localdomain> <20060626080711.GC24958@login.ecs.soton.ac.uk> <20060626115312.GB3363@bth05w.ABSp.alcatel.be> <20060626121921.GA27513@login.ecs.soton.ac.uk> <20060626130329.GC3363@bth05w.ABSp.alcatel.be> <20060626180537.GS2312@replic.net> Message-ID: <1151376177.4795.16.camel@localhost.localdomain> On Mon, 2006-06-26 at 18:05 +0000, carmen wrote: > > > > To ensure consistency the GUI should get its plugin descriptions from > > > > the host anyway. This works even with POL (Plain Old Ladspa). > > > rather a more general format that it could use to describe its > > internal modules or other plugin formats as well. The GUI doesn't > > in theory, this (client-readable metadata) shouldnt be a selling point. i mean if most hosts provided a nice API to query for plugin parameters. most don't.. For one this is a really complicated thing to do (unless you want to just fire SPARQL queries directly over OSC which is a bit.. well.. different), and two this assumes the transport is reliable, which in the case of OSC over UDP isn't true. Trust me. :) > it would be great for people to be able to make controllers for plugins, without the author of RoseGarden or Seq24 needing to ad some OM-style OSC-query-of-plugin-namespace I agree, and a good metadata querying system would be a very handy thing, but the nice thing about the data file is that it doesn't HAVE to be done that way, and flexibility is always good. As an example of where this is handy I'm going to do node previewing in Om's (now Ingen's) load plugin dialog by reading the data file directly. There's no node to query yet, and instantiating one is no good. There are solutions (making plugins a first class object and querying that), but why should the engine have to change to accomodate purely GUI related features? Plus, there's tons of other super fun things to be done with all that tasty graph data client side :] -DR- From rlrevell at joe-job.com Tue Jun 27 11:23:52 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Tue Jun 27 11:24:00 2006 Subject: [Freebob-devel] [linux-audio-dev] ieee1394 deadlock on RT kernels In-Reply-To: <44A044FD.6020201@joow.be> References: <449F1757.3080207@joow.be> <1151277118.2931.272.camel@mindpipe> <449F96B2.1000807@joow.be> <1151330936.2872.129.camel@grayson> <449FF461.908@joow.be> <1151337451.26257.62.camel@mindpipe> <44A02FF8.3030901@joow.be> <1151349863.26257.123.camel@mindpipe> <44A03908.3050803@joow.be> <1151351871.26257.132.camel@mindpipe> <44A044FD.6020201@joow.be> Message-ID: <1151421832.2899.23.camel@mindpipe> On Mon, 2006-06-26 at 22:35 +0200, Pieter Palmers wrote: > Another strange thing is: why doesn't the tasklet finish, so that it > can be 'unscheduled'? I have my IRQ priorities higher than any other > RT threads, so I would expect that the tasklet can finish. Or is > tasklet_kill not-preemtible? that would be very strange as I would > expect that busy waiting on something in a non-preemptible code path > on a single-cpu system always deadlocks. When are you going to report this to Ingo + LKML + the other -rt developers? Lee From pieterp at joow.be Tue Jun 27 15:20:31 2006 From: pieterp at joow.be (Pieter Palmers) Date: Tue Jun 27 15:20:33 2006 Subject: [Freebob-devel] [linux-audio-dev] ieee1394 deadlock on RT kernels In-Reply-To: <1151421832.2899.23.camel@mindpipe> References: <449F1757.3080207@joow.be> <1151277118.2931.272.camel@mindpipe> <449F96B2.1000807@joow.be> <1151330936.2872.129.camel@grayson> <449FF461.908@joow.be> <1151337451.26257.62.camel@mindpipe> <44A02FF8.3030901@joow.be> <1151349863.26257.123.camel@mindpipe> <44A03908.3050803@joow.be> <1151351871.26257.132.camel@mindpipe> <44A044FD.6020201@joow.be> <1151421832.2899.23.camel@mindpipe> Message-ID: <44A184FF.7090501@joow.be> Lee Revell wrote: > On Mon, 2006-06-26 at 22:35 +0200, Pieter Palmers wrote: >> Another strange thing is: why doesn't the tasklet finish, so that it >> can be 'unscheduled'? I have my IRQ priorities higher than any other >> RT threads, so I would expect that the tasklet can finish. Or is >> tasklet_kill not-preemtible? that would be very strange as I would >> expect that busy waiting on something in a non-preemptible code path >> on a single-cpu system always deadlocks. > > When are you going to report this to Ingo + LKML + the other -rt > developers? > After I do the printk testing to pinpoint the problem a little more precise (as you suggested yesterday). However, I didn't feel like iterating through the recompile kernel/crash/reboot cycle even more yesterday. Is there any underlying reason for this question? Pieter From rlrevell at joe-job.com Tue Jun 27 15:30:20 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Tue Jun 27 15:30:25 2006 Subject: [Freebob-devel] [linux-audio-dev] ieee1394 deadlock on RT kernels In-Reply-To: <44A184FF.7090501@joow.be> References: <449F1757.3080207@joow.be> <1151277118.2931.272.camel@mindpipe> <449F96B2.1000807@joow.be> <1151330936.2872.129.camel@grayson> <449FF461.908@joow.be> <1151337451.26257.62.camel@mindpipe> <44A02FF8.3030901@joow.be> <1151349863.26257.123.camel@mindpipe> <44A03908.3050803@joow.be> <1151351871.26257.132.camel@mindpipe> <44A044FD.6020201@joow.be> <1151421832.2899.23.camel@mindpipe> <44A184FF.7090501@joow.be> Message-ID: <1151436620.2899.99.camel@mindpipe> On Tue, 2006-06-27 at 21:20 +0200, Pieter Palmers wrote: > Lee Revell wrote: > > On Mon, 2006-06-26 at 22:35 +0200, Pieter Palmers wrote: > >> Another strange thing is: why doesn't the tasklet finish, so that it > >> can be 'unscheduled'? I have my IRQ priorities higher than any other > >> RT threads, so I would expect that the tasklet can finish. Or is > >> tasklet_kill not-preemtible? that would be very strange as I would > >> expect that busy waiting on something in a non-preemptible code path > >> on a single-cpu system always deadlocks. > > > > When are you going to report this to Ingo + LKML + the other -rt > > developers? > > > After I do the printk testing to pinpoint the problem a little more > precise (as you suggested yesterday). > > However, I didn't feel like iterating through the recompile > kernel/crash/reboot cycle even more yesterday. > > Is there any underlying reason for this question? Only that you seem to have found a bug in -rt and I'd like to get it fixed. Lee From nettings at folkwang-hochschule.de Wed Jun 28 15:55:01 2006 From: nettings at folkwang-hochschule.de (Joern Nettingsmeier) Date: Wed Jun 28 15:55:37 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] [admin] linux-audio-* maintainer wanted... In-Reply-To: <20060624092359.GA7310@charly.SWORD> References: <449ACFF6.9050501@folkwang-hochschule.de> <20060624092359.GA7310@charly.SWORD> Message-ID: <44A2DE95.9090009@folkwang-hochschule.de> Thorsten Wilms wrote: >> as an added bonus, there is also the job of cleaning up the old >> lad.linuxaudio.org page, throwing out all the obsolete stuff (i.e. >> everything except the subscription information and the contrib/ section) >> and maybe linking to all the excellent documentation efforts elsewhere :) > > Now this I might be interested in. thanks thorsten for this kind offer. you've done great web work in the past, and i think it's going to be a great improvement over the current code which was written by some clueless moron ages ago in php3 on a 2.0.36 kernel for apache 1.2 and then hacked to pieces beyond recognition over the course of several years.... ladies and gentlemen, i give you mr thorsten wilms as the new lad.linuxaudio.org maintainer, and judging by the work he has done for other linux audio sites, there will come a time when that page will no longer be a hall of shame for yours truly :-D best regards, j?rn -- j?rn nettingsmeier home://germany/45128 essen/lortzingstr. 11/ http://spunk.dnsalias.org phone://+49/201/491621 if you are a free (as in "free speech") software developer and you happen to be travelling near my home, drop me a line and come round for a free (as in "free beer") beer. :-D From james at dis-dot-dat.net Thu Jun 29 08:38:00 2006 From: james at dis-dot-dat.net (james@dis-dot-dat.net) Date: Thu Jun 29 08:38:11 2006 Subject: [linux-audio-dev] Envelopes Message-ID: <20060629123800.GM10261@fitz.Belkin> Hi peeps. I've been writing an app that requires volume envelopes. I've implemented the envelope part myself, but I was wondering if there was a library about to do it. I ask because I realised that probably everyone on this list has written something that uses envelopes, and probably written it better and with more features than I have. More generally, is there a library/toolkit of audio bits and bobs about? James From radarsat1 at gmail.com Thu Jun 29 09:57:11 2006 From: radarsat1 at gmail.com (Stephen Sinclair) Date: Thu Jun 29 09:57:19 2006 Subject: [linux-audio-dev] Envelopes In-Reply-To: <20060629123800.GM10261@fitz.Belkin> References: <20060629123800.GM10261@fitz.Belkin> Message-ID: <9b3e2dc20606290657t58d2e0aci85e0537741a5e557@mail.gmail.com> You might want to check out the STK. It has an object called Asymp, which can generate simple exponential envelopes, and also an ADSR object. It also has tons of other goodies. As a bonus, it's cross-platform. http://ccrma.stanford.edu/software/stk/ Here's the class list: http://ccrma.stanford.edu/software/stk/hierarchy.html Steve On 6/29/06, james@dis-dot-dat.net wrote: > Hi peeps. > > I've been writing an app that requires volume envelopes. I've > implemented the envelope part myself, but I was wondering if there > was a library about to do it. > > I ask because I realised that probably everyone on this list has > written something that uses envelopes, and probably written it > better and with more features than I have. > > More generally, is there a library/toolkit of audio bits and bobs > about? > > James > > From james at dis-dot-dat.net Thu Jun 29 11:43:50 2006 From: james at dis-dot-dat.net (james@dis-dot-dat.net) Date: Thu Jun 29 11:44:01 2006 Subject: [linux-audio-dev] Envelopes In-Reply-To: <9b3e2dc20606290657t58d2e0aci85e0537741a5e557@mail.gmail.com> References: <20060629123800.GM10261@fitz.Belkin> <9b3e2dc20606290657t58d2e0aci85e0537741a5e557@mail.gmail.com> Message-ID: <20060629154350.GN10261@fitz.Belkin> On Thu, 29 Jun, 2006 at 09:57AM -0400, Stephen Sinclair spake thus: > You might want to check out the STK. > It has an object called Asymp, which can generate simple exponential > envelopes, and also an ADSR object. It also has tons of other > goodies. > > As a bonus, it's cross-platform. > > http://ccrma.stanford.edu/software/stk/ > > Here's the class list: > http://ccrma.stanford.edu/software/stk/hierarchy.html Aceness. I ask and I receive. Now, where can I get 1 million pounds for free? James > Steve > > > On 6/29/06, james@dis-dot-dat.net wrote: > >Hi peeps. > > > > I've been writing an app that requires volume envelopes. I've > > implemented the envelope part myself, but I was wondering if there > > was a library about to do it. > > > > I ask because I realised that probably everyone on this list has > > written something that uses envelopes, and probably written it > > better and with more features than I have. > > > > More generally, is there a library/toolkit of audio bits and bobs > > about? > > > >James > > > > > From lars.luthman at gmail.com Thu Jun 29 11:52:52 2006 From: lars.luthman at gmail.com (Lars Luthman) Date: Thu Jun 29 11:53:00 2006 Subject: [linux-audio-dev] Envelopes In-Reply-To: <20060629154350.GN10261@fitz.Belkin> References: <20060629123800.GM10261@fitz.Belkin> <9b3e2dc20606290657t58d2e0aci85e0537741a5e557@mail.gmail.com> <20060629154350.GN10261@fitz.Belkin> Message-ID: <1151596372.7508.4.camel@c-5f75e055.456-1-64736c13.cust.bredbandsbolaget.se> On Thu, 2006-06-29 at 16:43 +0100, james@dis-dot-dat.net wrote: > On Thu, 29 Jun, 2006 at 09:57AM -0400, Stephen Sinclair spake thus: > > You might want to check out the STK. > > It has an object called Asymp, which can generate simple exponential > > envelopes, and also an ADSR object. It also has tons of other > > goodies. > > > > As a bonus, it's cross-platform. > > > > http://ccrma.stanford.edu/software/stk/ > > > > Here's the class list: > > http://ccrma.stanford.edu/software/stk/hierarchy.html > > Aceness. I ask and I receive. > > Now, where can I get 1 million pounds for free? I get emails about _that_ all the time without even asking. -- Lars Luthman - please encrypt any email sent to me if possible PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E 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: 191 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060629/6adc4bdc/attachment.bin From dlphillips at woh.rr.com Thu Jun 29 12:39:16 2006 From: dlphillips at woh.rr.com (Dave Phillips) Date: Thu Jun 29 12:28:24 2006 Subject: [linux-audio-dev] Envelopes In-Reply-To: <20060629154350.GN10261@fitz.Belkin> References: <20060629123800.GM10261@fitz.Belkin> <9b3e2dc20606290657t58d2e0aci85e0537741a5e557@mail.gmail.com> <20060629154350.GN10261@fitz.Belkin> Message-ID: <44A40234.3050503@woh.rr.com> james@dis-dot-dat.net wrote: >Now, where can I get 1 million pounds for free? > > There's about a million pounds of something at the White House in Washington DC... Born in the USA, dp From dlphillips at woh.rr.com Thu Jun 29 12:47:27 2006 From: dlphillips at woh.rr.com (Dave Phillips) Date: Thu Jun 29 12:36:34 2006 Subject: [linux-audio-dev] Envelopes In-Reply-To: <44A40234.3050503@woh.rr.com> References: <20060629123800.GM10261@fitz.Belkin> <9b3e2dc20606290657t58d2e0aci85e0537741a5e557@mail.gmail.com> <20060629154350.GN10261@fitz.Belkin> <44A40234.3050503@woh.rr.com> Message-ID: <44A4041F.6050801@woh.rr.com> Dave Phillips wrote: > james@dis-dot-dat.net wrote: > >> Now, where can I get 1 million pounds for free? >> >> > There's about a million pounds of something at the White House in > Washington DC... Sorry, I should have mentioned Congress too. Wouldn't want anyone to feel left out... Yours for the taking. I'll be glad to see it go. Best, dp From b0ef at esben-stien.name Thu Jun 29 18:49:23 2006 From: b0ef at esben-stien.name (Esben Stien) Date: Thu Jun 29 16:54:29 2006 Subject: [linux-audio-dev] Envelopes In-Reply-To: <9b3e2dc20606290657t58d2e0aci85e0537741a5e557@mail.gmail.com> (Stephen Sinclair's message of "Thu, 29 Jun 2006 09:57:11 -0400") References: <20060629123800.GM10261@fitz.Belkin> <9b3e2dc20606290657t58d2e0aci85e0537741a5e557@mail.gmail.com> Message-ID: <87zmfvh91o.fsf@esben-stien.name> "Stephen Sinclair" writes: > check out the STK. I don't think this is free software, btw. -- Esben Stien is b0ef@e s a http://www. s t n m irc://irc. b - i . e/%23contact sip:b0ef@ e e jid:b0ef@ n n From forest at alittletooquiet.net Thu Jun 29 18:35:58 2006 From: forest at alittletooquiet.net (Forest Bond) Date: Thu Jun 29 18:36:09 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt Message-ID: <20060629223558.GB20075@storm.local.network> Hello everyone, I don't recall posting here in the past, although I have several hundred LAD mails in .Mail... Nice to meet you, anyway. I've been looking at fst, and was going to package it for Ubuntu. I had used dssi-vst in the past. My big problem is this: neither of the two save current settings for kontakt, my sampler of choice (there is no free equivalent, as far as I can tell, or I would use it). I've now decided that fst has better long-term potential to do what I need, mainly due to 1) lash support 2) not having to work through DSSI, which probably cripples its ability to be able to save ALL parameters. It would seem that fst doesn't have full VST 2.0 support, from looking at the source code. I've never written anything remotely VST-related, but would like to add such support to fst. I see Kjetil S. Matheussen's name in the source for vsti.c. I'm hoping he has some guidance for me. Kjetil, and LAD's in general, can you confirm my observations, and do you have an opinion on whether or not my goal is feasible? thanks, Forest -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: Digital signature Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060629/47a7e22c/attachment.bin From paul at linuxaudiosystems.com Thu Jun 29 19:29:52 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Thu Jun 29 19:29:24 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <20060629223558.GB20075@storm.local.network> References: <20060629223558.GB20075@storm.local.network> Message-ID: <1151623792.10662.5.camel@localhost.localdomain> On Thu, 2006-06-29 at 18:35 -0400, Forest Bond wrote: > I've been looking at fst, and was going to package it for Ubuntu. you cannot legally package FST. please do not do this. its not likely that steinberg will come after you, and neither torben nor I are likely to either, but its a violation of various license agreements. i don't like this, torben doesn't like it, but its the current situation. > It would seem that fst doesn't have full VST 2.0 support, from looking at the > source code. I've never written anything remotely VST-related, but would like > to add such support to fst. FST doesn't even support VST SDK 2.4, which steinberg has pushed hard for everyone to switch to. > I see Kjetil S. Matheussen's name in the source for vsti.c. I'm hoping he has > some guidance for me. Kjetil wrote vstserver, he didn't write any of FST (other than a patch or two). He does know quite a bit about VST though. Both Torben and myself can help out, and in addition, Ardour hosts VST's slightly more fully than FST itself (though using the same basic code to handle the integration of win32 DLL's and run a win32 GUI). what parts of VST do you want to add support for, other than saving chunks? --p From forest at alittletooquiet.net Thu Jun 29 20:37:07 2006 From: forest at alittletooquiet.net (Forest Bond) Date: Thu Jun 29 20:37:42 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <1151626610.10662.11.camel@localhost.localdomain> References: <20060629223558.GB20075@storm.local.network> <1151623792.10662.5.camel@localhost.localdomain> <20060630000055.GD20075@storm.local.network> <1151626610.10662.11.camel@localhost.localdomain> Message-ID: <20060630003707.GE20075@storm.local.network> Thanks for clarifying the licensing issues. I think I knew that at some point. What are the odds of changing the FST license to GPL-with-exceptions? > what parts of the full 2.0 spec are you thinking about? Ack. You got me; I don't know enough about the spec to have an answer. But Kontakt doesn't save it's state when asked nicely by any linux VST host I'm aware of. I'll start by trying to fix that. > > There doesn't seem to be any tutorial-type documentation reguarding VST. > there isn't. the vst-plugins mailing list is full of people endlessly > seeking clarification of different aspects of the API. nobody has > definitive answers. I had feared this. To make matters worse, I've not done any serious audio development before. Bits in, bits out, though, isn't it? :) -Forest -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: Digital signature Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060629/aee25dcd/attachment-0001.bin From seablaede at gmail.com Thu Jun 29 21:54:26 2006 From: seablaede at gmail.com (Thomas Vecchione) Date: Thu Jun 29 20:50:13 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <20060630003707.GE20075@storm.local.network> References: <20060629223558.GB20075@storm.local.network> <1151623792.10662.5.camel@localhost.localdomain> <20060630000055.GD20075@storm.local.network> <1151626610.10662.11.camel@localhost.localdomain> <20060630003707.GE20075@storm.local.network> Message-ID: <44A48452.9030205@gmail.com> > What are the odds of changing the FST license to GPL-with-exceptions? Problem is, even if that did happen(LGPL I believe would cover it?) It isnt just the fst license that is the problem. It is Steinberg's license on the VST SDK. And chances of THAT license being changed... well I wouldnt hold my breath that is for sure;) Seablade From forest at alittletooquiet.net Thu Jun 29 21:07:30 2006 From: forest at alittletooquiet.net (Forest Bond) Date: Thu Jun 29 21:07:40 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <44A48452.9030205@gmail.com> References: <20060629223558.GB20075@storm.local.network> <1151623792.10662.5.camel@localhost.localdomain> <20060630000055.GD20075@storm.local.network> <1151626610.10662.11.camel@localhost.localdomain> <20060630003707.GE20075@storm.local.network> <44A48452.9030205@gmail.com> Message-ID: <20060630010730.GF20075@storm.local.network> > Problem is, even if that did happen(LGPL I believe would cover it?) It > isnt just the fst license that is the problem. It is Steinberg's > license on the VST SDK. And chances of THAT license being changed... > well I wouldnt hold my breath that is for sure;) I believe changing the fst license (only) could result in fst binaries being redistributable... -Forest -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: Digital signature Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060629/d72196f9/attachment.bin From piem at altern.org Thu Jun 29 21:43:27 2006 From: piem at altern.org (Paul Brossier) Date: Thu Jun 29 21:44:23 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] [admin] linux-audio-* maintainer wanted... In-Reply-To: <20060624155119.GB7310@charly.SWORD> References: <449ACFF6.9050501@folkwang-hochschule.de> <20060624092359.GA7310@charly.SWORD> <449D55D8.5020905@folkwang-hochschule.de> <20060624155119.GB7310@charly.SWORD> Message-ID: <20060630014327.GA28820@pomme.anchorland.local> Hi all, On Sat, Jun 24, 2006 at 05:51:19PM +0200, Thorsten Wilms wrote: > On Sat, Jun 24, 2006 at 05:10:16PM +0200, Joern Nettingsmeier wrote: > > > >What exactly does maintainership of the lists encompass? > > > > basically moderation of linux-audio-announce and helping people who have > > problems with their accounts. the latter has become a great problem > > lately, because the admin adresses are being drowned in spam :( > > > > but basically it's all about handling mailman, which has a neat and > > friendly web interface. but some extra effort spent on spam filtering > > would certainly ease the job in the long run... > > > If it was only moderation ... not knowing that much about email > and leaving all spam handling to my free-mail providers, I'm not > the right one for this job i should be able to help with moderation and spam filtering. J?rn, let me know if and how i can help. also, if i understand well, it could be a good idea to have more than one moderators. preferably in different time zones... greetings, Paul From radarsat1 at gmail.com Thu Jun 29 21:57:58 2006 From: radarsat1 at gmail.com (Stephen Sinclair) Date: Thu Jun 29 21:58:07 2006 Subject: [linux-audio-dev] Envelopes In-Reply-To: <87zmfvh91o.fsf@esben-stien.name> References: <20060629123800.GM10261@fitz.Belkin> <9b3e2dc20606290657t58d2e0aci85e0537741a5e557@mail.gmail.com> <87zmfvh91o.fsf@esben-stien.name> Message-ID: <9b3e2dc20606291857iaf26261n95906ba0e9a49e48@mail.gmail.com> > > check out the STK. > > I don't think this is free software, btw. They aren't too specific about the license but I think it's "public domain". I should ask Gary to be more clear about that on the site... Anyways, it is included as a package in Debian (libstk0c2a), and they are one of the best judges on software Freedom I know of. Here's the copyright file: http://packages.debian.org/changelogs/pool/main/s/stk/stk_4.2.0-9/libstk0c2a.copyright ------------------------------------- Debianized by Guenter Geiger (Debian/GNU) on Thu, 22 Apr 2004 10:55:08 +0200. http://ccrma.stanford.edu/software/stk/ Authors: Perry Cook and Gary P. Scavone Copyright: This software was designed and created to be made publicly available for free, primarily for academic purposes, so if you use it, pass it on with this documentation, and for free. --------------------------------------- But you're right in the sense that they aren't specific in their license about derivative works, which is an important part of the GPL. Steve From seablaede at gmail.com Fri Jun 30 00:52:30 2006 From: seablaede at gmail.com (Thomas Vecchione) Date: Thu Jun 29 23:48:14 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <20060630010730.GF20075@storm.local.network> References: <20060629223558.GB20075@storm.local.network> <1151623792.10662.5.camel@localhost.localdomain> <20060630000055.GD20075@storm.local.network> <1151626610.10662.11.camel@localhost.localdomain> <20060630003707.GE20075@storm.local.network> <44A48452.9030205@gmail.com> <20060630010730.GF20075@storm.local.network> Message-ID: <44A4AE0E.6000108@gmail.com> Hmm you may be right if it is kept in a purely binary form, any use with open source technology with the GPL though would require it not be distributed as per this section of the licensing terms... ------------------- The Licensee has no permission to sell, licence, give-away and/or distribute the VST PlugIn Interface technology or parts of it in anyway, on any medium, including the Internet, to any other person, including sub-licensors of the Licensee or companies where the Licensee has any involvement. This includes re-working this specification, or reverse-engineering any products based upon this specification. ------------------- As such it would not be able to be transfered with Lash on which FST depends according to its webpage. So to distribute a binary version of FST would violate the GPL license on Lash as well. The thing about changing a license on open source projects is the fact that many developers submit their code under the GPL if the project is licensed under the GPL. As such in order to change it you have to get permission from all of those developers to use their code with a different license. At least that is my understanding of all of this. As such if all projects involved were licensed under the LGPL and the work was released as a pre-compiled lib to link to I THINK(Key word) it would be legal. Getting to that point however is extraordinarily difficult though. Add on top of that though it would have to be statically linked to prevent api breakage on other projects like Wine(Which is LGPL I believe) and each version of wine tends to run plugins through FST to varying degrees of success, resulting in many people using very specific versions of wine to compile fst with, not just the most recent, as I am sure you are aware from previous posts you have made. Seablade From tomszilagyi at gmail.com Fri Jun 30 05:53:01 2006 From: tomszilagyi at gmail.com (Tom Szilagyi) Date: Fri Jun 30 05:54:17 2006 Subject: [linux-audio-dev] [ANN] Aqualung 0.9beta5 released Message-ID: <44A4F47D.3010201@gmail.com> Aqualung: Music Player for GNU/Linux http://aqualung.sf.net Release 0.9beta5 It is our greatest pleasure to announce the fifth official beta release of Aqualung. Some features you'd rarely stumble upon in other players (at least not too many of them at once): * Gapless playback (designed for this from the ground up) * High quality decoders (eg. libMAD for mp3), many supported formats * High-quality sample rate conversion support via libsamplerate * LADSPA support * Music Store for organizing your music * And much, much more... We hope you will enjoy this release. The release ChangeLog follows below. 2006-06-30 Tom Szilagyi * Aqualung 0.9beta5 http://aqualung.sf.net This is a new milestone release after 17 months of silent development. Large parts of the program have been rewritten, refactored, fixed, etc. A multitude of new features have been added to the software, which now weighs into Open Source with about 30,000 lines of GPL'ed source code, all written by a handful of free-time developers (no, you won't need your whole hand). It won't make too much sense to precisely list every change made to the sources during this period - the list would be prohibitively lengthy. For the curious, the mailing list archive is recommended. The most important, high-level changes are summarized below. * Group CDs in the Playlist via "Album mode". Shuffle between records but play their contents in order! * Statusbars in Playlist and Music Store display statistics and other data. * Multiple Music Stores are supported - useful for separate genres, file formats or for music mounted from different file servers via NFS. * CDDB support! * iFP driver support for integrating with iRiver HW players! * Completely reworked Settings dialog, the new control center! * Embed Playlist into Main window for a more compact look! * Search facility for Music Store and Playlist. * Add support for Musepack (via libmpcdec), Monkey's Audio, Ogg Speex. * Rudimentary album art (cover display) support. * RVA-related work, improved metadata support. * Fixed a boatload of bugs concerning cyrillic filenames, etc. * MP3 improvements (file recognition, clipping, seeking...) * Better fault tolerance in Ogg Vorbis decoder. * Various GUI fixes, new command line options, etc, etc. * Improved build system for skins, icons, etc. * New skins (Ocean, Plain), new Logo (see About box)! ;-) * Better RT behaviour with Jack output. * Compiles and runs on AMD64 (thanks to Mark Knecht for testing)! From james at dis-dot-dat.net Fri Jun 30 06:14:42 2006 From: james at dis-dot-dat.net (james@dis-dot-dat.net) Date: Fri Jun 30 06:14:52 2006 Subject: [linux-audio-dev] Envelopes In-Reply-To: <44A40234.3050503@woh.rr.com> References: <20060629123800.GM10261@fitz.Belkin> <9b3e2dc20606290657t58d2e0aci85e0537741a5e557@mail.gmail.com> <20060629154350.GN10261@fitz.Belkin> <44A40234.3050503@woh.rr.com> Message-ID: <20060630101442.GP10261@fitz.Belkin> On Thu, 29 Jun, 2006 at 12:39PM -0400, Dave Phillips spake thus: > james@dis-dot-dat.net wrote: > > >Now, where can I get 1 million pounds for free? > > > > > There's about a million pounds of something at the White House in > Washington DC... > > Born in the USA, I was born in the UK, and I think I'm missing the joke. James > dp > > From mista.tapas at gmx.net Fri Jun 30 06:21:42 2006 From: mista.tapas at gmx.net (Florian Paul Schmidt) Date: Fri Jun 30 06:22:16 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] [ANN] Aqualung 0.9beta5 released In-Reply-To: <44A4F47D.3010201@gmail.com> References: <44A4F47D.3010201@gmail.com> Message-ID: <20060630122142.0e1d2f18@mango.fruits> On Fri, 30 Jun 2006 11:53:01 +0200 Tom Szilagyi wrote: > Aqualung: Music Player for GNU/Linux > > http://aqualung.sf.net > > Release 0.9beta5 Damn you beat us to it. See these two mailing list posts: http://elists.resynthesize.com/linux-audio-users/2006/06/1609137/ http://elists.resynthesize.com/linux-audio-users/2006/06/1609170/ Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org From v2 at iki.fi Fri Jun 30 06:34:31 2006 From: v2 at iki.fi (Sampo Savolainen) Date: Fri Jun 30 06:35:08 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] [ANN] Aqualung 0.9beta5 released Message-ID: <1151663670.44a4fe370237c@www2.helsinki.fi> Quoting Tom Szilagyi : > Aqualung: Music Player for GNU/Linux > > http://aqualung.sf.net > > Release 0.9beta5 > > > It is our greatest pleasure to announce the fifth official beta > release of Aqualung. Some features you'd rarely stumble upon in > other players (at least not too many of them at once): Great news! Aqualung is starting to look like a very good option for a music player. A few gripes though: a) I would like to have a notification area icon to show/hide aqualung b) There seems no easy way to import my existing collection of music. I can select individual files from one directory, but whole directories. My collection is divided into directories and subdirectories. (artist/album/track.ogg) Also, I found the metadata option a bit confusing: why doesn't aqualung use metadata (id3's, etc.) provided by the audio files automatically? I had to enable it explicitly. Just my 0.02? Sampo From james at dis-dot-dat.net Fri Jun 30 06:48:55 2006 From: james at dis-dot-dat.net (james@dis-dot-dat.net) Date: Fri Jun 30 06:49:02 2006 Subject: [linux-audio-dev] Envelopes In-Reply-To: <9b3e2dc20606291857iaf26261n95906ba0e9a49e48@mail.gmail.com> References: <20060629123800.GM10261@fitz.Belkin> <9b3e2dc20606290657t58d2e0aci85e0537741a5e557@mail.gmail.com> <87zmfvh91o.fsf@esben-stien.name> <9b3e2dc20606291857iaf26261n95906ba0e9a49e48@mail.gmail.com> Message-ID: <20060630104855.GQ10261@fitz.Belkin> On Thu, 29 Jun, 2006 at 09:57PM -0400, Stephen Sinclair spake thus: > >> check out the STK. > > > >I don't think this is free software, btw. > > They aren't too specific about the license but I think it's "public domain". > I should ask Gary to be more clear about that on the site... > > Anyways, it is included as a package in Debian (libstk0c2a), and they > are one of the best judges on software Freedom I know of. Hmm. No Gentoo ebuild in the normal tree, though. Unusual for Debian to have something Gentoo doesn't. > Here's the copyright file: > > http://packages.debian.org/changelogs/pool/main/s/stk/stk_4.2.0-9/libstk0c2a.copyright > > Debianized by Guenter Geiger (Debian/GNU) on > Thu, 22 Apr 2004 10:55:08 +0200. > > http://ccrma.stanford.edu/software/stk/ > > Authors: Perry Cook and Gary P. Scavone > > Copyright: > This software was designed and created to be made publicly available > for free, primarily for academic purposes, so if you use it, pass it > on with this > documentation, and for free. > > But you're right in the sense that they aren't specific in their > license about derivative works, which is an important part of the GPL. > > Steve > From dlphillips at woh.rr.com Fri Jun 30 07:01:42 2006 From: dlphillips at woh.rr.com (Dave Phillips) Date: Fri Jun 30 06:50:44 2006 Subject: [linux-audio-dev] Envelopes In-Reply-To: <20060630101442.GP10261@fitz.Belkin> References: <20060629123800.GM10261@fitz.Belkin> <9b3e2dc20606290657t58d2e0aci85e0537741a5e557@mail.gmail.com> <20060629154350.GN10261@fitz.Belkin> <44A40234.3050503@woh.rr.com> <20060630101442.GP10261@fitz.Belkin> Message-ID: <44A50496.6030102@woh.rr.com> james@dis-dot-dat.net wrote: >On Thu, 29 Jun, 2006 at 12:39PM -0400, Dave Phillips spake thus: > > >>james@dis-dot-dat.net wrote: >> >> >> >>>Now, where can I get 1 million pounds for free? >>> >>> >>> >>> >>There's about a million pounds of something at the White House in >>Washington DC... >> >>Born in the USA, >> >> > >I was born in the UK, and I think I'm missing the joke. > > It's a currency conversion joke (a poor one too). We use dollars for $$$ and pounds as a measure of weight. Ergo: There's a million pounds of (descriptive noun deleted) on Capitol Hill. Ah, for the days before Babel, when all men spoke one language. I think it was a proto-BASIC... Best, dp From rah at bash.sh Fri Jun 30 06:57:52 2006 From: rah at bash.sh (Robert Ham) Date: Fri Jun 30 06:58:05 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <44A4AE0E.6000108@gmail.com> References: <20060629223558.GB20075@storm.local.network> <1151623792.10662.5.camel@localhost.localdomain> <20060630000055.GD20075@storm.local.network> <1151626610.10662.11.camel@localhost.localdomain> <20060630003707.GE20075@storm.local.network> <44A48452.9030205@gmail.com> <20060630010730.GF20075@storm.local.network> <44A4AE0E.6000108@gmail.com> Message-ID: <20060630105752.GA13275@teasel.arb.net> On Thu, Jun 29, 2006 at 09:52:30PM -0700, Thomas Vecchione wrote: > At least that is my understanding of all of this. As such if all > projects involved were licensed under the LGPL ... [ Long discussion > of relicensing ] [ Hello all. Yes, I am still alive :) ] The issue here is that Mr Bond wants a sampler like Kontakt that works with Linux audio systems and saves its state. The best way to achieve that is to work on a free alternative, eg, Linux Sampler. Comparing that with flogging yourself trying to get licenses changed for the sole purpose of hacking up some VST niceness, and the alternative seems a lot simpler and a lot more productive. Forest, you might reconsider your decision that fst has the most long-term potential and check out Linux Sampler instead; specifically QSampler. Bob From james at dis-dot-dat.net Fri Jun 30 07:35:53 2006 From: james at dis-dot-dat.net (james@dis-dot-dat.net) Date: Fri Jun 30 07:36:01 2006 Subject: [linux-audio-dev] Envelopes In-Reply-To: <44A50496.6030102@woh.rr.com> References: <20060629123800.GM10261@fitz.Belkin> <9b3e2dc20606290657t58d2e0aci85e0537741a5e557@mail.gmail.com> <20060629154350.GN10261@fitz.Belkin> <44A40234.3050503@woh.rr.com> <20060630101442.GP10261@fitz.Belkin> <44A50496.6030102@woh.rr.com> Message-ID: <20060630113553.GR10261@fitz.Belkin> On Fri, 30 Jun, 2006 at 07:01AM -0400, Dave Phillips spake thus: > james@dis-dot-dat.net wrote: > > >On Thu, 29 Jun, 2006 at 12:39PM -0400, Dave Phillips spake thus: > > > > > >>james@dis-dot-dat.net wrote: > >> > >> > >> > >>>Now, where can I get 1 million pounds for free? > >>> > >>> > >>> > >>> > >>There's about a million pounds of something at the White House in > >>Washington DC... > >> > >>Born in the USA, > >> > >> > > > >I was born in the UK, and I think I'm missing the joke. > > > > > It's a currency conversion joke (a poor one too). We use dollars for $$$ > and pounds as a measure of weight. Hehee! This reminds me of playing isketch in the English-UK rooms. There would always be 50% americans who would complain that people didn't use proper words and always use $ for money. I should have got the pounds thing though. It's not like we don't have them. Some people have managed to resist metrification even now. You can go and ask for 2lb of bacon (mmmm, 2lb of bacon) but they can't advertise 2lb of bacon. > Ergo: There's a million pounds of (descriptive noun deleted) on Capitol > Hill. I trod in a pile of deleted descriptive nouns the other day. > Ah, for the days before Babel, when all men spoke one language. I think > it was a proto-BASIC... I'm church of the latter-day Gnu, so I KNOW that the world has only been around for 40 years or so, and everyone spoke Lisp. James > Best, > > dp > > > > > > From pshirkey at boosthardware.com Fri Jun 30 07:46:57 2006 From: pshirkey at boosthardware.com (Patrick Shirkey) Date: Fri Jun 30 07:48:18 2006 Subject: [linux-audio-dev] Envelopes In-Reply-To: <20060630101442.GP10261@fitz.Belkin> References: <20060629123800.GM10261@fitz.Belkin> <9b3e2dc20606290657t58d2e0aci85e0537741a5e557@mail.gmail.com> <20060629154350.GN10261@fitz.Belkin> <44A40234.3050503@woh.rr.com> <20060630101442.GP10261@fitz.Belkin> Message-ID: <44A50F31.40003@boosthardware.com> james@dis-dot-dat.net wrote: > On Thu, 29 Jun, 2006 at 12:39PM -0400, Dave Phillips spake thus: >> james@dis-dot-dat.net wrote: >> >>> Now, where can I get 1 million pounds for free? >>> >>> >> There's about a million pounds of something at the White House in >> Washington DC... >> >> Born in the USA, > > I was born in the UK, and I think I'm missing the joke. > What joke? It's a definitive fact isn't it? -- Patrick Shirkey - Boost Hardware Ltd. Http://www.boosthardware.com Http://lau.linuxaudio.org - The Linux Audio Users guide ======================================== "Anything your mind can see you can manifest physically, then it will become reality" - Macka B From forest at alittletooquiet.net Fri Jun 30 08:46:42 2006 From: forest at alittletooquiet.net (Forest Bond) Date: Fri Jun 30 08:46:57 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <20060630105752.GA13275@teasel.arb.net> References: <20060629223558.GB20075@storm.local.network> <1151623792.10662.5.camel@localhost.localdomain> <20060630000055.GD20075@storm.local.network> <1151626610.10662.11.camel@localhost.localdomain> <20060630003707.GE20075@storm.local.network> <44A48452.9030205@gmail.com> <20060630010730.GF20075@storm.local.network> <44A4AE0E.6000108@gmail.com> <20060630105752.GA13275@teasel.arb.net> Message-ID: <20060630124642.GG20075@storm.local.network> > The issue here is that Mr Bond wants a sampler like Kontakt that works > with Linux audio systems and saves its state. The best way to achieve > that is to work on a free alternative, eg, Linux Sampler. I was under the impression that Linux Sampler is undergoing license changes. Not sure where I picked that up. In any case, Linux Sampler and Kontakt are different sorts of samplers at this point. Linux Sampler is more in the spirit of Gigasampler, and Kontakt is more like an emulation of a hardware sampler (but vastly more flexible). Kontakt supports several built in effect types, and complex modultation of parameters. I don't understand Linux Sampler to support that, but instead, I believe Linux Sampler focuses on smoothly playing huge samples in order to achieve accurate imitations of real instruments. Am I incorrect? > Comparing > that with flogging yourself trying to get licenses changed for the sole > purpose of hacking up some VST niceness, and the alternative seems a > lot simpler and a lot more productive. Assuming that kontakt is the only goal, yes. However, I do have other VSTs that I used extensively before dropping Windows altogether a few years ago. One tends to turn to the same tools over and over again to the point where they are almost essential. Every effect implementation is perhaps only slightly different, however, I've found that I became reliant on those subtleties. In any case, the VST spec itself is an open specification, even if the source is not freely re-distributable. I think it is a worthwhile goal to have full support for VST under Linux, not because it isn't worth the time to create free alternatives to current VSTs. Having good VST support will help bring a lot of musicians from other platforms. People rely on these things! > Forest, you might reconsider your decision that fst has the most > long-term potential and check out Linux Sampler instead; specifically > QSampler. Noted. However, I remain unconvinced that Linux Sampler is intended to be a drop-in replacement for something like Kontakt. I will look into it further. I played with LS a while back (actually, I packaged it for Ubuntu). Maybe I missed something. thanks, Forest -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: Digital signature Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060630/0838c2d3/attachment.bin From tomszilagyi at gmail.com Fri Jun 30 08:56:42 2006 From: tomszilagyi at gmail.com (Tom Szilagyi) Date: Fri Jun 30 08:57:31 2006 Subject: [linux-audio-dev] Re: [ANN] Aqualung 0.9beta5 released Message-ID: <44A51F8A.4010202@gmail.com> On Fri, Jun 30, 2006 at 01:34:31PM +0300, Sampo Savolainen wrote: > > Great news! Aqualung is starting to look like a very good option for a music > player. Thanks. We still see a number of areas where great improvement is needed, but we couldn't wait more before a real release (many people won't use our CVS tarballs ever, even though their contents are pretty much the same). > A few gripes though: > a) I would like to have a notification area icon to show/hide aqualung > b) There seems no easy way to import my existing collection of music. > I can select individual files from one directory, but whole > directories. My collection is divided into directories and > subdirectories. (artist/album/track.ogg) These are indeed noted, and planned for the next release. > Also, I found the metadata option a bit confusing: why doesn't aqualung use > metadata (id3's, etc.) provided by the audio files automatically? I had to > enable it explicitly. The defaults may be wrong, but once you enable autodetection, the program will remember your choice. (It is off by default so metadata won't accidentally override data from the Music Store -- this area may still need refinement.) Thanks for the feedback, Tom From forest at alittletooquiet.net Fri Jun 30 09:55:07 2006 From: forest at alittletooquiet.net (Forest Bond) Date: Fri Jun 30 09:55:15 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <3c808a150606300626ue1dbff8t2a703995b300ae40@mail.gmail.com> References: <1151623792.10662.5.camel@localhost.localdomain> <20060630000055.GD20075@storm.local.network> <1151626610.10662.11.camel@localhost.localdomain> <20060630003707.GE20075@storm.local.network> <44A48452.9030205@gmail.com> <20060630010730.GF20075@storm.local.network> <44A4AE0E.6000108@gmail.com> <20060630105752.GA13275@teasel.arb.net> <20060630124642.GG20075@storm.local.network> <3c808a150606300626ue1dbff8t2a703995b300ae40@mail.gmail.com> Message-ID: <20060630135507.GH20075@storm.local.network> > You are... Linux sampler doesn't support built-in effects because of what > working with audio is like under linux. JACK (jack audio connection kit) > is an application that allows one to manage connection between various > audio software. This includes linux sampler, but also plugins based on the > LADSPA sdk. You are right to say that there are no built-in effect in > Linuxsampler. It's not a lack of functionnality. It's meant to be like > this because you can connect linuxsampler's output to a effect management > rack like jack-rack (which also benefits of being jack compatible) have > any effect you like applied (and there's loads ! see > http://www.ladspa.org/). I can appreciate this modularity as much as the next fellow, but having effects support in the sampler itself is near-critical. Creating sophisticated sounds using a sampler requires it. I need to have multiple layers of samples, each filtered and modulated differently. You can't do this in post-processing. It just isn't possible. Even supposing Linux Sampler could route sounds out to effects and back in to the sampler, that would be far to complicated to be even remotely usable without giving up huge amounts of sampling felixibility. This is not about applying reverb to a drum kit. It's about having 6 samples triggered when I press a key on the keyboard, and each sample being filtered, pitch bended, saturated differently, and modulating all of those parameters using LFO's, envelopes, and midi parameters. You can't do that using "outboard" effects. -Forest -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: Digital signature Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060630/d6921dcd/attachment.bin From luisgarrido at users.sourceforge.net Fri Jun 30 10:03:00 2006 From: luisgarrido at users.sourceforge.net (Luis Garrido) Date: Fri Jun 30 10:03:08 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <20060630135507.GH20075@storm.local.network> References: <1151623792.10662.5.camel@localhost.localdomain> <1151626610.10662.11.camel@localhost.localdomain> <20060630003707.GE20075@storm.local.network> <44A48452.9030205@gmail.com> <20060630010730.GF20075@storm.local.network> <44A4AE0E.6000108@gmail.com> <20060630105752.GA13275@teasel.arb.net> <20060630124642.GG20075@storm.local.network> <3c808a150606300626ue1dbff8t2a703995b300ae40@mail.gmail.com> <20060630135507.GH20075@storm.local.network> Message-ID: > This is not about applying reverb to a drum kit. It's about having 6 samples > triggered when I press a key on the keyboard, and each sample being filtered, > pitch bended, saturated differently, and modulating all of those parameters > using LFO's, envelopes, and midi parameters. You can't do that using "outboard" > effects. Did you try to do that using soundfonts and fluidsynth? I am not sure at what extent fluid supports the modulator entities described in the spec, but these should do those tricks. HTH, Luis From rlrevell at joe-job.com Fri Jun 30 10:18:12 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Fri Jun 30 10:18:42 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] [ANN] Aqualung 0.9beta5 released In-Reply-To: <44A4F47D.3010201@gmail.com> References: <44A4F47D.3010201@gmail.com> Message-ID: <1151677093.32444.17.camel@mindpipe> On Fri, 2006-06-30 at 11:53 +0200, Tom Szilagyi wrote: > Aqualung: Music Player for GNU/Linux > > http://aqualung.sf.net > > Release 0.9beta5 > > > It is our greatest pleasure to announce the fifth official beta > release of Aqualung. Some features you'd rarely stumble upon in > other players (at least not too many of them at once): > > * Gapless playback (designed for this from the ground up) > * High quality decoders (eg. libMAD for mp3), many supported formats > * High-quality sample rate conversion support via libsamplerate > * LADSPA support > * Music Store for organizing your music > * And much, much more... > > We hope you will enjoy this release. The release ChangeLog follows below. Do you guys have any interest in getting this into Debian/Ubuntu? The only .debs I could find are old (for Sarge?) Lee From tszilagyi at users.sourceforge.net Fri Jun 30 10:19:55 2006 From: tszilagyi at users.sourceforge.net (Tom Szilagyi) Date: Fri Jun 30 10:21:28 2006 Subject: [linux-audio-dev] Re: [ANN] Aqualung 0.9beta5 released In-Reply-To: <5bdc1c8b0606300646x1482964dy2c1f804d35ffea2a@mail.gmail.com> Message-ID: <20060630141955.GA5158@r51> On Fri, Jun 30, 2006 at 06:46:39AM -0700, Mark Knecht wrote: > > Tom, > Maybe you and Peter should post these on the Aqualung download > site? Maybe they are there already? The scripts were never intended to be used by a large audience (large by any standard), however, if there is popular demand for them, we might just post them to the website so everyone has easy access to it. We anticipate that this aspect of Aqualung (ie. mass import, mass tagging, etc) will improve greatly by the time we release our next beta. Tom From forest at alittletooquiet.net Fri Jun 30 10:25:04 2006 From: forest at alittletooquiet.net (Forest Bond) Date: Fri Jun 30 10:25:15 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: References: <1151626610.10662.11.camel@localhost.localdomain> <20060630003707.GE20075@storm.local.network> <44A48452.9030205@gmail.com> <20060630010730.GF20075@storm.local.network> <44A4AE0E.6000108@gmail.com> <20060630105752.GA13275@teasel.arb.net> <20060630124642.GG20075@storm.local.network> <3c808a150606300626ue1dbff8t2a703995b300ae40@mail.gmail.com> <20060630135507.GH20075@storm.local.network> Message-ID: <20060630142504.GI20075@storm.local.network> On Fri, Jun 30, 2006 at 04:03:00PM +0200, Luis Garrido wrote: > >This is not about applying reverb to a drum kit. It's about having 6 > >samples > >triggered when I press a key on the keyboard, and each sample being > >filtered, > >pitch bended, saturated differently, and modulating all of those parameters > >using LFO's, envelopes, and midi parameters. You can't do that using > >"outboard" > >effects. > > Did you try to do that using soundfonts and fluidsynth? I am not sure > at what extent fluid supports the modulator entities described in the > spec, but these should do those tricks. Well, that's a little more reasonable, but you still don't get realtime editing of the sampler programs (i.e. within a production environment, tweak patch parameters). In fact, if I understand correctly, one edits a soundfont using an external editor, that presumably has a preview function, and then uses the soundfont with fluidsynth. What's the problem? You're editing and playing using two different implementations of the filters, modulation, etc... The two are unlikely to sound the same, or even close to the same. Soundfonts weren't really designed for the kind of precise sampler control you get with a real hardware sampler, or kontakt, where you can cut/loop samples exactly where you want (and do so without leaving your production environment), and route modulation and effects on the fly. I don't mean to say that fluidsynth doesn't have its place, as well, just that fluidsynth and kontakt are not really intended to do the same things. As far as I can tell there are two resolutions: 1) someone works on fst to make it save kontakt's state 2) someone writes a free kontakt replacement 1) is both easier and gets you access to more software (other VSTs). 2) has the benefit of finally freeing myself from proprietary software completely, which I'd love to do. I'm happy to tackle (2) with help, but that would certainly require a lot of help. -Forest -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: Digital signature Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060630/fffa7625/attachment.bin From tszilagyi at users.sourceforge.net Fri Jun 30 10:28:00 2006 From: tszilagyi at users.sourceforge.net (Tom Szilagyi) Date: Fri Jun 30 10:42:37 2006 Subject: [linux-audio-dev] Re: [ANN] Aqualung 0.9beta5 released In-Reply-To: <1151677093.32444.17.camel@mindpipe> References: <44A4F47D.3010201@gmail.com> <1151677093.32444.17.camel@mindpipe> Message-ID: <20060630142800.GA5308@r51> On Fri, Jun 30, 2006 at 10:18:12AM -0400, Lee Revell wrote: > > Do you guys have any interest in getting this into Debian/Ubuntu? The > only .debs I could find are old (for Sarge?) Yes, certainly. However, we entirely rely on others (users) to do it (read: we won't work hard for it to happen; we are not members/advocates/fans of any distro, etc etc. We have our reasons for this policy.) If anyone creates up-to-date .debs, we will be happy to post them on our site. If the program makes it into the official debian repositories, even better. Tom From forest at alittletooquiet.net Fri Jun 30 10:44:41 2006 From: forest at alittletooquiet.net (Forest Bond) Date: Fri Jun 30 10:45:25 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <20060630142503.GB13275@teasel.arb.net> References: <1151623792.10662.5.camel@localhost.localdomain> <20060630000055.GD20075@storm.local.network> <1151626610.10662.11.camel@localhost.localdomain> <20060630003707.GE20075@storm.local.network> <44A48452.9030205@gmail.com> <20060630010730.GF20075@storm.local.network> <44A4AE0E.6000108@gmail.com> <20060630105752.GA13275@teasel.arb.net> <20060630124642.GG20075@storm.local.network> <20060630142503.GB13275@teasel.arb.net> Message-ID: <20060630144441.GJ20075@storm.local.network> > > In any case, Linux Sampler and Kontakt are > > different sorts of samplers at this point. Linux Sampler is more in the spirit > > of Gigasampler, and Kontakt is more like an emulation of a hardware sampler (but > > vastly more flexible). > > The key words there are "at this point." As noted, the *long-term* > potential of Linux Sampler is probably still much greater than Kontakt-in-wine. Agreed. Maybe time is best spent improving linux sampler. Then again, good VST has benefits, although I do see how it may hurt the long term goals of free software. I'm just not sure if the best way to help free software is to limit it's ability to integrate with proprietary software. > > > > Noted. However, I remain unconvinced that Linux Sampler is intended to be a > > drop-in replacement for something like Kontakt. > > I don't think it's intended to be a drop-in replacement for Kontakt; I > think it's just intended to be cool. I can appreciate that. -Forest -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: Digital signature Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20060630/d809def4/attachment.bin From luisgarrido at users.sourceforge.net Fri Jun 30 10:52:55 2006 From: luisgarrido at users.sourceforge.net (Luis Garrido) Date: Fri Jun 30 10:53:11 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <20060630142504.GI20075@storm.local.network> References: <1151626610.10662.11.camel@localhost.localdomain> <44A48452.9030205@gmail.com> <20060630010730.GF20075@storm.local.network> <44A4AE0E.6000108@gmail.com> <20060630105752.GA13275@teasel.arb.net> <20060630124642.GG20075@storm.local.network> <3c808a150606300626ue1dbff8t2a703995b300ae40@mail.gmail.com> <20060630135507.GH20075@storm.local.network> <20060630142504.GI20075@storm.local.network> Message-ID: > soundfont with fluidsynth. What's the problem? You're editing and playing > using two different implementations of the filters, modulation, etc... The two Wrong, swami uses fluidsynth itself. > are unlikely to sound the same, or even close to the same. Soundfonts weren't > really designed for the kind of precise sampler control you get with a real > hardware sampler, or kontakt, where you can cut/loop samples exactly where you > want (and do so without leaving your production environment), and route > modulation and effects on the fly. Weren't they? I don't see why can't you do those things provided you modify the existing software. > 1) is both easier and gets you access to more software (other VSTs). 2) has the > benefit of finally freeing myself from proprietary software completely, which > I'd love to do. I'm happy to tackle (2) with help, but that would certainly > require a lot of help. Let's talk about it, then. I like Kontakt a lot, too, but emulation is bound to always be problematic. There are nowadays two open source major sampling engines: linuxsampler and fluidsynth. Both are suitable to the task, but fluid is no longer being actively developed (big pity, that). I already went superficially through fluid sources am and now playing around with LS. It is not that far away, I think. Luis From rah at bash.sh Fri Jun 30 10:54:29 2006 From: rah at bash.sh (Robert Ham) Date: Fri Jun 30 10:55:04 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <20060630124642.GG20075@storm.local.network> References: <20060629223558.GB20075@storm.local.network> <1151623792.10662.5.camel@localhost.localdomain> <20060630000055.GD20075@storm.local.network> <1151626610.10662.11.camel@localhost.localdomain> <20060630003707.GE20075@storm.local.network> <44A48452.9030205@gmail.com> <20060630010730.GF20075@storm.local.network> <44A4AE0E.6000108@gmail.com> <20060630105752.GA13275@teasel.arb.net> <20060630124642.GG20075@storm.local.network> Message-ID: <20060630145429.GC13275@teasel.arb.net> On Fri, Jun 30, 2006 at 08:46:42AM -0400, Forest Bond wrote: > > The issue here is that Mr Bond wants a sampler like Kontakt that works > > with Linux audio systems and saves its state. The best way to achieve > > that is to work on a free alternative, eg, Linux Sampler. > > In any case, Linux Sampler and Kontakt are > different sorts of samplers at this point. Linux Sampler is more in the spirit > of Gigasampler, and Kontakt is more like an emulation of a hardware sampler (but > vastly more flexible). The key words there are "at this point." As noted, the *long-term* potential of Linux Sampler is probably still much greater than Kontakt-in-wine. > > Forest, you might reconsider your decision that fst has the most > > long-term potential and check out Linux Sampler instead; specifically > > QSampler. > > Noted. However, I remain unconvinced that Linux Sampler is intended to be a > drop-in replacement for something like Kontakt. I don't think it's intended to be a drop-in replacement for Kontakt; I think it's just intended to be cool. Bob From rah at bash.sh Fri Jun 30 10:54:52 2006 From: rah at bash.sh (Robert Ham) Date: Fri Jun 30 10:55:20 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <20060630142504.GI20075@storm.local.network> References: <20060630003707.GE20075@storm.local.network> <44A48452.9030205@gmail.com> <20060630010730.GF20075@storm.local.network> <44A4AE0E.6000108@gmail.com> <20060630105752.GA13275@teasel.arb.net> <20060630124642.GG20075@storm.local.network> <3c808a150606300626ue1dbff8t2a703995b300ae40@mail.gmail.com> <20060630135507.GH20075@storm.local.network> <20060630142504.GI20075@storm.local.network> Message-ID: <20060630145452.GD13275@teasel.arb.net> On Fri, Jun 30, 2006 at 10:25:04AM -0400, Forest Bond wrote: > As far as I can tell there are two resolutions: > > 1) someone works on fst to make it save kontakt's state > 2) someone writes a free kontakt replacement 3) someone makes Linux Sampler do what Kontakt does It already does bulk of what you need; ie, triggering an audio sample on reciept of a MIDI note. See http://www.linuxsampler.org/features.html for everything else it does. Bob From rah at bash.sh Fri Jun 30 11:22:25 2006 From: rah at bash.sh (Robert Ham) Date: Fri Jun 30 11:22:46 2006 Subject: [linux-audio-dev] fst, VST 2.0, kontakt In-Reply-To: <20060630144441.GJ20075@storm.local.network> References: <20060630000055.GD20075@storm.local.network> <1151626610.10662.11.camel@localhost.localdomain> <20060630003707.GE20075@storm.local.network> <44A48452.9030205@gmail.com> <20060630010730.GF20075@storm.local.network> <44A4AE0E.6000108@gmail.com> <20060630105752.GA13275@teasel.arb.net> <20060630124642.GG20075@storm.local.network> <20060630142503.GB13275@teasel.arb.net> <20060630144441.GJ20075@storm.local.network> Message-ID: <20060630152225.GE13275@teasel.arb.net> On Fri, Jun 30, 2006 at 10:44:41AM -0400, Forest Bond wrote: > I'm just not sure if the best way to help free software is to limit > it's ability to integrate with proprietary software. Integrating with proprietary software is great; let's have full VST support. I'm for it. Let's have free software that works with everything. Unless it involves relicensing free software in less free terms in order to aid the proprietary software. That would be.. well.. nuts. It's also worth bearing in mind that the only people to expend energy on integrating free software with proprietary software will be those who have a vested interest in that integration. Bob From gene.heskett at verizon.net Fri Jun 30 11:24:03 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Fri Jun 30 11:24:37 2006 Subject: [linux-audio-dev] Envelopes In-Reply-To: <44A50F31.40003@boosthardware.com> References: <20060629123800.GM10261@fitz.Belkin> <9b3e2dc20606290657t58d2e0aci85e0537741a5e557@mail.gmail.com> <20060629154350.GN10261@fitz.Belkin> <44A40234.3050503@woh.rr.com> <20060630101442.GP10261@fitz.Belkin> <44A50F31.40003@boosthardware.com> Message-ID: <44A54213.5090401@verizon.net> Patrick Shirkey wrote: > james@dis-dot-dat.net wrote: >> On Thu, 29 Jun, 2006 at 12:39PM -0400, Dave Phillips spake thus: >>> james@dis-dot-dat.net wrote: >>> >>>> Now, where can I get 1 million pounds for free? >>>> >>>> >>> There's about a million pounds of something at the White House in >>> Washington DC... >>> >>> Born in the USA, >> >> I was born in the UK, and I think I'm missing the joke. >> > > What joke? > > It's a definitive fact isn't it? > Yup, and the heat of the composting is 50% of whats driving global warming. -- Cheers, Gene From jens.andreasen at chello.se Fri Jun 30 16:02:44 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Fri Jun 30 16:02:50 2006 Subject: [linux-audio-dev] Envelopes In-Reply-To: <20060629123800.GM10261@fitz.Belkin> References: <20060629123800.GM10261@fitz.Belkin> Message-ID: <1151697764.9274.322.camel@c80-216-124-251.cm-upc.chello.se> On Thu, 2006-06-29 at 13:38 +0100, james@dis-dot-dat.net wrote: > Hi peeps. > > I've been writing an app that requires volume envelopes. I've > implemented the envelope part myself, but I was wondering if there > was a library about to do it. > > I ask because I realised that probably everyone on this list has > written something that uses envelopes, and probably written it > better and with more features than I have. > Well, I don't know what features you have implemented or wish for, but for what it is worth, I implemented 8 stage envelopes with looping sustainlevels, key- and velocity-follow, the works ... and it is all crap! :-D Honestly, I never use all those features (spare the key-follow) and am instead returning to a much more basic view of envelopes where even the standard ADSR appears to be a bit over-worked. The focus on complex envelopes is perhaps a left-over from another era when stable oscillators were expensive and envelopes fairly cheap to implement, adding a welcomed illusion of complexity. Other implementations made from many smaller basic building blocks, like the ones from Bucla and EMS, was an exclusive for radio-stations and research-centers. Bucla only had attack/decay (but you could chain several elements), EMS had attack/decay/release which I believe comes pretty close to an ideal minimalist approach: * Attack is needed because it may take some time before the system stabilizes after we start adding energy. * Decay is needed because we may have added a single burst of energy, fading away with no further energy being added. * Release is needed for damping, or else all our instruments will be variations of tubular bells and marimbas. A straight forward Farfisa organ has its place too. Is this then really enough to cater for all our envel?pe needs? Given we have a few of them, say a small number like four, and a patchbay, I believe it is. Say we wanted to use a wobbling complex envelope for a punchy trombone bratt? That can still be done with simple envelopes, perhaps even better than with a complex, by routing an LFO through a second (shortish) envelope, modulating the sounding oscillator on top of the main envelope. Combine and conquer! Oscillators are cheap these days and we do not need to rely on a single LFO implemented as a shared resource. Or perhaps we would like a bit of envelope delay to make a sudden change of the sound after a while? One way of doing this could be to put the envelope through a delay line (which we would then need to have made part of the synthesizing algorithm.) There is no need to put the delay feature into the envelope itself. Delay lines are inexpensive these days and, given a patch bay, very flexible and useful little tools also for peak and notch filters. Hey, given enough feedback, we can even use them as spare oscillators ... Another argument in favour of ADR rather than, say ADSR, is if we compare by counting the number of knobs to be assigned. Given a finite amount of knobs, I am convinced it would be more flexible to have four ADR's rather than three ADSR's. And knobs are a finite resource, if for no other reason than the lenght of your arms. Finally, we could throw in a bit of Bucla wisdom and allow the envelopes to retrigger themselves, so as to get us a bank of LFO's instead. With all this being said, what would then be a desireable implementation of a very basic ADR? The decay and release is probably the easiest to come to terms with, because we will simply borrow from physics, which tells us that the system should decay exponentially towards zero. And then some ... Because of the inner damping, we actually do reach zero in finite time. Following the same strategy backwards for the attack unfortunately does not work. Our instruments will sound uninspired and booring ... But if we instead allow us to do it upside down, an exponential decay from zero towards one so to say, then we appear to come much closer to the desired result. Now why is that? I can see two reasons, the first one again having to do with physics. Say we were playing the trombone, then the energy applied from the buildup of pressure is almost explosive in the initial phase, accellerating the system response very quickly, but over time the intial pressure diminishes, giving us a smoother rounding into the sustained part. So it is in part because that that's the way attacks tend to appear naturally. The second reason is that given a choice we wouldn't really like to do it any other way, not even in situations where we gently fade the notes in ... because it makes no sense to play below the hearing-treshold. A fast fade-in to just above hearing-treshold, grabbing the attention, followed by a smooth parking at the sustain level, allows us to be both soft and distinct at the same time. Although technically not part of the envelope itself, a keyfollow, modifying the time of the envelope is a must have. Small high pitced systems tends to decay much faster than the huge and low pithed ones. One thing to remember here, is to keep the unmodifyed reference note within the part of the keyboard that we actually own. Having key zero as a reference is an annoying mistake. The real kicker would of course be if we have aimed high enough in the quality of implementation, as well as applied the re-trigger feature. Then the keyfollow could potentially turn the envelope into a pitched oscillator with variable shape. Aim even higher and make it a stateless function, and we can start implementing FM-synthesis. We could also let one envelope re-trigger another, re-triggering the first. With appropiate settings we would then be on our way into the realms of the Casio CZ-101 ... Oy, this became somewhat lengthier than I intended. I better stop now before it turns into a complete design document for a synthesizer based on simple envelopes and short delay lines. Also ... It is friday evening and I have a beer to attend to :-D > More generally, is there a library/toolkit of audio bits and bobs > about? > Well if you like, you can copy/paste the old ones I have. In the innermost loop there are a few mmx instructions adding up progress and squaring the current value, but they can easily be rewritten to plain C. And like I said, it is perfectly possible to ignore the excess parameters and make a simplified UI > James > -- cheers! // Jens M Andreasen From james at dis-dot-dat.net Fri Jun 30 17:04:40 2006 From: james at dis-dot-dat.net (james@dis-dot-dat.net) Date: Fri Jun 30 17:04:46 2006 Subject: [linux-audio-dev] Envelopes In-Reply-To: <1151697764.9274.322.camel@c80-216-124-251.cm-upc.chello.se> References: <20060629123800.GM10261@fitz.Belkin> <1151697764.9274.322.camel@c80-216-124-251.cm-upc.chello.se> Message-ID: <20060630210440.GB25650@fitz.Belkin> Wow. I just have linear ADSR, which is about all I need. The exponential decay and attack are probably a good idea, though. Cheers. It's nice to see people thinking! That sounds wrong. I mean, compared to only seeing the result of thought, which is more usual. James On Fri, 30 Jun, 2006 at 10:02PM +0200, Jens M Andreasen spake thus: > On Thu, 2006-06-29 at 13:38 +0100, james@dis-dot-dat.net wrote: > > Hi peeps. > > > > I've been writing an app that requires volume envelopes. I've > > implemented the envelope part myself, but I was wondering if there > > was a library about to do it. > > > > I ask because I realised that probably everyone on this list has > > written something that uses envelopes, and probably written it > > better and with more features than I have. > > > > Well, I don't know what features you have implemented or wish for, but > for what it is worth, I implemented 8 stage envelopes with looping > sustainlevels, key- and velocity-follow, the works ... and it is all > crap! :-D Honestly, I never use all those features (spare the > key-follow) and am instead returning to a much more basic view of > envelopes where even the standard ADSR appears to be a bit over-worked. > > The focus on complex envelopes is perhaps a left-over from another era > when stable oscillators were expensive and envelopes fairly cheap to > implement, adding a welcomed illusion of complexity. Other > implementations made from many smaller basic building blocks, like the > ones from Bucla and EMS, was an exclusive for radio-stations and > research-centers. > > Bucla only had attack/decay (but you could chain several elements), > > EMS had attack/decay/release which I believe comes pretty close to an > ideal minimalist approach: > > * Attack is needed because it may take some time before the system > stabilizes after we start adding energy. > > * Decay is needed because we may have added a single burst of energy, > fading away with no further energy being added. > > * Release is needed for damping, or else all our instruments will be > variations of tubular bells and marimbas. A straight forward Farfisa > organ has its place too. > > Is this then really enough to cater for all our envel?pe needs? > > Given we have a few of them, say a small number like four, and a > patchbay, I believe it is. > > Say we wanted to use a wobbling complex envelope for a punchy trombone > bratt? That can still be done with simple envelopes, perhaps even better > than with a complex, by routing an LFO through a second (shortish) > envelope, modulating the sounding oscillator on top of the main > envelope. Combine and conquer! Oscillators are cheap these days and we > do not need to rely on a single LFO implemented as a shared resource. > > Or perhaps we would like a bit of envelope delay to make a sudden change > of the sound after a while? One way of doing this could be to put the > envelope through a delay line (which we would then need to have made > part of the synthesizing algorithm.) There is no need to put the delay > feature into the envelope itself. Delay lines are inexpensive these days > and, given a patch bay, very flexible and useful little tools also for > peak and notch filters. Hey, given enough feedback, we can even use them > as spare oscillators ... > > Another argument in favour of ADR rather than, say ADSR, is if we > compare by counting the number of knobs to be assigned. Given a finite > amount of knobs, I am convinced it would be more flexible to have four > ADR's rather than three ADSR's. And knobs are a finite resource, if for > no other reason than the lenght of your arms. > > Finally, we could throw in a bit of Bucla wisdom and allow the > envelopes to retrigger themselves, so as to get us a bank of LFO's > instead. > > > > With all this being said, what would then be a desireable implementation > of a very basic ADR? > > The decay and release is probably the easiest to come to terms with, > because we will simply borrow from physics, which tells us that the > system should decay exponentially towards zero. And then some ... > Because of the inner damping, we actually do reach zero in finite time. > > Following the same strategy backwards for the attack unfortunately does > not work. Our instruments will sound uninspired and booring ... But if > we instead allow us to do it upside down, an exponential decay from zero > towards one so to say, then we appear to come much closer to the desired > result. Now why is that? > > I can see two reasons, the first one again having to do with physics. > Say we were playing the trombone, then the energy applied from the > buildup of pressure is almost explosive in the initial phase, > accellerating the system response very quickly, but over time the intial > pressure diminishes, giving us a smoother rounding into the sustained > part. So it is in part because that that's the way attacks tend to > appear naturally. The second reason is that given a choice we wouldn't > really like to do it any other way, not even in situations where we > gently fade the notes in ... because it makes no sense to play below the > hearing-treshold. A fast fade-in to just above hearing-treshold, > grabbing the attention, followed by a smooth parking at the sustain > level, allows us to be both soft and distinct at the same time. > > Although technically not part of the envelope itself, a keyfollow, > modifying the time of the envelope is a must have. Small high pitced > systems tends to decay much faster than the huge and low pithed ones. > One thing to remember here, is to keep the unmodifyed reference note > within the part of the keyboard that we actually own. Having key zero as > a reference is an annoying mistake. > > The real kicker would of course be if we have aimed high enough in the > quality of implementation, as well as applied the re-trigger feature. > Then the keyfollow could potentially turn the envelope into a pitched > oscillator with variable shape. Aim even higher and make it a stateless > function, and we can start implementing FM-synthesis. We could also let > one envelope re-trigger another, re-triggering the first. With > appropiate settings we would then be on our way into the realms of the > Casio CZ-101 ... > > > Oy, this became somewhat lengthier than I intended. I better stop now > before it turns into a complete design document for a synthesizer based > on simple envelopes and short delay lines. Also ... It is friday evening > and I have a beer to attend to :-D > > > More generally, is there a library/toolkit of audio bits and bobs > > about? > > > > Well if you like, you can copy/paste the old ones I have. In the > innermost loop there are a few mmx instructions adding up progress and > squaring the current value, but they can easily be rewritten to plain C. > > And like I said, it is perfectly possible to ignore the excess > parameters and make a simplified UI > > > James > >