Re: [linux-audio-dev] Re: [linux-audio-user] disaster day #1
On Tue, Jun 07, 2005 at 10:27:02AM -0400, Paul Winkler wrote: Yep, hardware failures are no fun. The deeper I get into the hardware world (day job) the scarier it is. You know how some PSUs cost more than others? Sometimes a lot more? There are reasons for that. Ditto RAM. I'm frankly amazed that we all get by without ECC on *every* machine. It's frightening. Tim
Re: [linux-audio-user] Re: [linux-audio-dev] RME is no more
On Sat, Nov 27, 2004 at 12:34:17AM +0100, Marek Peteraj wrote: Which seems like it's the beginning of end for linux pro-audio hw support if we don't fight for it. Right now it concerns just me, but it might concern everyone in the near future. How can we fight it? I've been holding off on a firewire interface, but now maybe I just won't get one...
Re: [linux-audio-dev] RME is no more
On Thu, Nov 25, 2004 at 02:14:11AM +0100, Marek Peteraj wrote: The official statement is that there will be no support for ALSA (Linux) FireWire drivers from RME. In other words there will be no such drivers, as it is impossible to write them without tons of hardware and software documentation from RME. And we won't share these information with anyone. Regards Matthias Carstens RME No further explanations. Suck. I guess I won't buy one then. Sigh. Why do companies suck so much?
Re: [linux-audio-dev] Linux and Standards
On Sat, Oct 30, 2004 at 03:23:04AM -0400, Ivica Ico Bukvic wrote: AUDIO-RELATED STANDARDS THAT CAME FROM LINUX COMMUNITY (in no particular order -- it's 3am, give me a break ;-) Jack, LADSPA, LASH, ALSA, Ogg/Vorbis, others? Don't forget GMPI. Several of the active folks on the (slow) GMPI standard project are from LAD.
Re: [linux-audio-dev] Re: [Jackit-devel] Re: realtime-lsm in the kernel
On Sun, Sep 12, 2004 at 02:06:53AM -0400, Lee Revell wrote:
OK, patch has been posted to LKML...
http://lkml.org/lkml/2004/9/12/22
Shouldn't you use in_group_p() instead of searching the grouplist
yourself? in the new kernels, groups are sorted, so in_group_p uses a
binary search. Also, the ifdef will never fly. Also, don't put a blank
line after if () { - you do that in a couple places.
Nitpicking before Linus and Andrew do it for you :)
Re: [linux-audio-dev] Re: desktop and multimedia as an afterthought?
On Tue, Jul 13, 2004 at 11:06:30AM -0400, Paul Davis wrote: Thus, the lock-free ringbuffer is not portable. (What if the reader gets an old value that is never updated?) the kernel *requires* atomic operations to at least the same extent that audio apps do. if you can run linux on a h/w platform, then the required atomic ops are available. Those atmoic ops may or may not be possible or allowed in user space by a non-root user. If I recall, some architectures have atomic ops only in ring 0 (kernel space). Could be wrong on that...
Re: [linux-audio-dev] malloc() in RT code considered not-so-harmful?
On Tue, Jul 13, 2004 at 02:12:21PM +0200, Olivier Guilyardi wrote: 2. When your lock-free malloc needs more memory from the OS it will still take a system call to do it. I believe I have heard it said in the past that system calls of any sort are unacceptable in RT code, but isn't this a bit a of a hard-line position? Is msgrcv() unacceptable as well, then ? If you want to be careful, then yes. You can ask msgrcv to not block, but I'd personally double check the kernel code. :) Tim
Re: [linux-audio-dev] malloc() in RT code considered not-so-harmful?
On Tue, Jul 13, 2004 at 06:09:57PM +0200, Olivier Guilyardi wrote: If you want to be careful, then yes. You can ask msgrcv to not block, but I'd personally double check the kernel code. :) What do you usually use then to talk with a RT thread ? The JACK doc talks about rwlocks, but message queues happen to elegantly suit my code... You can do IPC without syscalls, if you have atomic ops on a platform. See the various lock-free FIFO implementations floating around.
Re: [linux-audio-dev] malloc() in RT code considered not-so-harmful?
On Tue, Jul 13, 2004 at 10:21:23AM -0700, Joshua Haberman wrote: You could use a lock-free malloc as an emergency memory store for when your pre-allocated buffers run out. There's no such thing as a lock free malloc() that calls brk(), unless I am confused. brk() is a syscall that can block the caller. To make a lock-free malloc(), you have to malloc() a big chunk of memory, then run your own allocator against it. You don't reduce your overhead at all. Or am I confused? Allocators never were my focus.. :)
Re: [linux-audio-dev] malloc() in RT code considered not-so-harmful?
On Wed, Jul 14, 2004 at 05:58:25AM +0200, Ralf Beck wrote: Am Dienstag, 13. Juli 2004 22:50 schrieb Steve Harris: On Tue, Jul 13, 2004 at 10:21:23 -0700, Joshua Haberman wrote: Its not my experieince that you usually need to allocate memory in RT threads, the times when I've seen it done are mostly generalisation bacuase of bad design, excessive OO-ness or lack of knowledge of alloca(3) /generalisation. malloc does not guarantee, that the allocated memory is locked into physical memory. To say it short: A RT thread must NEVER call a function that might block!! The point was that an RT-safe malloc() could be safe, but it indicates a bad design. If your app starts up, does malloc(1024*1024*32); walks through that memory to page it in, then mlock()s it, you can write a safe malloc to allocate from that memory. But yuck. Tim
Re: [linux-audio-dev] Re: lock-free data structures
On Sat, Jun 19, 2004 at 01:48:43PM +0300, Juhana Sadeharju wrote: http://en.wikipedia.org/wiki/Memory_barrier What it means practically? Any code? (Cannot check wikipedia now.) Practically, there are memory barrier implied instructions. See the Linux kernel for examples. I don't know how possible it is to bring all that to user space, especially across platforms. Quick question: disk thread may suspend if there are no disk use. How the disk thread is woken up to read the lock-free buffer? Semaphore. Every time you put something into the buffer, up() the semaphore (after). Every time you want to take something from the buffer, down() the semaphore, first.
Re: [linux-audio-dev] lock-free data structures
On Thu, Jun 17, 2004 at 08:22:29PM -0700, Joshua Haberman wrote: One final thing: I'm not sure if this is a problem in practice, but most (if not all) processors do not guarantee that memory reads and writes are performed in order, as observed by other processors and by I/O devices. This could theoretically lead to a problem where the stores that write data to the ring buffer are not performed until *after* the store that updates your write pointer. Your reader thread could get old data rather than the data your just wrote. To guarantee that the loads and stores are observed in the required order, you have to use memory barriers (again, in theory). See: Yes, this was discussed here a while back. For all practical platforms that the developers cared about, 32 bit aligned access are atomic. They are not guaranteed to STAY that way, but for now..
Re: [linux-audio-dev] Knobs, the reply
On Fri, Jun 11, 2004 at 02:57:11AM -0400, Lee Revell wrote: Hello? See my previous post re: mouse wheel. There is a *perfect* mapping between a knob and the mouse wheel, much more straightforward than for any other hardware control. Perfect it is not. My favorite mouse has a wheel which is not very fine grained. Not so good for moving a knob. Besides that, you still need to decide whether the main control (left-click) is linear or radial. Mouse wheel is an add-on and not something that can be considered standard, yet.
Re: [linux-audio-dev] [OT] bedroom vs. any other room, was re: [OT] marketing hype
On Fri, Jun 11, 2004 at 01:21:51PM -0400, Paul Davis wrote: more seriously, its necessary to be able to escape from programming. if not the bedroom, then where? but then how do you wake up when you r build is done? make echo ^G^G :)
Re: [linux-audio-dev] Knobs, the reply
On Thu, Jun 10, 2004 at 02:09:08PM +0200, Thorsten Wilms wrote: Tim Hockin: please elaborate about velocity sensitve knobs like used by OhmForce. When you move the mouse slowly, you get very fine control. When you move it faster, the control gets coarser. So you can move a knob from 0.0 to 1.0 quickly with a fast mouse gesture, or you can move it from 0.5 to 0.6 very slowly. For those who think radial is bad: in that case knobs shouldn't be used at all! (Tim Hockin: it makes no sense to disagree to a half sentence/meaning!) Popping up a slider doesn't help much, the nature of the control should be clear right away. I'm still going to put my bet on linear. If you do a usability study of linear vs radial, I bet linear will be more obvious and easy to control. And you will not convince me otherwise until I see a usability test done with non-LAD users :) Oh, and about linear needing 2 directions, up/down for gain and right left for pan (Uwe): Sure. And the widget has to be clear about that in advance. This is such a bad idea, unless the control is an X/Y control to start with.
Re: [linux-audio-dev] [OT] marketing hype [was: Is ladspa actually la-dsp-a? Is JACK the ultimate solution?}
On Thu, Jun 10, 2004 at 12:40:33PM -0400, Dave Robillard wrote: Not that I wasn't being truthful though - I really don't want proprietary software anywhere around here (freedom's pretty much all we have), but that's just one man's opinion, take it or leave it. I'm happy to have the freedom to know what my OS is *really* doing. I'd buy Cubase for Linux.
Re: [linux-audio-dev] Knobs / widget design
On Thu, Jun 10, 2004 at 12:50:19PM +0200, [EMAIL PROTECTED] wrote: why dont we specify behaviour and a gfx format for control animations and then implement the widgets for gtk and qt ? Brilliant, but get every aspect of the behavior down. For example, something that no one has discussed yet: if the knob is pointed at 3:00 and I click-and-hold on it at 9:00, does the knob jump to 9:00? I've seen knobs do that, and I have seen knobs which don't. I personally can't stand knobs that jump when I click them. It is so frustrating.
Re: [linux-audio-dev] Knobs, the reply
On Thu, Jun 10, 2004 at 08:02:48PM +0200, Thorsten Wilms wrote: When you move the mouse slowly, you get very fine control. When you move it faster, the control gets coarser. So you can move a knob from 0.0 to 1.0 quickly with a fast mouse gesture, or you can move it from 0.5 to 0.6 very slowly. Thanks. Sounds like trouble with controlabilty/predictability to me. It is unpredictable. I don't much care for it as a UI feature. It is very hard for me to stay below the 'fine-grain' speed limit. I'm still going to put my bet on linear. If you do a usability study of linear vs radial, I bet linear will be more obvious and easy to control. And you will not convince me otherwise until I see a usability test done with non-LAD users :) Maybe linear is easier to handle, but the usual knob graphics are still misleading (you can't tell me something round with clear center hints at linear movement, even if the real world metaphor is left out). I think that your frontal lobe is saying knobs are round, move the mouse around them but I still believe that your hand will find it more intuitive and correct to move the mouse in one direction - up and down. This is such a bad idea, unless the control is an X/Y control to start with. No, I did not mean 2 axes for one widget. Only that a linear widget has to indicate it's direction even before interaction happens, and that it makes sense to use vertical for volume and horizonal for pan in the same interface. OH! Hrrm, yes, well. I see the point, but I don't think it will work. Differing semantics for similar-looking widget is the worst of all possible choices.
Re: [linux-audio-dev] [OT] marketing hype [was: Is ladspa actually la-dsp-a? Is JACK the ultimate solution?}
On Thu, Jun 10, 2004 at 02:26:44PM -0400, Paul Davis wrote: I'm happy to have the freedom to know what my OS is *really* doing. I'd buy Cubase for Linux. you don't care as much about the freedom to know what your DAW is *really* doing? if you're a musician or an audio engineer, you will be interacting with the DAW very very much more than with the OS ... I'd *like* that. But I'd also like to be able to make music on Linux. I'm an OS hacker by trade and an amateur musician by hobby. In order to reconcile my tastes for music software and Linux, I have had to begin to become an audio hacker. I am faced every day with the decision to a) make music b) make music software So when I disappear from the GMPI list for a few days and then re-appear with 20 emails in one day, you now know where my attention is going :) Tim
Re: [linux-audio-dev] Knobs, the reply
On Thu, Jun 10, 2004 at 02:53:56PM -0400, Paul Winkler wrote: No, I did not mean 2 axes for one widget. Only that a linear widget has to indicate it's direction even before interaction happens, and that it makes sense to use vertical for volume and horizonal for pan in the same interface. OH! Hrrm, yes, well. I see the point, but I don't think it will work. Differing semantics for similar-looking widget is the worst of all possible choices. Not if the pan sliders are laid out horizontally :-) I was speaking of knobs. A horizontal slider is obviously visually different from a vertical one. A horizontally-linear knob is not obviously different from a vertically-linear knob :)
Re: [linux-audio-dev] Knobs, the reply
On Thu, Jun 10, 2004 at 11:56:30PM +0100, Steve Harris wrote: I was speaking of knobs. A horizontal slider is obviously visually different from a vertical one. A horizontally-linear knob is not obviously different from a vertically-linear knob :) I dont think theres any reason to support up-down and not left-right at the same time. Having it work in two dimensions is ok, but I don't know that it's actually as obvious as up/down. In fact, 1 dimension makes it easier to get small incrments by moving diagonally. Your hand is not good at very small movements, so you can make a moderately sized movement diagonally, which has a small vertical component. This lets you get very small vertical tweaks.
Re: [linux-audio-dev] Knobs / widget design
On Wed, Jun 09, 2004 at 10:38:49PM +0200, Thorsten Wilms wrote: If you ask me, radial is the only right way of mouse control for I have to disagree. Sometimes I close my eyes to ensure that I am only using my ears to make adjustments, and a radial knob just SUCKS at that. IMHO the right way is left or down = decrease, up or right = increase. In fact, I am not convinced left/right should even factor. Tim
Re: [linux-audio-dev] Knobs / widget design
On Wed, Jun 09, 2004 at 10:38:49PM +0200, Thorsten Wilms wrote: SVG vector graphics (prefered by Peter and me) http://wrstud.uni-wuppertal.de/~ka0394/forum/04-05-02_knobs_02.png 3d rendering variatios http://wrstud.uni-wuppertal.de/~ka0394/forum/04-05-02_knob_3d_1-2-3.jpg I quite like them both, btw, but I prefer the SVG look (and potential for scalability). Tim
Re: [linux-audio-dev] Knobs / widget design
On Wed, Jun 09, 2004 at 07:04:58PM -0400, Dave Robillard wrote: - Left button to turn knob (radially) Left button to turn knob linearly up/down. Ctrl-Left to fine adjust 1/10th scale or whatever. How about velocity sensitive knobs like OhmForce plugs use. Uggh.
Re: [linux-audio-dev] Knobs / widget design
On Wed, Jun 09, 2004 at 11:56:59PM +0200, Arnold Krille wrote: Still the question is: What toolkit to use for a standard-LAD-Gui-elements-set? Or just define the graphics and the handling and then let everyone implement it in his/her preferred toolkit? The last would be my suggestion, and maybe I am volunteering to create on for Qt... Other way around? Define a graphics system so I can add my own knob-graphics, and you make them work.
Re: [linux-audio-dev] [OT] marketing hype
On Thu, Jun 10, 2004 at 01:11:43AM +0200, Fons Adriaensen wrote: from SuSE 8.2 to 9.0. In the new distro, most of the Gnome apps that I loved before suddenly seemed to be dumbed down to the point I really started to dislike them, and I just removed them form my system. Agree completely. It gets dumber and dumber. Options I *like* and *use* disappear in each release. Meanwhile dumb stuff appears and I can't figure out how to do simplish things. I'm using KDE now for about a week, and I can't say I like it THAT much better. Sigh. XP may have it's problems, but the UI is fast, the file browser works 99.99% of the time, and stuff just works. I know Linux people love to claim how choice is our strength, but I think it's bunk. Linux needs a single GUI environment that has a lot of deep flexibility (and I don't mean Scheme config files :) and a single widget kit, bound to all the languages. A freshly installed linux box is a horrible mess, these days. Hundreds of megs of disk spent on crap that the vast majority of people don't even know is there.
Re: [linux-audio-dev] Knobs / widget design
On Wed, Jun 09, 2004 at 08:39:15PM -0400, Dave Robillard wrote: But then you either have to click and drag up, click and drag up, click and drag up and so on because the motion is too slow, or you can't make no, I click and hold as long as I am tweaking a knob.. fine adjustments. Unless someone can think of something clever that hasn't been though of before, you can't have both with faders. hold ctrl, and the movement becomes an order of magnitude finer-grained. It works really well. :P
Re: [linux-audio-dev] Knobs / widget design
On Wed, Jun 09, 2004 at 08:40:09PM -0400, Dave Robillard wrote: - left click/drag adjusts radially I just can't get used to radial turning, I find it obnoxious, and know many who feel the same. Linear was obvious to me. Radial was very non-obvious. - control click adjust linearly (x axis coarse adjust, y axis fine adjust) no! Having the two axes mean different things is bad. No one mouses in a perfectly straight line. - middle click resets to default/0/whatever - right click for context menu There really needs to be some global option for radial vs. linear knobs. I want all my knobs linear, always. so I see: * left-click = coarse asjust (radial or linear) * ctrl+left-click = fine adjust * double-click = edit I don't like a 'reset' button. Reset to what? 0? the preset? the last save-point? If there has to be a 'reset' it should be in the context menu (though I guess I don't feel too strongly about it :) Too many clicky options is confoosing.
Re: [linux-audio-dev] Re: UI stuff
On Tue, Jun 08, 2004 at 04:50:40PM -0500, Ben wrote: and Murphy's law says your first 2 guesses will be wrong. The app Soundplay for BeOS takes a novel approach ... the level is shown as a knob but when you grab it, a rectangular box appears behind the knob and you adust it like a fader. This is great because it gives you visual feedback of which direction(s) to move the knob. FL Studio does something similar for some knobs. When you click it, a vertical progress-bar pops up next to the knob, which makes it quite clear that you move the mouse UP and DOWN to change the level.
Re: [linux-audio-dev] initial release of libfst - in-process VST support
On Mon, Apr 19, 2004 at 05:29:00PM -0400, Dave Robillard wrote: Should we maybe organize a letter-writing campaign or something like that to attempt to convince Steinberg to make VST free? My understanding was that they would do it, except that the SDK doesn't work in g++. GMPI will (maybe) obsolete that all, one day. Until then, a free VST is a great answer.
Re: [linux-audio-dev] IRQ rotation
On Fri, Mar 05, 2004 at 03:06:27PM +, Steve Harris wrote: It used to be possible (in the 2.0 kernel series) to the rotate priority of IRQs on the two controllers. This sounds really good as on my laptop the soundcard is welded to IRQ5 (very low priority) and everything else is on IRQ10 (higher, c.f. http://myweb.cableone.net/eviltwin69/Arcana.html sec 2.4), so I can only run the card with big buffers. This really mattered? I'm honestly DEEPLY surprised, and a bit sceptical. IRQ priority will only matter AT ALL if you are in a constant state of interrupt, or your IRQ handlers are painfully slow, neither of which should be true. DMA ATA mitigates IRQ storms a LOT, and you shouldn't be flooding the net while you play low-latency audio. Those are the two biggest sources of IRQs. Curious to see how it changes with a new laptop..
Re: [linux-audio-dev] IRQ rotation
On Fri, Mar 05, 2004 at 06:30:58PM +, Steve Harris wrote: This really mattered? I'm honestly DEEPLY surprised, and a bit sceptical. IRQ priority will only matter AT ALL if you are in a constant state of interrupt, or your IRQ handlers are painfully slow, neither of which should be true. Heres /proc/interrupts after ~3 hours of uptime. CPU0 0: 12578480 XT-PIC timer 1: 22347 XT-PIC keyboard 2: 0 XT-PIC cascade 5: 0 XT-PIC Maestro3 8: 1 XT-PIC rtc 10: 58915 XT-PIC usb-uhci, ohci1394, eth0, Texas Instruments PCI4451 PC card Cardbus Controller, Texas Instruments PCI4451 PC card Cardbus Controller (#2) 11: 774663 XT-PIC nvidia 12: 28909 XT-PIC PS/2 Mouse 14: 16635 XT-PIC ide0 NMI: 0 ERR: 0 Everything beats the soundcard, including the video drivers. It shows that your soundcard had ZERO interrupts. I have trouble believing that over the course of THREE HOURS it tried and tried and could not get a single interrupt through. Is that what you're saying? This does not show a particularly high interrupt load, either. It does show that you get about 70 video interrupts per second (ask nvidia!) and it shows that you seem to have the timer at 1024 HZ (lowlatency patch?).
Re: [linux-audio-dev] IRQ rotation
On Fri, Mar 05, 2004 at 08:35:06PM +, Steve Harris wrote: No, I hadn't used the ALSA modules :) The interrupts get through unless I use 2048 samples / period, if I do ALSA reports lost interrupts constantly. hrrmm...I doubt if it is due to IRQ priorities. I mean, really, any modern CPU can handles 10s or 100s of thousands of IRQs per second.. This does not show a particularly high interrupt load, either. It does show that you get about 70 video interrupts per second (ask nvidia!) and it shows that you seem to have the timer at 1024 HZ (lowlatency patch?). You get one per screen refresh dont you? Not on my system :) Many systems don't even have an IRQ for video. What would the video IRQ need every refresh? You're not punping data there constantly unless the screen is changing..
Re: [linux-audio-dev] IRQ rotation
On Fri, Mar 05, 2004 at 10:19:47PM +, Steve Harris wrote: hrrmm...I doubt if it is due to IRQ priorities. I mean, really, any modern CPU can handles 10s or 100s of thousands of IRQs per second.. Hm... ok. I dont think its a s/w problem FWIW, other people I know with the same machine (dell i8100) have the same problem. Interesting problem - not sure how I'd attack it...
Re: [linux-audio-dev] [ANN] First public release of Lindrum v 0.5.1
On Mon, Mar 01, 2004 at 12:55:14PM -0500, Dave Robillard wrote: On Mon, 2004-03-01 at 07:07, guenter geiger wrote: Lack of collaboration is one of the weaknesses of the free software development (peculiarly enough it is considered one of its strenghts), especially with audio software. A weakness compared to what? Proprietary software is /definitely/ not immune to this problem (in fact, I'd say it's far worse - there's no collaboration whatsoever). Is is really a weakness of free software if non-free software has the same problem? I don't hear people complaining about Steinberg and Emagic 'duplicating effort'. How many OSS projects are aiming at similar goals? Each one has one or two people on them. If you put 5 or 6 people on one project, it would have a much better chance at competing with the big boys*. (*) Assuming smart people who could find a common vision. ;)
Re: [linux-audio-dev] [ANN] First public release of Lindrum v 0.5.1
On Mon, Mar 01, 2004 at 03:20:46PM -0500, Dave Robillard wrote: Speaking of GMPI, what's the status there anyway? Coincidentally, my dream modular synth (and effects bay) could use a more advanced plugin format than LADSPA... Is there a GMPI progress page or something like that? http://www.gmpi-plugins.org has the work-in-progress requirements doc. The mailing list archive on freelists.org has the work-in-progress messages. We're at requirements and it is slow. Much slower than I hoped for. But now is the time to make your needs known.
Re: [linux-audio-dev] {draft} setgid problems with GTK for realtime audio (long)
On Fri, Dec 12, 2003 at 10:56:17AM -0600, Jack O'Quin wrote: If refusing to run with any privileges is their goal, then they have failed completely. We do it all the time right now using JACK capabilities, which bypasses their checks entirely, or by running as root with `sudo' or `su'. This is the heart of their problem. GTK *cannot tell* when it is running at elevated priviledge levels. It does not detect privilege levels at all, but merely disallows two of the 17 possible ways of gaining privilege. By disallowing the mechanism but not the privilege their action becomes counter-productive, forcing people to use cruder mechanisms than would otherwise be necessary to acquire the privileges they need. Those might be lightened a bit, but they might go well into your letter.
Re: [linux-audio-dev] Linux Security Module for realtime audio
On Thu, Dec 11, 2003 at 10:00:16AM +0100, [EMAIL PROTECTED] wrote: But, I don't know how to query the module parameters, and that would certainly be useful. setting up a proc readable file is not so hard. making a proc file is trivial, really. I have lots of example code for simple proc file interfaces (read and write). Need it?
Re: [linux-audio-dev] Linux Security Module for realtime audio
On Thu, Dec 11, 2003 at 09:15:50AM -0600, Jack O'Quin wrote:
I've been looking at that, and plan to do it next. A good example is
always helpful. It can help to avoid missing some subtle detail,
especially important for kernel-mode programming.
Here is some of the boilerplate code we used. Also have code to make a proc
dir and use it, so instead of /proc/realtime or what not, you could have
/proc/realtime/a, /proc/realtime/b, etc. Also have code to do a read/write
proc file.
These are against linux-2.4. Haven't played with proc on 2.6, yet.
#include linux/proc_fs.h
#ifdef CONFIG_PROC_FS
static struct proc_dir_entry *proc_foo;
#endif
init(...)
{
...
#ifdef CONFIG_PROC_FS
proc_foo = create_proc_read_entry(foo, 0, NULL, foo_read_proc, NULL);
if (!proc_foo {
printk(KERN_ERR can't create /proc/foo\n);
}
#endif
...
}
cleanup(...)
{
...
remove_proc_entry(foo, NULL);
...
}
#ifdef CONFIG_PROC_FS
static int
foo_read_proc(char *buf, char **start, off_t pos, int len, int *eof, void *x)
{
int plen;
plen = sprintf(buf, %s\n, foo);
/* trying to read a bad offset? */
if (pos = plen) {
*eof = 1;
return 0;
}
/* did we write everything we wanted to? */
if (len = (plen-pos)) {
*eof = 1;
}
*start = buf + pos;
plen -= pos;
return (len plen) ? plen : len;
}
#endif
Re: [linux-audio-dev] {draft} setgid problems with GTK for realtime audio (long)
It needs some nice ending. We respectfully ask that you reconsider the implementation of this check. Or something
Re: [linux-audio-dev] Linux Security Module for realtime audio
On Mon, Dec 08, 2003 at 05:12:50PM -0600, Jack O'Quin wrote: If you accept my arguments why this is not the right solution, then the question remains, what to do about GTK-2? I don't suppose the GTK developers are likely to take the test out just because we ask them. Have we tried? It seems like a deeply paramoid check, to disallow sgid programs. Is that REALLY the business of the toolkit? I think they're overstepping their bounds, and they need to be reminded that some OTHER people need stuff like that.
Re: [linux-audio-dev] Linux Security Module for realtime audio
On Tue, Dec 09, 2003 at 12:49:24AM +0100, Jesper Anderson wrote: GTK has been like that for years now. Check the archives of SLASH'EM, a Nethack clone, for lots of back and forth. In short, they're not going to change. Do they have a valid reason? Or are they just imposing their paranoia on us for fun?
Re: [linux-audio-dev] Linux Security Module for realtime audio
I apologizer if this has been discussed, but I haven't read the whole thread. Has the idea of a simple sched_rr helper been discussed? It can be setuid and only executable by a specific group. rtsched my_rt_app setscheduler drop privs exec I guess that doesn't help mlockall(), though. Hrrm.
Re: [linux-audio-dev] cute idea from the VST world ...
On Thu, Nov 20, 2003 at 09:21:18AM +, Steve Harris wrote: On Wed, Nov 19, 2003 at 11:08:06PM -0500, Paul Davis wrote: http://www.fxfreeze.com/product.html It's such an obvious idea, too. I much prefer their fxTeleport product. I've had visions of doing something like that for a long time.
Re: [linux-audio-dev] plugin GUIs
On Tue, Nov 18, 2003 at 10:45:40AM -0500, Paul Davis wrote: i offer this as a proof of concept. i believe that our problems with GUIs for plugins are pretty much over, modulo defining some standards as per another recent from me. Paul, I freely confess that I do not know how X works. Can you explain a bit more for the dummies (like me) what you've come up with, what it means, and how we can use it for the GMPI discussions? Tim
Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24
On Mon, Nov 17, 2003 at 08:39:10AM +0100, Melanie wrote: userspace and runs as root. Errm, since when does PAM run as root?
Re: [linux-audio-dev] LADSPA: proposition for polyphonic use of plugins
On Mon, Nov 17, 2003 at 07:48:53PM -0500, Paul Davis wrote: Well, we COULD discuss this with the QT/GTK folk. However, I personally i already am :) Excellent. Please keep us appraised :) QT and GTK would take care of the majority of Linux issues.
Re: [linux-audio-dev] last CFP: LCA2004 audio miniconf
On Tue, Nov 11, 2003 at 06:41:14PM +1100, Erik de Castro Lopo wrote: Yahoo! It seems I will be at LCA. So tell me, do I stay at the dorms (St. Marks) or do I get the hotel? :) The hotel is for tried old farts like me and the dorms are for people who like to party. That said, even though I am a tried old fart, I will be in the dorms :-). I missed this year's LCA due to the birth of my daughter but the dorms were fine for LCA in Brisbane in 2002. Wow, and I had just about decided on the hotel. Maybe I'll do the dorms ater all. :) Tim
Re: [linux-audio-dev] last CFP: LCA2004 audio miniconf
On Tue, Oct 28, 2003 at 07:42:54PM +1100, Conrad Parker wrote: This is the last reminder for anyone interested in presenting at the audio mini-conference at Linux.Conf.Au, Monday January 12 2004. Submissions are due at the end of this week (Fri 31 Oct), details at: Yahoo! It seems I will be at LCA. So tell me, do I stay at the dorms (St. Marks) or do I get the hotel? :)
Re: [linux-audio-dev] last CFP: LCA2004 audio miniconf
On Tue, Oct 28, 2003 at 07:42:54PM +1100, Conrad Parker wrote: This is the last reminder for anyone interested in presenting at the audio mini-conference at Linux.Conf.Au, Monday January 12 2004. Submissions are due at the end of this week (Fri 31 Oct), details at: I am still working on my clearance to attend LCA, but assuming that flies, I *will* be at the audio mini conf. I don't have a presentation to do, but I'd love to do a GMPI reqs/spec and plugins in general BoF or get-together or something. -- Notice that as computers are becoming easier and easier to use, suddenly there's a big market for Dummies books. Cause and effect, or merely an ironic juxtaposition of unrelated facts?
[linux-audio-dev] GMPI - requirements
One of my tasks as part of GMPI is to provide a draft of the requirements doc. I turn tp you all. If you have requirements that you think should be in GMPI - please let me know. These have to be requirements. Not handwaving though explosions, and not wishful dreaming. Things that are required or desired that will make GMPI be the open music platform we need. Feel free to email me privately or publicly. I'll be happy to condense ideas and to extract requirements from whatever you have for me. Trying to get the ball rolling again... Tim -- Notice that as computers are becoming easier and easier to use, suddenly there's a big market for Dummies books. Cause and effect, or merely an ironic juxtaposition of unrelated facts?
Re: [linux-audio-dev] GMPI - requirements
On Tue, Oct 21, 2003 at 05:17:24PM +0400, horsh wrote: 1) jack-transport-like and 2) LADCCA-like functionality? Those are not requirements, they're wishlist items. What are the requirements? Break it down to a set of statements that say something like GMPI must provide... or GMPI should define Or explain in a lot of detail what you want. -- Notice that as computers are becoming easier and easier to use, suddenly there's a big market for Dummies books. Cause and effect, or merely an ironic juxtaposition of unrelated facts?
Re: [linux-audio-dev] some more GMPI thoughts
On Tue, Oct 21, 2003 at 06:43:14PM +0400, horsh wrote: 1)is API monolithous or there are sub-APIs like GMPI-audio, GMPI-seq, GMPI-control These are requirements. It's not time to decide such things. Hopefully, it's one main API, with as few as possible support APIs (which are required so they really are just one API :). 2) Explicit versioning for API? Versioning of...? 3) Explicit versioning for plugins? of course 4) uniq IDs for plugins? who is authority? Not sure that UUIDs are a great idea. URIs could work, or... What is your requirement here? What do you need it to do? Don't design a solution, just define the problem. 5) format for plugin state saving: XML? (damn its ugly!) I vote for more YAML-like language. We're not designing solutions, just requirements, right now. It's fine to have a solution to a requirement, but remember that this is a bigger group. I don't even know what YAML is. XML is a somewhat obvious answer for portable data, but that may be beyond the scope of GMPI. 6) Should the GMPI discussion produce reference plugin implementation reference host implementation reference tools implementation This I have covered in my current draft ;) 7) Can there be off-line non real-time plugins? This is mentioned in passing in my draft. What is your requirement? Thanks for the thoughts. If we can boil them down further we'll get what I need :) -- Notice that as computers are becoming easier and easier to use, suddenly there's a big market for Dummies books. Cause and effect, or merely an ironic juxtaposition of unrelated facts?
Re: [linux-audio-dev] GMPI - requirements
On Tue, Oct 21, 2003 at 06:51:16PM +0200, Joern Nettingsmeier wrote: * it should be elegant, or even beautiful * it should be fun to program with Can't exactly put that in a requirements doc, though I think it is on my mind :) * it *must* be easy to support in host applications This is mentioned * it *must not* force any particular choice of toolkit or language upon the implementer of either the host or the plugin The API will be C. GUI has not been discussed much.. * it must be free without loopholes (bsd or lgpl) * specs and sdk must be available free-of-charge I have covered both of these ;) * the surrounding community must be hospitable towards non-professional developers This is not a req, but social engineering. I'm not worried about it. VST has a wide base of amateur and hobbyist and open source developers. * both the licensing and the community atmosphere should not discourage closed-source commercial implementations while still conveying enough free spirit to make commercial vendors play fair and participate in or even donate something back to the community This is a task for lawyers. The reqs doc does cover this, though.
Re: [linux-audio-dev] some more GMPI thoughts
On Tue, Oct 21, 2003 at 07:50:38PM +0100, Steve Harris wrote: We're not designing solutions, just requirements, right now. It's fine to have a solution to a requirement, but remember that this is a bigger group. I don't even know what YAML is. XML is a somewhat obvious answer for portable data, but that may be beyond the scope of GMPI. It probably should be in the spec, or at least a recommended schema. There better be a good reason for it being anything other than XML. The *spec* certainly. But requirements? The requirement seems to be GMPI should have a standard preset file format. That format must be flexible, extensible, well-defined, hierarchical, and human-editable pure ASCII. Does that cover it? -- Notice that as computers are becoming easier and easier to use, suddenly there's a big market for Dummies books. Cause and effect, or merely an ironic juxtaposition of unrelated facts?
[linux-audio-dev] Athlon64
I'm potentially in the market for a new box before end of year. Has anyone found anything to show whether Athlon64 (or the high-end FX line) are worth it for audio? Assume some legacy audio code under legacy OS :-/ Tim
Re: [linux-audio-dev] Oss threading -- is it possible
On Fri, Oct 10, 2003 at 11:14:17PM +0300, Jussi Laako wrote: On Fri, 2003-10-10 at 19:28, Paul Davis wrote: you need to additively mix your two signals. writing them to DSP orders them sequentially in time. it doesn't mix them. The commercial OSS driver does mixing and samplerate conversion. OSS is the most disgusting API I have ever seen. For that reason alone, I don't want to use it. I have this thing about paying attention to details, and the OSS API, well, doesn't. -- Notice that as computers are becoming easier and easier to use, suddenly there's a big market for Dummies books. Cause and effect, or merely an ironic juxtaposition of unrelated facts?
Re: [linux-audio-dev] GAP: Audio API again
I'm not so skilled like the developers you cited, but perhaps I can contribute with some ideas I didn't see considered. I haven't done it yet for the reasons I've written. I haven't seen any reasons for keeping quiet except that you aren't happy the MMA is running, it, which is hardly a reason. If you want to have influence, open your mouth and tell us what you think is wrong. -- Notice that as computers are becoming easier and easier to use, suddenly there's a big market for Dummies books. Cause and effect, or merely an ironic juxtaposition of unrelated facts?
Re: [linux-audio-dev] GMPI?
On Sat, Sep 27, 2003 at 06:27:45PM +0200, Marco Ballini wrote: I'm reading the messages but I can't easely find the final decisions for each item of the agenda. Maybe I could post my ideas and let the partecipants to the list answer if it has been decideded accordingly to them or not? The summaries usually have a subject that is like Summary x.y:. Please don't re-open cans of worms on the GMPI list. If you have specific questions, ask me, and I'll tell you the current status, if it has been decided. Tim -- Notice that as computers are becoming easier and easier to use, suddenly there's a big market for Dummies books. Cause and effect, or merely an ironic juxtaposition of unrelated facts?
Re: [linux-audio-dev] what happened to XAP?
On Wed, Sep 24, 2003 at 05:21:33PM +0100, Steve Harris wrote: On Wed, Sep 24, 2003 at 07:44:43PM +0200, Marco Ballini wrote: So, what happened to XAP? GMPI: http://aulos.calarts.edu/pipermail/music-dsp/2003-February/022272.html Is this list the right place for discussion on it? I think XAP has been put on hold. GMPI is a much more promising project, though its progressing quite slowly. I've laid all my hopes on GMPI. If the GMPI process continues to hurt so much, maybe XAP should progress asynchronously. It can always adapt to GMPI later. -- Notice that as computers are becoming easier and easier to use, suddenly there's a big market for Dummies books. Cause and effect, or merely an ironic juxtaposition of unrelated facts?
Re: [linux-audio-dev] exploring LADSPA
On Thu, Aug 14, 2003 at 01:24:50AM -0400, Paul Davis wrote: and other controllers using (yuck) MIDI for now. LADSPA is interesting but I do not see where it handles some of the issues of polyphonic voicing and assignment control. it doesn't. it was never meant to. attempts to create an API that did do this led to discussions here (on LAD) about XAP, but this has just about all moved to the GMPI mailing list, where us LAD'ers get to hang out and talk shop with the guys at Cakewalk, Adobe, FXpansion, and several other companies who work on plugins and DAWs. devising your own new API at this time is a bit like, err, err, i don't know what its like but its like something. It's like designing a new windowing system. You MIGHT do better, but lots of really smart people have done worse. I'd actively beg that anyone who has a lot of thoughts on this PLEASE catch up on GMPI and join in the fray. The XAP ideas have actually been pretty well received so far, and the LAD community is doing a lot to stop the Mac and Windows people from screwing this up yet again (Paul, Steve - my thanks!). not missing the point. i welcome any and all developers to LAD and to LADSPA. but those who don't know and understand history are condemned to repeat it, and the linux world is full of repeated false starts while all the time promising projects cry out for more assistance to flesh them out. I too started my own plugin API to replace LADSPA for multichannel IO and instruments etc. It's a BIG problem to do really right. I think XAp had some REALLY clever ideas come out of it. GMPI is sanctioned by the MMA - if ANYTHING has a chance at succeeding cross-platform, that is it. Yes, it is a SLOW process. Yes, you'll have to make concessions to Windows developers. But in the end, you might just have a real winner of an API. Tim
Re: [linux-audio-dev] exploring LADSPA
On Thu, Aug 14, 2003 at 12:22:06PM +0100, Steve Harris wrote: On Thu, Aug 14, 2003 at 09:48:45AM +0100, Steve Harris wrote: I would activly encourage people who are interested in this subject to learn what they are doing before entering the fray. GMPI needs more random unevaluated ideas like it needs a hole in the head. This is a bit harsh, sorry, I didn't mean to be so negative. I'd been having a bad day. :) np. I actually think random ideas are wonderful - that is how you break out of ruts. -- Notice that as computers are becoming easier and easier to use, suddenly there's a big market for Dummies books. Cause and effect, or merely an ironic juxtaposition of unrelated facts?
[linux-audio-dev] kernel 2.6
All, I haven't used kernel 2.5/2.6 for any audio stuff yet. I'm at the Linux Symposium this week - do we have any requests or gripes with 2.6 that I can relay to the core kernel guys? Audio is a workload they don't really test. Tim
Re: [linux-audio-dev] New form of GPL licence that protects Linux from proprietary world [was: New powermacs?]t
In the end, we will not reap what we have sown. Users on the OS X will be theoretically able to run Ardour as much as we will, especially now that jackd has been ported to OS X. To me, this does not seem right. I guess I don't see it as a problem. Forcing people to use this or that software is exactly what GPL is AGAINST. Use whatever works for you. Perhaps we should make a mended version of GPL that would have exact permissions like the original GPL license, but in addition would ask that the software cannot be run on top of proprietary OS. This way, we can make our software indigenous only to free/oss OS's and hence create I guesss feel free to do it with your own software - I don't know that such a proviso is in my best interests..
Re: [linux-audio-dev] lock-free ring buffer code
Attached is the fifo I've had banging about. It uses atomic_t. OK, I haven't been programming much lately, but when did I miss atomic_t becoming a part of any C standard? Also, several people have referred to the atomicity of int/pointer read/write. This is news to me - can someone point me at the spec for this?
Re: [linux-audio-dev] lock-free ring buffer code
Also, several people have referred to the atomicity of int/pointer read/write. This is news to me - can someone point me at the spec for this? its an architecture-specific issue. its not true on SPARCs and on some NUMA systems. it has nothing to do with a language per se. Is it really true on x86? Being that you can do unaligned accesses just fine, you can certainly do cross-cacheline accesses. Pardon the skepticism, but I've never heard such assertions before. Can anyone offer me a specification for this?
[linux-audio-dev] lock-free ring buffer code
i remember i have read a statement about a lock free ringbuffer implemented in C somewhere. courtesy of paul davis: you should use a lock free ringbuffer. we will be adding example code to the example-clients directory soon. existing code is in ardour's source base (for C++). the example code will be in example-clients/capture_client.c. where ardour is ardour.sf.net. (i doubt there is anything hugely non-C in the ringbuffer code proper). maybe it's just me, but I can't find said file...?
Re: [linux-audio-dev] XAP again - channels, etc.
Interesting stuff worth talking about. Is this a clean, natural division? I don't think so. Why does the model treat the output of an envelope generator as being (in many respects) more like a string than it is like an oscillator output? Why isn't it clear what an LFO's output type should be? Why does something as simple as a ramp spawn so much complexity? Some good questions. In fact, maybe an LFO _should_ be audio data. Or at least Audio-rate. But one can argue that an LFO is LF enough that you can represent it reasonably well with a series of short linear ramps, and have less overhead. Maybe XAP should consider some method of identifying Audio-rate control ports. If your control expects audio-rate input, you should be able to ask for it? Why not use actual audio ports for that, then, and just hint that they are control signals? An envelope generator or an LFO should be audio outputs that go into audio inputs. Maybe. Even where the audio/event distinction looks clear cut, its not. The user toggles a switch. Thats an event, surely? We... maybe it is, but then, what does the plugin do with the event? If the switch is switch *is* an event. But the rise and fall characteristics should belong to the owner of the source, not to the destination. An app Disagree, here. The flip of a switch is a binary event. The receiver needs to handle it. Non-binary things like knob turns will already either be interpolated by the sequencer, by a custom UI, or by the plugin. Or all three.
Re: [linux-audio-dev] XAP again - channels, etc.
why support the difference between ports and controls ? This is done in the C galan and tony somehow managed to remove this difference in the C++ galan. Because throughout all the XAP discussions we have made it clear that controls are event-driven and ports are audio-rate data (specifically audio data). Controls are more flexible in their data typing. We have argued many hours about th ebenefits/drawbacks of using normalized float data for everything and the decision we came to was that it just isn't the best model. I point you at th earchives for the discussions :) I have not read much of this code but tony said he managed to remove this. LADSPA is much the same way - connect anything to anything. But several people in the XAP discussion feel that normalized data (0 to 1.0 or whatever) is bad. I am still of the position that I could be convinced to support two basic control types: numerical (normalized) and other (strings, data block, etc). This, however, is still not the same as audio-rate controls, which is what you get when you plug an oscillator into a knob. The simplest concept is that they are different things. Audio and Control data. Reconsidering this notion would takes us WAY back to early XAP discussions. Maybe that is OK - anyone want to make a case for a new fundamental model? Tim
Re: [linux-audio-dev] XAP again - channels, etc.
i know that. In galan it is the same. But why should this difference be so clearly stated in the API ? Can you show me a nice API that makes the two feel similar? Controls: multiple datatypes, receive events in time-order queues Ports: are assigned buffers (possibly datatyped) of arrays of data We could, I suppose, send an event for each block which contains the buffer pointer for each port, thereby making a Port a type of control. Is there a benefit to that? It seems to just hide what a Port is behind a control. If in the face of gmpi it still makes sense to specify XAP we should make it supersede gmpi. But as acceptance is the biggest API feature i doubt this makes sense. Even if GMPI is a smash success, having XAP to the alpha or beta stage will lend us a lot of credibility when we say to GMPI This is how XAP does it, here is the code, and here is the analysis. And GMPI won't be done for at LEASt a year. no... galan is almost an XAP implementation. read the XAP early scribbles thread i respawned. Nothing can be a XAP implementation yet, because we have fundamental model issues we have not solved. I know David uses Audiality to model and prove some of the XAP ideas, but it is hardly a XAP implementation, yet :) Tim
[linux-audio-dev] XAP again - channels, etc.
I fear we've all been very busy. I know I have. I have not had time to
devote to XAP, though I have certainly not lost interest.
So today I start looking at my evolving spec doc again. The biggest chunk
of undecidedness lies in the area of Channels. We never really resolved the
Bays/Channels etc debate. We just put it off. Here it is.
I'd like to propose the following - it is simple and flexible. Not too
confusing.
Plugins define 'Modules'. Every plugin has a master Module, and 0-n extra
Modules. The host can instantiate Modules as needed. A Module is analogous
to a MIDI Channel in a synth (maybe Module is the wrong word). It is
analogous to a slot in a mixer.
struct XAP_descriptor {
...
/* master module descriptor */
XAP_module master;
/* other channel descriptors */
int n_modules;
XAP_module *modules;
/*
* Instantiate a module, return a plugin-unique
* id/index for it - it's 'Channel'.
*/
int (*add_module)(void *plugin, int module);
/*
* Remove a module.
*/
int (*del_module)(void *plugin, int index);
};
struct XAP_module {
char *label;
char *name;
uint32_t flags;
/* how many instances of this module are allowed? */
int count_max;
/* per-module controls and I/O */
int n_controls;
XAP_control **controls;
int n_ports;
XAP_port **ports;
};
Re: [linux-audio-dev] Help wanted with audio app design
I have been working on an audio processing/synthesis application that should have the power of Reason and Buzz plus the ability to be used effectivly in live proformance. Some of you may have read my earlier emails on this subject. I call it Voltage. galan has the same goals... the design is nice. tony did a great job. Sorry all - I've been away and then I had to build out a new PC - old one died. The reason I got started in XAP was because I wanted a Linux based FruityLoops. We all have similar goals. But I decided a proper API had to come FIRST. :) Tim
Re: [linux-audio-dev] Damned .org domains...
Now, should I try some others instead? xapaudioplugins.org (*heh*) or whatever? Not all that interesting, of course... lad-xap.org xap-audio.org xap-plugins.org or xapaudioplugins are all ok.. Well, I could try and contact the owner of xap.org. Doesn't seem to be Xap Corporation (who owns xap.com), but they'll probably want some extra bucks anyway. try it...can't hurt..
Re: [linux-audio-dev] Damned .org domains...
xap-plugins.org All are available, though I'm not sure about the lad one. Makes it sound more Linux specific than it really is. Which one? Other ideas? I like this one..
Re: [linux-audio-dev] Call for participation: MMA GMPI working group
Some sort of (seperate, technical) statement from the l-a-d community about what features we'd like is probably a good idea too. We have more experiences in some areas than the closed plugin systems, eg. plugins as modular synth modules, natural ranges*, seperating UIs from DSP code** and metadata. Yes - rather than flood with duplicate requests. My immediate thoughts: * Implementable in C, not C++ * Agnostic about multiple inputs/outputs * Event driven * No MIDI legacy, but able to automagically connect MIDI hints * Named audio ports (Left, Right, etc) for clever connections between plugins * Native support/hints for control types - Float/Int - Boolean - Enum - String * Arbitrary per-voice continuous controls * Some way to seek into long samples (optional for plugins to support) * Mono float buffers
Re: [linux-audio-dev] XAP and GMPI
and all the other things I rant about that I've forgotten ;) Well, now we could use a nice summary of our conclusions... :-) I'm working on that!
Re: [linux-audio-dev] XAP domain [was: Call for participation: MMA GMPI working group]
If your really worried about longevity you can still request a sub-URI from an authority (like LADSPA uids are handed out), eg. http://www.xap.org/steves-plugins/... BTW, should I grab that domain? (Before someone else does, just to piss us of or something.) Could point it directly at my XAP site for now. if it is available, go for it. Or I can stick it on my co-lo if you prefer. Tim
Re: [linux-audio-dev] XAP domain [was: Call for participation: MMA GMPI working group]
Either way, I'm just a few clicks away from [www.]xap.org for 2 years with automatic extension. Go? :-) go for it - we'll pitch in and help cover the (20 dollars?) cost :)
Re: [linux-audio-dev] XAP domain [was: Call for participation: MMA GMPI working group]
go for it - we'll pitch in and help cover the (20 dollars?) cost :) That won't ruin me, so there's no need for that. :-) Unfortunately, my bank server is closed this time of day, so I can't get any further right now. The ISP is waiting for the payment. would you rather I get it? I can still get it today
Re: [linux-audio-dev] PTAF link and comments
On Sat, Feb 08, 2003 at 07:41:43 +0100, David Olofson wrote: As a matter of fact, if you just loop the output back to the input, the LEARN switch is all you need. Whenever you flip the switch to off the new data would be send back to the input. When you save a preset, the host would see the connection of the input and go look for the current value - which it finds on that output. This is starting to sound like a really nasty hack. I'm starting to agree. I really dislike the idea that the host has to read a plugin's output control to get extra stuff for a preset. If there really is extra stuff, let's do it properly. I'm not sure yet that there is a need for it, so let's just back-burner it? Tim
Re: [linux-audio-dev] XAP spec PTAF comments [merge]
[silence detection] You still have unpredicatable CPU load, which makes it pretty useless. ...for you
Re: [linux-audio-dev] XAP spec PTAF comments [merge]
Branching to fill your delay line with explit 0.0's intead of reading them
from a buffer of zeros doesn't help. We allready know that reverbs cant
support it at all. Efficieny reasons would also rule out flangers, delays,
most filters and choruses.
Maybe I'm missing something, but how can a test that amounts to this NOT be
faster than doing any work at all?
if (me-silent XAP_BUF_SILENT(me-in[0]) XAP_BUF_SILENT(me-in[1])) {
return;
}
I would never, ever use a silence detecting system live, you never
know when its going to suddenly wake up all the plugins and run out of CPU
power.
All it would take was a bit of unexpected noise on an input line and
suddenly the CPU load goes up 300%.
You may be right for a lot of cases, but there are cases where a live
performance is nothing but on the fly loop-layering, or pattern-based
sequencing. No live input, no accidentally triggering an otherwise silent
subnet. In fact, large portions of the tree would be muted at any one time
in the host.
Whether it makes sense or is a good idea, people are doing it now. And I
have a penchant for faster computers.
As for the 'feature' - let's keep it in mind, and we'll see how it fares.
If it is not effective, or the burden is really too much, we'll scrap it.
That is why discussions like this are so great.
Re: [linux-audio-dev] PTAF link and comments
I'm starting to agree. I really dislike the idea that the host has to read a plugin's output control to get extra stuff for a preset. This is not an exception. It has to do something like that all the time, since inputs are not readable. Has everyone forgotten that? We don't have to do this for most controls because the host knows what was last written to each input. And we only save inputs in a preset, right? However, these assumptions make a problem: 1) Writing a preset or saving the plugin state involves writing the value of all the plugin's (input) controls. 2) Controls can be directly connected, needing no host intervention 3) Controls are not readable 2 and 3 lead us to conclude that if the host does not snoop every event, it does not know the value of some controls. So how can it write them out? Either the host has to snoop every event in order to cache every single control change, or controls need to be directly readable somehow. Is it so bad to have a control-get_value() method ?
Re: [linux-audio-dev] PTAF link and comments
If we allow hard ranges (not really neccesary, as LADSPA shows) then the
host should enforce them.
Remind me why we want soft ranges? I'm more of the mind that all ranges are
hard ranges, except for {pos/neg} infinity.
If a control is going to the effort of specifying a range, don't we want to
respect it ALWAYS.
Re: [linux-audio-dev] XAP spec PTAF comments [merge]
something out... It just seems to me that plugins have a better idea how to clamp - and they can quite often use constant limits as well, I guess. I'm fine with this. If the plugin can constrian the inputs itseelf, it seems reasonable not to have explict host support. We know it works, and its Simple(TM) Yeah. It's always a good idea to consider alternatives, I guess we haven't seen any sensible ones yet... Assuming we really want to allow soft-limits (which I just don't get), we can just say that if you want a hardlimit, constrain it internally. I'm all for optimizations, but really, this is a MICRO MICRO MICRO MICRO optimization. SOMEONE SOMEWHERE is going to do a conditional and constrain. Be it the host or the plugin. Let's just say that all ranges are suggestions, and if it matters, it is the plugin's problem. If we later find this to be a big problem, we'll deal with it. Fair? I do see your point, but I'm not certain whether or not this optimization is really useless for normal one song at a time use. Some real life test data would be really interesting... Yeah, that's one of the reasons why I can't quite make up my mind on this. This feature is not for free, so it has to be seriously motivated. I think it can come almost free. Plugins that don't optimize, do nothing. Plugins that want to optimize do an extra flag check. Not too hard. Besides, if you have seriously heavy plugins in combination with this a few effects at a time behavior, the host could probably optimize this a bit without plugins explicitly supporting it. It means the host has to test buffers and figure out a clean way of activating and deactivating plugins without side effects, but if the plugins, or whole sub nets of plugins can be disabled, it's still a big win. ...and doesn't require any API support whatsoever, apart from the (de)activation stuff, which is needed anyway. This was more or less what I originally proposed. If a plugin can indicate that it will not do anything unless more (non-zero) signal turns up, it can be virtually removed from the tree. Except it still needs to run() for events. On thinking of it, I think Silent-per-buffer flags are better.
Re: [linux-audio-dev] XAP spec PTAF comments [merge]
Let's just say that all ranges are suggestions, and if it matters,
it is the plugin's problem. If we later find this to be a big
problem, we'll deal with it. Fair?
Yeah. Works for LADSPA, so it can't be *that* bad.
Unless anyone objects with good arguments, I'm putting it in my notes as
such.
Right, but you have to put the flag somewhere. If there's a nice place
for it,
We can ver easily turn a XAP_sample *buf into a XAP_buffer { flags, buf }
struct.
This was more or less what I originally proposed. If a plugin can
indicate that it will not do anything unless more (non-zero) signal
turns up, it can be virtually removed from the tree. Except it
still needs to run() for events.
Yeah, you're right... Effects *generally* don't start making sound
just becaues you change some parameter, though - but that's the only
way this could work at all.
You need an explicit run without processing audio mode for this.
Except that they MIGHT audibly respond to a control. Unless the host knows
EVERY event sent, we have to run it as normal.
On thinking of it, I think Silent-per-buffer flags are better.
I still agree with myself, which is rare after three days in this
discussion. :)
I think we have to think about the implications. Let's look att all
combinations for starters:
1) Silent buffers; host: NO, plugin: YES
This will not work, since a plugin with
silence support may leave garbage in
silent output buffers. The host must
If we make a small adjustment and say that silent buffers are zeroed (not
really THAT costly), then this is no matter at all.
Or we can just say that only the host can mark a buffer as silent. If a
plugin wants to generate silence, but the output buffer is not silent, it
better do it itself.
3) Silent buffers; host: YES, plugin: YES
No problem. Whenever a plugin without
silence support is to be called, the
host will check and clear any silent
buffers on the plugin's inputs. The
host will also reset the silent
flags of all outputs from the plugins,
since the plugin will always generate
valid output, but not touch the flags.
We can also make a very simple non-optional rule that if you generate data
for an output buffer, you must clear it's silent flag. This eliminates the
need for a plugin flag indicating silence support.
Now, there is a problem here: If you have a chain of plugins, and some
of them don't support silence, these will screw things up for the
silence aware plugins. However, if we apply silence detectors on the
outputs of plugins w/o silence support whenever they're sending to
plugins *with* silence support, things will work fine.
Yeah. Or users can beat developers of dumb plugins for wasting CPU.
And of course, regardless of how complicated or simple this is, it has
to be sufficiently motivated.
One thing I haven't really considered before (in the DAW context), is
that any CPU time you save in the DSP thread reduces the risk of
drop-outs in a firm or soft real time system, and maybe more
importantly (to people with real operating systems ;-), it is extra
CPU power for disk butlers and other high latency background
processes.
In my mind this was the WHOLE reason :). I might build up a very
complicated net of plugins for my track. If I tried to run all those
plugins for every process-cycle, it would never finish in time. But the
reality is that at any one time, my tracks are using maybe 35% of the whole
net. Usually less. An optimization that allows a reverb to return almost
immediately helps me to ensure I meet the deadline. I hate clicks and
drop-outs.
For live performance with XAP plugins, it is a big win.
Re: [linux-audio-dev] PTAF link and comments
I'm questioning whether having a simpler query based system may be easier. I don't like the idea that you have to instantiate to query, though. Many plug-in standards require instanciation before fetching properties. PTAF must be able to make good wrappers for existing plug-ins, industry requires it. Yeah. Here is an open question: Should the wrapped plugin be a control at all? David mentioned once the difference between 'Controls' and 'Parameters'. I don't like having different control types that due basically the same thing. BUT (you knew that was coming): the wrapped plugin is kind of a parameter, more than a control. Changing the parameter can change the ENTIRE metadata of the plugin. Maybe we should formalize that? Anyway I would like to minimize the number of functions. Functions are handy when the calling conventions of both parts are compatible. If the language you use doesn't support this convention natively, all functions have to be wrapped, which is a real pain. If you have to wrap into different languages, you have to wrap enums, too. There is no way to reduce the total number of things wrapped. More, there are still issues with existing plug-ins, reporting wrongly if they support some opcode or not (talk to this issue to Plogue people :). Bugs are bugs, whether they are a NULL pointer or a false-positive. How about defining buffer alignment as what works good for whatever extensions that are available on this hardware...? Good, but it requires the host to be updated when new hardware is released. We can add a host property indicating the current alignment so the plug-in can check it before continuing. I've thought more about it, and the ONLY place I can see buffer alignment coming into the API is that a plugin may request a minimum alignment, and that REALLY seems almost useless. It should perhaps be an option for the user to set in the host, but not part of the plugin API. The plugin can detect the alignment of a buffer by examining the buffer pointer. NO further mention of it is even needed. you'll get a lot of arguments about that on this list - linux people tend to have a 486 or pentium stashed somewhere. :) Professional musicians and studios have recent hardware, at By necessity, not choice. Fatter OS and software requirements drive that. I don't want to make that part of the XAP requirements, if possible. Sometimes we spend too much time prematurely optimizing here. I try to catch that, when I can, though I can be guilty of it, too. Right, but MIDI is integers, and the range defines the resolution. With floats, why have 2.0 if you can have 1.0...? To make 1.0 the middle, default position. ick - if there is a balanced (or even unbalanced) spectrum of values, center it at 0, please :) No, it makes sense for true bipolar data, but here 0 or close to 0 values have their meaning for parameters like velocity. It's not exactly like the volume. ok, so make it 0 to 1.0 with 0.5 the middle - 0-2 is just ick... ;) The spec should not dictate ABI, either. The ABI is an articat of the platform. If my platform uses 32 registers to pass C function arguments, it is already binary imcompatible with your PC :) The only way to guarantee real portability through platforms and programming languages is to describe the API at the byte level. This include calling convention. IMHO We can assume that every target system has a stack, and can pass parameters on it. This is baloney, IMHO. If you want to make plugins that are binary compatible ACROSS PLATFORMS, then this matters. Within a platform, ABI does not change (or, it shouldn't - don't use C++ as an example :) Assume the spec dictates stack-based arguments for functions. Now assume I have a system (it IS happening) where the ABI dictates that up to 128 arguments are stored in registers for functions. If I want to build a XAP host and plugins on this platform I need to specifically add code to them to violate the platform native conventions. The only thing that needs to be byte-level specified is fields whose width matters (integers, flags, etc) and communication protocols. I sure as hell am not dictating that a pointer is 4 or 8 bytes, or that function calls must be NEAR jumps on x86 or any other such thing. Until we have fully-cross platform plugins, we don't need this. At all. I don't like having to call normalize functions for every translation, though. Can the translation overhead be minimized? It's not a big overhead if done efficiently. VST works this way for years, and people don't complain about this side at all. Host just needs to store and pass normalized parameter, so overhead is not here. It makes even things way simpler because data is alawys [0;1]/float, which wouldn't be the case with natural or multi-type parameter handling. I'm still on the fence about this. (sorry for the latentcy - real work this week :) Tim
Re: [linux-audio-dev] PTAF link and comments
Functions are handy when the calling conventions of both parts are compatible. If the language you use doesn't support this convention natively, all functions have to be wrapped, which is a real pain. Really? I don't think it is such a pain. I'd rather penalize the wrapping systems than the native systems. We can add a host property indicating the current alignment so the plug-in can check it before continuing. Very good idea. There *are* platforms where a plugin could crash the host if they ignore this. how about we encode it as setting all the low order bits of the buffer pointer to 0 up to the alignment. The first 1-bit dictates the alignment. :) Yes, but given my experience with customer support, unsafty displeasure is one or two orders of magnitude above efficency pleasure. Very good point! If it *crashes*, who cares if it's slightly faster? At least they won't have to wait as long for it to crash.. Natural values would be needed only for parameter connection between plug-ins, if user chooses to connect natural values. There will be conversion work to do *somewhere* no matter what. However, I don't like the idea of making all controls have hard ranges. It restricts the users in ways not necessarily intended by plugin authors, since there's no way to set controls to values no, it restricts users in ways EXACTLY intended by the authors. But then, I am the lone advocate of dumping (or mostly dumping) soft-ranges altogether :) Yeah, that's the approach I have in mind. Chained fixed size blocks or something... It's not too much fun working with, but we *are* dealing with real time here; not word processing. People wanting to write real time software will simply have to accept that it's a different world, since there's no way we can changes the laws of nature. That will probably be just fine - raw blocks do need some special magic. The only way to guarantee real portability through platforms and programming languages is to describe the API at the byte level. This include calling convention. IMHO We can assume that every target system has a stack, and can pass parameters on it. Good point. I think we can count on standard C calling conventions to work and be supported by all languages on every platform. No big deal Of course, a language that cannot interface with the event struct would be a problem. Requirements: Pointers, 32 bit integers, 32 bit floats and 64 bit floats. (We *could* make all integers 64 bit on 64 bit CPUs, but it seems insane and pointless to me. 64 bit machines don't have infinite memory bandwidth...) If we want to interface XAP/PTAF to some other language than that which the API is defined in, we need wrappers. Period. For most languages you CAN'T change calling conventions. Specifying this stuff in an API is insane. Tim
Re: [linux-audio-dev] PTAF link and comments
[ arguing get/set_extra_state()...] Oh wait, there's one more difference. If we just assume that this is data that the plugin wants to store whenever you save a project, we have major issue: A project will *change* in non-obvious ways if you repeatedly play and save, without explicitly editing anything. That sounds very scary to me... urr, yeah. That is a good point. I'm willing to drop this one for now. Let's go about our business and see if it ever is needed. at which point we'll know a lot more about the problem. My original thought was that we couls use it as a way to save time when reloading a plugin. Stuff like wave-table data that is calculated from a waveform once. We can always recalculate it, I guess. As an example, if you have a compressor that can adjust to how you sing and handle a mike, just hook it up and sing some, to program it. Then grab the state output data and save it in your preset, as the value for the corresponding input. Whenever you load that preset, the plugin will behave exactly like you trained it to. (Or rather, the way it *thinks* you want it to. ;-) In short, we're talking about DSP plugins that are also their own parameter editors, using live input in non-obvious ways to do the editing. Sounds like a *very* interesting concept to me, and I definitely think we should try to get the supporting interfaces right. This is vaguely interesting - dunno if there is a real need for it, or if existing interfaces need mods at all. Flip on the LEARN control, do your stuff. When you flip off the LEARN control a raw-data output is updated. We don't even need to use a hint for LEARN - it is totally plugin unique.
Re: [linux-audio-dev] PTAF link and comments
BUT (you knew that was coming): the wrapped plugin is kind of a parameter, more than a control. Changing the parameter can change the ENTIRE metadata of the plugin. Maybe we should formalize that? We could hint the Control as will cause metadata changes!, but who cares, really? Just for starters, if it's done that way, hosts have to snoop any connections to such controls, or Really Bad Things will happen. Which is what I originally was thinking. How do presets work for wrappers? We need to make sure that these 'gestalting' controls always get loaded first. Doesn't that violate some rule we tried to establish about order not mattering? Are there other repurcussions? The spec should not dictate ABI, either. The ABI is an articat of the platform. If my platform uses 32 registers to pass C function arguments, it is already binary imcompatible with your PC :) Well, all we really need is to pick the most widely supported calling conventions for each platform. Is there *any* platform that has relevant languages that do not support the native variant of C calling conventions...? (At least, most compilers on Un*x and Win32 seem to support at least two or three variants.) No, we need to go with whatever the native conventions are. I think the original poin in the spec was that C++ code would use PTAF as extern C. That is fine, you just need to put it in the header. Don't burden DSP programmers with things like ABI. Tim
[linux-audio-dev] XAP stuff still pending
Items we haven't agreed to a solution on (or that I missed the solution for :) 1) Do plugins load the default value for all their controls or do we have to send an event for data they already know? 2) Do we need a run_adding() form of run()? If so what are the semanitcs and how to specify the run_adding_gain?
Re: [linux-audio-dev] PTAF link and comments
However, I don't like the idea of making all controls have hard ranges. It restricts the users in ways not necessarily intended by plugin authors, since there's no way to set controls to values no, it restricts users in ways EXACTLY intended by the authors. Unless the author just intended to hint a useful range for a control that doesn't have obvious limits. There's no way to do that if ranges are hard. That _CAN_ be solved, but I feel outnumbered in my position. ;) I'll bet a pint that a lot of plugins will have internally clamped hardlimits. Specifying this stuff in an API is insane. Except on platforms that have multiple commonly used calling conventions. (Like Win32.) If you say use standard C calling conventions, you're fine, but if you say nothing, you're asking for trouble. OK, I'm fine with that. I just don't want to see us explaining what they are. :)
Re: [linux-audio-dev] PTAF link and comments
Flip on the LEARN control, do your stuff. When you flip off the LEARN control a raw-data output is updated. We don't even need to use a hint for LEARN - it is totally plugin unique. Right. As long as there is suitable control datatypes, no additional support is needed, really. It works without explicit support. That said, it might be nice to allow plugins to somehow hint that an output generates data that you may write back to a specified input of the same type. This would allow hosts to be smart about this, rather than just showing these controls as normal, totally unrelated inputs Using an output control for this is actually wrong, on another thought. You would NEVER save a VOICE output control or anything else output with a preset. Output goes to some other place. Just because we CAN get data out of an output control, doesn't make it consistent with the semantics of an output control. We'd need Yet Another Flag that says a control is an output that is meant JUST for preset data. Ick?
Re: [linux-audio-dev] PTAF link and comments
no, it restricts users in ways EXACTLY intended by the authors. Unless the author just intended to hint a useful range for a control that doesn't have obvious limits. There's no way to do that if ranges are hard. That _CAN_ be solved, How? All ideas are of interest... :-) A seperate hint that ranges are just a suggestion. In fact we're close to this NOW. I just bet that ALOT of plugins will use hardlimits at their hinted ranges. but I feel outnumbered in my position. ;) I'll bet a pint that a lot of plugins will have internally clamped hardlimits. Sure, but they don't have to be clamped to the hinted ranges. Then let me restate - I bet that a LOT of plugins will hardlimit to their controls ranges. Soft-limits will be done by people who are used to not having a limit, but if we succeed and get market capture, no one will really use softlimits that often. Just a hunch :) Tim
Re: [linux-audio-dev] XAP stuff still pending
2) Do we need a run_adding() form of run()? Yes - but we should only encourage it for small/fast plugins that are ... Is this really worth messing with? This is starting to sound like silence handling with plugin granularity... ... Well, there's another issue. For this to be truly useful, the gain would have to be a ramped control, and there would have to be one for each audio output. Simpler versions *could* be useful, but I have a feeling that it would only cover some special cases, rather than your average automated mixer session. I've never seen such a fast about-face! :) So it is still undecided, then. Tim
Re: [linux-audio-dev] XAP spec PTAF comments [merge]
On Thursday 06 February 2003 07.50, Tim Hockin wrote: [...Paul's k5000...] The top-of-chain plugin (synth) will tell you when it is silent, of course! I think it can be a massive, coarse-grain optimization, if we can make it work. I think it'll be rather useless if done on the plugin level, with synths and other devices with many audio ports. As soon as we start talking about multitimbral/multichannel synths without internal FX, we're talking about *trees*; not chains. The reason I have it is that games and other multimedia stuff should be able to just set up all FX processing needed for the whole thing and then not worry about it. You can have the full FX net for every song in the game running at all times virtually without cost. The plugins won't start burning CPU until you actually send some sound their way, and they'll stop burning CPU as soon as their tails are out. Whether or not this is useful in your average studio is another matter, but it does *work*. Yes - based on my experiences of looking at (admittedly mainstreamish) music done in modern Windows sequencers, the majority of the time, a significant portion of the processing tree is not in use. Now, based on recent arguments, I am rethinking my otiginal idea. I had originally put this at the plugin granularity, then moved it to per-channel. This may be Good Enough, but not The Best. What I learned is that you can NEVER not call the run() method on a processing pass. Event outputs, etc. mandate that you call run(). Now, if the plugin knows it's input is silent, it can heavily optimize the run() if it does not have anything to do. I'm starting to lean more towards David's idea which is that a buffer also has at least one flag - SILENT. All buffers start out silent (though they should be zeroed, I think). If a plugin can optimize in the face of silent buffers, it should. We should heavily recommend this, and code all examples to do this. This gives plugins a lot of granularity, and a lot of responsibility. However, it is easy to do, and doesn't require the host to participate at all. Tim
Re: denormal floats (was Re: [linux-audio-dev] XAP spec - early scribbles)
On Thursday 06 February 2003 16.28, Steve Harris wrote: [...] #define FLUSH_TO_ZERO(fv) (((*(unsigned int*)(fv))0x7f80)==0)?0.0f:(fv) I think it came from the music-dsp list. There's a conditional in there, though. Another method is to add noise or some other signal (beep at Nyqvist) with an amplitude a few hundred dB or more below the 0 dB level of audio data. Which is fine, unless you have a LP filter in your chain. Maybe a -200dB sine at 1Hz and Nyquist? But then a BP filter screws you. Someone once suggested a slight DC offset, though I can't see how that would solve things like a reverb, unless they preserve it and shift their 0.
Re: denormal floats (was Re: [linux-audio-dev] XAP spec - early scribbles)
Maybe a -200dB sine at 1Hz and Nyquist? But then a BP filter screws you. White noise is pretty good... A very simple Denormal-Zapper plugin which injects white-noise at -200dB (or lower) can be inerted anywhere in the chain. A Very Useful Plugin. Tim
Re: [linux-audio-dev] newest audio server for Linux (yep, yet another)
That is a great feature of C++ but PortAudio is using 'C' not C++. So I
think our only choices are #define and enum. PortAudio uses both.
you can still use const variables - gcc with optimizations treats them like
defines, but with type-safety.
Are enums better than #defines?? I am always trying to improve my 'C' chops
so I am open to suggestions.
If you can enumerate the values, you should, IMHO. Of course, there are
times to break this, but in general YES. An enum is a real type, and can be
used as such.
enum foo_cmd {
FOO_A,
FOO_B,
FOO_C,
};
int doo_foo_cmd(enum foo_cmd cmd);
Tim
Re: [linux-audio-dev] PTAF link and comments
Or do we just normalize 'generic' outputs? Well, what is a generic output, really? Looks like just another unit + range combo to me, and all it means is it's *supposed* to map to all sorts of inputs. Problem is that it's still not obvious how do actually get it right. A generic output is a plugin which wants to emit control data, but it doesn't know what it is connected to - might be pitchbend, might be oscillator shape, might be pan. Generic outputs should emit normalized data 0.0-1.0. To connect it to anything useful, you need to scale it by the targets true range. It seems more obvious to me, though, that controls DO need to do bounds checking for their inputs, or the host needs to do snoop-and-fixup for every control. So the way I see saving the state of a plugin: For each control save snooped control data to output (maybe XML) endfor if (plug-get_extra_state) d = plug-get_extra_state() save d as if it were a raw control endif Well, that eliminates the need for the in/out pair, which *is* a special case after all. right, we only need to 'read' data we didn't write. However, how do you actually transfer the raw data through that call? It's just not about a function call, but also about the data transferred. We'll need an RT safe solution for the controls. What to do here? Just assume that it's not RT safe? (Which means you can't save states without taking plugins out of the net, or requiring that they're thread safe WRT this call...) I'd assume this is NOT RT safe. Don't save a preset while your track is running :) Tim
