Subject: sfront and LADSPA, was Re: [linux-audio-dev] Lots about latency and disk i/o and JACK...
On Wed, Oct 03, 2001 at 07:14:47PM -0700, John Lazzaro wrote:
I think that should be adequate for many purposes.
Well, given the above, it's not strictly necessary.
Interesting. This sounds workable.
> > Any other obstacles?
If you have the time, I'd encourage that. Probably the ladspa.h header
http://www.ladspa.org/ladspa_sdk/ladspa.h.txt
One interesting note from the header:
Hmm. sfront generates .c files, but the manual only discusses
[pw_AT_roaddog sfront]$ cd examples/perc
[pw_AT_roaddog perc]$ gcc -c -o perc.o perc.c
Cool.
> Also, you have to try really hard, but it is possible to write SAOL
I don't think this will be a large problem in practice.
This archive was generated by hypermail 2b28
: Thu Oct 04 2001 - 20:54:32 EEST
From: Paul Winkler (slinkp23_AT_yahoo.com)
Date: Thu Oct 04 2001 - 20:56:41 EEST
> 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.
> > 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
>
> I would have to read up on LADSPA to really say ...
includes everything you need to know, it's extensively commented.
"Plugins will reside in shared object files suitable for dynamic
linking by dlopen() and family. The file will provide a number of
`plugin types' that can be used to instantiate actual plugins
(sometimes known as `plugin instances') that can be connected
together to perform tasks."
compiling them to executables. Wonder how they like being compiled
into shared libs....
[pw_AT_roaddog perc]$ sfront -o perc.c -orc perc.saol -sco perc.sasl
sfront, a SAOL to C translator. Version 0.76 09/22/01.
Run sfront with -license option for Copyright/License info.
[pw_AT_roaddog perc]$ ld -o perc.so perc.o -shared
[pw_AT_roaddog perc]$ file perc.so
perc.so: ELF 32-bit LSB shared object, Intel 80386, version 1, not stripped
> programs that call malloc() in the asys_orun() call -- but avoid a
> few constructs and you should be OK ...
--
................ paul winkler ................
custom calendars: http://www.calendargalaxy.com
A member of ARMS: http://www.reacharms.com
home page: http://www.slinkp.com