Subject: Re: [linux-audio-dev] Lots about latency and disk i/o and JACK...
> Is this understanding correct? If so, is there any way to modify SAOL
The short answer is, audio drivers, both passive (you define a function
-- queue the incoming data to the next k-cycle
But no, you can't actually "choose your K-rate at runtime", technically
Note that audio drivers are free to choose their own audio blocksize,
> There's also the matter of naming the ports ... LADSPA ports generally
You could use run-time options for the sa.c file executable, that's how
http://www.cs.berkeley.edu/~lazzaro/sa/sfman/devel/cdriver/data/index.html#cmdline
Or, you could do it at sfront compile-time, by having parameters for
> Any other obstacles?
I would have to read up on LADSPA to really say -- one thing to note
Also, you have to try really hard, but it is possible to write SAOL
--jl
This archive was generated by hypermail 2b28
: Thu Oct 04 2001 - 05:12:27 EEST
From: John Lazzaro (lazzaro_AT_CS.Berkeley.EDU)
Date: Thu Oct 04 2001 - 05:14:47 EEST
> so that a compiled SAOL program can be told its K-rate at runtime?
sfront calls as a driver writer) and active (at startup, you tell your
callback system to call a function, and this function calls asys_orun()
or asys_iorun() to compute new samples), let the driver set the blocksize
for delivering audio. For control, SAOL will only process it once per
kcycle, so the right thing to do is
-- choose a krate for your SAOL program sufficiently large so that
the latency effect of this queing is negligble (i.e. oversample).
speaking.
because sfront doesn't do CSound-style blocking computation -- it
computes audio sample-by-sample, and uses other means to get fast
performance.
> have reasonably intelligible names; how could sfront be told what the
> names are and which port they go with?
the ALSA sequencer control driver gets configured. See:
the -cin, -aout, and -ain options.
is that audio drivers are "active" but control drivers are still
"passive" -- you would be defining a call back that fills a queue
that the sfront control driver then checks when its called. But as
I describe above, if you choose your SAOL krate high enough, this
won't make a big latency hit ...
programs that call malloc() in the asys_orun() call -- but avoid a
few constructs and you should be OK ...