On Mon, Jun 15, 2009 at 5:40 PM, Fons Adriaensen<fons@email-addr-hidden> 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.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
Received on Tue Jun 16 08:15:02 2009
This archive was generated by hypermail 2.1.8 : Tue Jun 16 2009 - 08:15:02 EEST