Subject: Re: [linux-audio-dev] priority inversion & inheritance
From: Martijn Sipkema (msipkema_AT_sipkema-digital.com)
Date: Thu Jul 11 2002 - 15:53:20 EEST
so, to summarize:
nframes != constant
- (better) support for various (stupid) hardware.
nframes == constant:
1- Easier porting of read/write applications.
2- Optimized latency of FFT; FFT done on period size. This would
also require a power of 2 sized period.
So not having nframes constant gives better support for some
(stupid) hardware. Drawback number 1 is not really a problem I think.
The applications will have to be ported to a callback based API
anyway for optimal performance. There exist solutions that enable
these applications to be ported without too much effort, but with
larger latency.
Only in the case that the (constant) period size is a power of 2 will
it be possible to have one period less FFT latency than the general case.
This is an optimization. If the applicaiton supports the case where
nframes != constant and not a power of 2 in size, then it could possibly
optimize FFT latency in the case that nframes happened to be constant
and ^2 sized. If JACK supported a call to request whether
nframes == constant, then this would be possible.
ASIO is not that good an example I think. ASIO also assumes double
buffering, which not all hardware might use. In the case of ASIO this
requires extra copying.
It is not my decision to make, and there is something to be said for
either, but I\'d choose to stick with a non-constant nframes and possibly
add the interface for requesting nframes constness.
--martijn
Powered by ASHosting
This archive was generated by hypermail 2b28 : Thu Jul 11 2002 - 16:05:25 EEST