[vorbis] Audio Section - Game Programming Gems 3

Mercier, Dave dmercier at ea.com
Thu Nov 8 11:30:33 PST 2001



Just a couple of points of Vorbis interest from a game developer:

1) There seems to be a lot of emphasis on PC game development in this
thread. 90% of the games we do are on consoles, not PC's, and we are
probably the biggest game developer in the world. So Vorbis on consoles is
what we find most interesting.

2) Compared to MP3 implementations, the current Vorbis implementation takes
gobs of memory up (at least around 500k per decoder instance last time I
checked). MP3 requires maybe only around 50k. In a typical game, we may want
to play 2, 3, or 4 compressed audio streams at the same time. So with Vorbis
we might be hitting 2 megs of memory use, with MP3 we are hitting only 200k.
On consoles, we don't have much memory, so having to use 2 megs is counter
productive to using compression at all (one of the big reasons is to save
RAM).

3) Being able to easily vector out standard lib functions would be a good
thing. Contrary to what's been posted recently, most consoles have
absolutely pathetic inefficient math libraries and the like, which we
actually forbid from being used because the bloat in 100k of code in some
cases just calling something like sin(). We can quite easily hack the Vorbis
code ourselves, but that makes it harder to stay on top of things since we
are creating a branch off the main line code. What I might suggest is making
it all vectored, then providing a function such as
"vorbis_vector_to_standard_lib()". This would fill in the vectors with what
is used now.

Anyway, the main thing for game developers is to get the memory usage down.
I've been told it's possible. But it seems to me you really have to
understand the code to do that. I also wonder if it might slow down the code
a bit if this was done. Most game developers are very busy working on the
games, and don't have time to figure this out. What game developers can be
very good at on the other hand is optimizing parts of the code for specific
systems.

On the other hand, I don't think the memory usage is much of an issue for a
PC game, so that's probably the first area we would consider using Vorbis
in. For example, playing a users Vorbis files for the sound track would be a
cool thing. I'd actually say other than that (playing users Vorbis files), I
don't think getting Vorbis into games really promotes the Vorbis cause that
much anyway - from a game players point of view they could care less how the
audio in the game is played. 

Although I'm bringing this up, I don't think it should be an issue for
anyone until 1.0 is out. Nothing should distract from that. Once 1.0 is out,
I think you will see people jump in and see what they can do to optimize
various parts of the code/algorithms. Once the main line decoder supports
things like SSE for fast operation, I think it will make it all that much
easier for game developers to throw into their game. 

I think the same goes for hardware Vorbis players, etc. Until a final 1.0
product is out, developers who have to commit to hardware will be skittish,
so I wouldn't push them too hard until that point. Yes I know the current
decoders will continue to work, but history has shown that statements like
this don't always hold up, as bugs may creep in that need to break the
format, etc.

Anyway, please forgive me for any ignorant statements as I haven't actually
looked at the code in a long time and there may be inaccurate assumptions
above. Just wanted to give you an idea of the current vibe of one game
developer.

Thanks,
Dave.

-----Original Message-----
From: Tom Hubina [mailto:tomh at 3dgamedev.com]
Sent: Thursday, November 08, 2001 5:10 AM
To: vorbis at xiph.org
Subject: Re: [vorbis] Audio Section - Game Programming Gems 3

At 03:39 AM 11/8/2001, you wrote:
>Scott,
>
>How detailed would this need to be? I think that this probably doesn't need
>to explain the backgrounds of vorbis encoding/decoding.
>In my opinion, the sole notion that a free and open standard for lossy
audio
>(de)compression exists, can rock the foundations of todays in-game music
>playing. Vorbis has not yet caught firm roots in gamedev industry just
>because _almost no one knows it exists_!

Actually, quite a few people in the game industry know it exists. Some are 
waiting for the MP3 dorks to sue you guys while others have already paid 
for MP3 or are using it through DirectMusic / Quicktime. Then you have 
people like myself and Brian who are going to use it now :)

The larger game houses can afford to spend a couple thousand dollars on an 
MP3 license (or just get it by using Miles) because they know no one is 
going to pull the rug out from under them later(like if the MP3 dorks got 
an injunction against all products that used Ogg Vorbis as part of a 
lawsuit .. valid or not). The smaller game companies are watching every 
penny and those are the ones that would be most interested in Ogg Vorbis. 
They're also the ones who are very pressed for time and pre-packaged / 
clean solutions are very interesting to them.

>If an article about vorbis appeared in such a popular book, it would mean a
>lot. Perhaps it doesn't need to go into explaining the vorbis itself much,
>but more into explaining how to use it in a game, what are common
>traps'n'pitfalls when using it in an interactive application that is
>CPU-usage
>sensitive, etc.

An article showing how to stream the data into a DSound buffer efficiently 
using the callback functions and with a minimum of extra junk would be 
useful. Information about CPU load, memory use, and song start latency 
would be important as well.

>Now, I don't have much free time lately, but if no one else feels like
doing
>the article, I'll volunteer because I think that Vorbis deserves it. :o)

I would suggest that you guys build up some binary distributions of the 
playback stuff. In general, I think game developers want a clean solution 
that they can play with right off the bat. In general we're not interested 
in contributing to the code base or spending a couple days getting the 
projects to compile and integrate with our project. It's great to know the 
source is available if we have to port to PS2 or fix a bug, but it really 
isn't a primary concern. In other words, what I'd be looking for is a 
simple package with:

1. Static and dynamic libraries.
2. Header files required for playback.
3. Some simple examples to show playback through a FILE pointer and using 
the call back functions to feed into DSound.
4. Easy to use tools for creating the Ogg files that we can give to our 
music guys.
5. Docs for the API and tools.

Repeat the above for different platforms (MacOS and maybe Linux) for extra 
credit, but Win32 is the primary concern for most game developers.

I would also suggest trying to get feedback from any developer using Ogg 
Vorbis and putting a list of titles that use it up on the web site.

One final suggestion ... remove all use of standard libraries ... get the 
decompression libs to stand on their own without linking to anything else. 
This greatly simplifies their integration into our projects under Win32 
since there's so many options for linking with the standard libraries, and 
everything you link to needs to use the same method. This means you'd have 
to rely on the callback functions as the only method for playing back a 
file, but some decent sample code makes that a non-issue.

Tom

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.



More information about the Vorbis mailing list