Subject: Re: [linux-audio-dev] we should use gtk objects for our plugins
From: David Olofson (audiality_AT_swipnet.se)
Date: pe elo 27 1999 - 20:27:05 EDT
On Fri, 27 Aug 1999, est_AT_hyperreal.org wrote:
> glib, OTOH, is a completely separate question and I'd still recommend
> going with it. It provides great datatype definitions and has seen
> heavy use on many platforms. Coding things from scratch has a lot
> less appeal for me than it did when I was younger. It's always harder
> than it seems and there are always more bugs than expected. :)
Hmm... glib is BIG. And it contains LOTS of code that doesn't have anything at
all to do with what we're doing, and isn't even possible to implement in a
real time safe way, even in user space.
As far as I can see, there isn't really that much that's truly useful, except
for in GUI code. (And GUI code still doesn't belong in the same file as the
processing code... :-)
Using the standard glib means that it gets very easy to use stuff that breaks
user space real time, and prevents plug-ins from even loading under Audiality.
For example, some functions in some libraries (most likely applies to glib as
well) will result in system calls which cannot be resolved in a sane way in
kernel space. And you certainly don't want DSP code to printf() and that kind
of things anyway...
What I'm saying is, glib is a lot of real time unsafe code that we have no
control over. Grab the useful stuff and change anything that isn't real time
safe. The ultimate test of the "rt-glib" specification will be the RTLinux port.
//David
·A·U·D·I·A·L·I·T·Y· P r o f e s s i o n a l L i n u x A u d i o
- - ------------------------------------------------------------- - -
·Rock Solid David Olofson:
·Low Latency www.angelfire.com/or/audiality ·Audio Hacker
·Plug-Ins audiality_AT_swipnet.se ·Linux Advocate
·Open Source ·Singer/Composer
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:25:53 EST