> How hard are the
> practical issues involved in making an implementation where
> part of the code runs on the host and part runs on the sound
> card?
Intuitively, the clearest wins for sfront would be the stuff
at the very end of the signal-processing chain, where the
normative floating-point aspects of MP4-SA loosen up. I.e. :
-- After the summation onto output_bus is complete, sfront
clips the floats at -1.0/1.0 and then does the necessary
conversion requested by the output driver (none for drivers
that request floating point, scaling and float->signed int
conversion for 16-bit 2's complement integer drivers). It
could very well be that offloading the clipping and conversion
to the special output driver for SB-Live equiped Linux machines
gets a few percent improvement in performance. More complex
but still reasonable would be offloading the output_bus
summations (from output() calls on instruments that write to
the output_bus, and outbus(output_bus, ...) calls.
-- Right now, sfront computes spatialize() calls on the main
processor, using a simple spatialization algorithm developed
by Brown and Duda. When used aggresively (like the examples/perc
example in the sfront distribution, that places each drum in
a trap kit in a different location), spatialize() can dominate
computation time. Offloading this to the SB-Live would be easy,
since it comes at the end of the chain and is non-normative.
-- One could imagine writing a set of SAOL effects instruments
(reverb, ect) that are designed to:
-- come at the end of the signal processing chain, right before
the output_bus
-- are written so that they map easily onto whatever processing
engine the SBLive card has
Basically, a naive compiler would just run the SAOL code, but a
knowing compiler would pattern-match to recognize that these are
special SAOL programs, and substitue a hand-crafted library that
runs on the SBLive card. Since these effects would be designed
to come at the end of the chain, moving the computation onto the
card would be easy.
Anything more than these sorts of back-end offloads really
would require the SBLive card to have relatively general-purpose
IEEE-standard floating-point FLOPS available, in a quantity
comparable to the candidate main processor (since the SBLive
card is typically shipped on higher-end PC's, that would be
an Athon or a PIII, as opposed to a K3 or a Celeron). There
will be a big latency cost for any computation that needs to
move data across the PCI bus to the SBLive card and then back
to the main CPU for further processing, so there had better
be a big well of FLOPS there in the card to make it worthwhile,
--jl
P.S. I should add that I'm really happy Creative decided to go
GPL with their SBLive drivers, when I ordered my PC a few months
ago, I ended up ordering the cheaper PCI 128 card instead of
the SBLive card because there wasn't an open-source driver,
depriving Creative of $20 of mostly profit -- the loss on the
margin of 10,000 or 100,000 people a year making that decision
probably reached the point where it outweighed any strategic
advantage to keeping the drivers closed.
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:15:42 EDT