Re: sound header

[The Greene Family <topcoder@mindspring.com>]

At 12:29 PM 4/1/99 +1000, you wrote:
> 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.

For the final time, I said I agree! :-) OSS/ALSA comes first, and later
down the road, say version 2.0, 3.0 heck later on even, low level drivers
ought to be implemented.  I really do think we could do a more efficient
job of it.  But, getting a mature API, is more of a priority...my first doc
said OSS and ALSA was not hte priority and, after research and reading
comments, I changed it.


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

You'd be surprised, I've seen some alternative implementations...very
interesting!  It's been a long time though, mind you I was writing all that
stuff on about umm well no sleep, so my thought processes were not going
very well.

> 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 ......

By mixer, I meant the code that takes the sounds and mixes them together.
:)  I meant, code that takes the sound's point of origin in 3D space,
factors in everything, then mixes it accoordingly.

> 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)

My definition of surround sound requires >2 speakers, sorry for confusion.
To me "surround sound" with only 2 speakers is just vanilla 3d positional
audio...it's not surrounding you is it? ;-)

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

Thank you.  I thought of it, because a game design i've been working on for
quite sometime requires it, and all the APIs I'd really looked at for DOS
et cetera, never really implemented it.

> 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.

Hey, I take help where it can be taken from.  Right now, I'm trying to
learn about the OSS stuff, I'm going to try to compile some stuff later and
test it out that I've already done.  I really wish I was back in the DOS
days, the docs made so much more sense when they said put this value in
that port. ;-)  OSS has ioctl calls, and I've only use ioctl once many many
moons ago for CD Audio (it was interesting...) so it's a weird thing to learn.

Derek