> Hmm. sfront generates .c files, but the manual only discusses
> compiling them to executables. Wonder how they like being compiled
> into shared libs....
One problem will be that, at present, even active drivers result in
the sa.c file including a main(). However, for active drivers, all
the main() does is run a few initialization functions, then call
the audio driver's asys_main() function, which then maintains control
and runs the simulation itself (usually, simply by sleeping and letting
the callbacks get called to run the audio system via calls to asys_orun()
or asys_iorun()). Upon receipt of control back from asys_main(), a few
clean-up functions are run and then exit(0) happens.
I assumed eventually, some application would have trouble with main()
existing for active drivers, and the result would be some sort of
sfront flag which acts to rename main() to a callable function -- it
seemed better to wait until that application happens, to get a sense
of the best sort of "alternative personality" for sfront to create
to a normal main().
> > I would have to read up on LADSPA to really say ...
> If you have the time, I'd encourage that.
OK, I'll add it to that ever-growing list of things to do :-).
--jl
-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------
