[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sound header



At 12:21 31/03/99 -0500, you wrote:
>Since I have not recieved any objections to the current plans, I will be
>releasing a header file soon.  I have already been workin on mixer
>functions (such as volume et cetera. )  I also have a couple people who
>have contacted me about helping with sound, working on some things.

 I agree with Nicholas, in that a top-down approach is much better, and
it will also allow us to have some working demos faster. If you really
want to (re-)write low level drivers, write them later after we have an
API to call them from that already works with OSS/ALSA.

>7) Provide functions to play MOD (XM,MOD, etc.) files. 2.0
>  Can be done very much similarly to the MIDI files, except  to sound
decent, it almost requires
>wavetable-synthesis. However is can be done without it.

 Playing MOD, XM, S3M etc _IS_ wavetable synthesis! (-:

>9) Provide mixer functionality to allow for 3D sound, such as distance and
location panning
>(such as to the left or right.) 2.0
>  This can get kind of complicated, but for the people who want to help
out on it, I know of a
>place that shows you how to do it.  Although, when I've done it, I've
implemented it rather
>differently.

 We need an API so the game can define where in 3d space each active sound
source is relative
to the listener, and it's relative velocity. Maybe that's what you meant,
I'm not sure. 'Mixer'
is a word that can mean several things. It can mean the volume control for
the whole system, or
the part that mixes multiple audio streams into a single stereo stream to
go to the sound card,
or the part that encodes sound into 3d space, or ......

>10) Surround sound functionality. 2.0
>  This I've never implemented, but since you need a card which supports
more than two speakers
>to use it, most hardware manufacturer's docs will tell you how to do it on
their card...plus ALSA
>I'm sure does or will support it. ( I have not actually looked.)

 Depends on your definition - you only need a standard stereo soundcard to
output dolby encoded
surround sound, which is what I've done. It can be done in real time fairly
easily. If the cards
offer >2 physical speaker outputs, then we can also use them, but that's
hardware dependant.
Either way, the API should be the same - the game defines 'where' the
sounds are, and penguinsound
locates them using whatever system is available.
 (some player<>game<>API interaction is needed, eg for the user to enable
or disable the various
types of sound positioning)

>13) Provide functions to record. 1.0
> Very useful!  Most programmers will use this, because a new "fad" in
gaming is
>real-time voice communications.

 Good point, I hadn't thought of that. It would make penguinsound more
interesting if it had
this built-in.

>14) Provide functions to compress sound so that  it may be sent across the
network/internet in
>smaller form,to make more efficient use of bandwidth. 2.0
>  Any number of compression algorithms could be used...several should be
due tot he fact that
>some will use the CPU more than others.  This would be useful to users who
have higher or lower
>speed CPUs and higher or lower speed access to the network.

 Yep. This may also require some interfacing to the network parts of
penguinplay. It would be
great if we could make a multi-player game demo which incorperated realtime
voice as well.

btw, I can contribute to the dolby & 3d sound stuff, as well as the audio
codec for the
voice communication stuff, as well as generic sound codec handling.

Balance += 0.02