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.
true, but i take it you get the way CoreAudio is doing it: it means you
can drive audio processing from a different interrupt source (e.g.
system timer) because you have very accurate idea of the position of the
h/w frame pointer. In CoreAudio, the "callback" is decoupled from any
PCI, USB or ieee1394 interrupt. Tasty.
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.
you can, true, though JACK doesn't. JACK uses poll and mmap (the OSS
driver uses ioctls and select IIRC); expecting regular audio developers
to use poll/mmap on a day to day basis creates very bad reactions :)
--p