> Is this understanding correct? If so, is there any way to modify SAOL
> so that a compiled SAOL program can be told its K-rate at runtime?
The short answer is, audio drivers, both passive (you define a function
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
-- queue the incoming data to the next k-cycle
-- choose a krate for your SAOL program sufficiently large so that
the latency effect of this queing is negligble (i.e. oversample).
But no, you can't actually "choose your K-rate at runtime", technically
speaking.
Note that audio drivers are free to choose their own audio blocksize,
because sfront doesn't do CSound-style blocking computation -- it
computes audio sample-by-sample, and uses other means to get fast
performance.
> There's also the matter of naming the ports ... LADSPA ports generally
> have reasonably intelligible names; how could sfront be told what the
> names are and which port they go with?
You could use run-time options for the sa.c file executable, that's how
the ALSA sequencer control driver gets configured. See:
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
the -cin, -aout, and -ain options.
> Any other obstacles?
I would have to read up on LADSPA to really say -- one thing to note
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 ...
Also, you have to try really hard, but it is possible to write SAOL
programs that call malloc() in the asys_orun() call -- but avoid a
few constructs and you should be OK ...
--jl