At 05:33 PM 10/30/99 , Eric Scheirer wrote:
>For those who haven't heard, Creative has decided to open-source
>the Linux drivers for its SB-Live card. This is interesting news
>for the SAOL developer, because the SB-Live has a programmable
>DSP on it. I don't know the exact specs, but I do know that although
>it's not completely general-purpose (it doesn't have branching
>instructions, for example), the Emu 10K1 chip has a variety of
>features that would be useful to accelerate SAOL implementations.
>
>So two things:
>
> 1. Can any of the Creative/Emu people lurking on this list tell
> us whether the 10K1 spec is likely to be included as part of
> the open-source package? Will there be enough information
> that the non-registered developer will be able to program the
> 10K1 and send code to the chip?
This is a key point. It is difficult to answer to 2. without a clear
understanding of this. So far if one wanted a DSP the choice has
been among Motorola, AD, TI etc...
> 2. I'd like to see some discussion and comments from people who
> know more about DSP compilers about the prospects of making an
> SB-Live accelerated version of sfront and/or SAINT, when
> Giorgio releases it. 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? Are there good theoretical models for doing the
> compiler optimizations for programmable but not general-purpose
> architectures?
Difficult, as I said. I move from John's reply, many things are already there.
Impossible to think to communication through PCI bus. True. Distributed
calculation needs chips and systems made for that purpose. Spatialize() ?
I know well 3-d algorithms, probably feasible by stereo panning and good
quality processing for late reverberation, probably impossible a *true* 3-d
(note that stereo panning is 2-d :-)) by HRTFs and so on: a 5+1 uses to
saurate a DSP5630x. Anyway I won't move that direction, because either
the DSP is saturated or is empty. Naive compilers for end processing ? The
same problem, perhaps with just a better granularity.
IMO a DSP like the EMU (but I repeat, I don't know it in details) is not
designed
to support things like Object types 3 and 4. If I should do something for
that and
for SA I'd prefer, right now, to consider Object types 1 and 2. Nobody active
in this list seems to care about them but, always imo, this is the direction
the market will take in immediate future. Algorithmically easy, good sound
quality, support for the huge bundle available right now (i.e. MIDI). Note that
a chip with no branching is designed for "easy" and well-known stuff,
we made the same for Studer's PUMA. No general purpose programming,
normally. Only well-known "classes" of algorithms.
My best regards,
Giorgio
__________________________________________________________________
Giorgio ZOIA
Integrated Systems Laboratory - DE/LSI - EPFL
CH-1015 Lausanne - SWITZERLAND
Phone: + 41 21 693 69 79 E-mail: Giorgio.Zoia@epfl.ch
Fax: +41 21 693 46 63
__________________________________________________________________
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:15:43 EDT