> > 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
