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
