16 Jun
2009
16 Jun
'09
2:08 a.m.
On Mon, Jun 15, 2009 at 5:40 PM, Fons Adriaensen<fons(a)kokkinizita.net> wrote:
Typical audio hardware will interrupt whenever it has
N
samples available for reading and writing, where in many
cases N will be a power of 2.
neither USB nor firewire devices work this way, and are instead based
on clocks that are unrelated to audio sample rate. i believe that you
know this :)
The conclusion is that resampling at the sound card
API, if
this is in any way 'period based' breaks things,
this is part (a big part) of the reason why CoreAudio's HAL API is not
based on hardware interrupts at all. it adds a small amount of latency
(and i continue to suspect that apple is playing conservative with
their "safety buffer"). the system is elegant (its basically a DLL
with a small offset built in), allows resampling and many other cool
things. PulseAudio is also using a similar model layered "above" ALSA.
And there is no good reason for ever doing that.
Applications like soft synths should be capable of generating
their output at the sample rate imposed by the hardware. The
*only* cases were resampling is really needed is when dealing
with *stored* data (either being read or written). But in that
caes there will be buffering between the storage and the RT
audio code, and *that* is the right place to apply resampling,
it costs nothing (in terms of timing) if done there.
infrastructure like gstreamer has done this for years. problem is (a)
the architecture is baroque (b) their resampler is poor quality and an
unbelievable CPU hog.