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

From: Paul Davis <paul@email-addr-hidden>
Date: Thu Jun 16 2005 - 17:30:29 EEST

> > 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
Received on Thu Jun 16 20:15:08 2005

This archive was generated by hypermail 2.1.8 : Thu Jun 16 2005 - 20:15:09 EEST