On Wed, Jun 15, 2005 at 08:22:17AM -0400, Paul Davis wrote:
i don't think thats entirely fair. when jaroslav
started ALSA i think he
was intent on a set of ideas that looked like the best choices at the
time. the goal was to improve lots of issues with OSS, including its
requirement for all "functionality" to reside in the kernel.
And that was an excellent step.
i don't think that, even if we had had fons on
board at that time, that
the idea of using a DLL rather than interrupts to truly drive the whole
system would have occured to anyone in 1996-2000.
Probably not, but I remember we (at Alcatel) used them in soft DSP
systems at that time. But the DLL isn't really 'driving' anything,
it just provides more accurate timing *information* than what you can
get without it in the presence of interrupt and scheduling latencies.
Most audio apps don't need this info.
as for callbacks, this
would have been dismissed by almost all commentators because it would
require every single existing audio app to be rewritten. it would have
been a great idea, yes, but it would never have been accepted. too many
developers would have whined to LKML that it was unacceptable to remove
the open/read/write/close model from the official linux audio API.
There is nothing really wrong with that model per se, and you can easily
build a callback system on top of it, as jackd does. Basically all it
requires is a user-space thread to call back from.
I think the real reason why such a callback (to user space) system was
probably impossible at the time is that it can't be done without user
space threading, or at least some form of co-routines. How many people
were prepared to write multi-threaded apps in 1995, if it could be done
at all ? For most of us in this group it seems like a natural thing to
do, but I'm sure that even today the whole concept of multithreading and
message or event driven programming remains something quite unfamiliar
to the majority of programmers,
--
FA