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

[Paul Davis]

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