What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)

[Alfons Adriaensen]

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