Vorbis - Nov 2001 - Audio Section - Game Programming Gems 3

I'm interested to see if a senior vorbis developer would like to write an
article introducing vorbis for the audio section of Game Programming Gems 3.

The proposal summary needs to be entered in the next few days.

Here is the official announcement:

Hi, I'm the audio section editor for the newly announced Game Programming
Gems 3.

This is your opportunity to contribute to the development community and
write your name in history as a published author.  It is also an opportunity
to introduce technology to the influential world of game developers.

There is only one week left to submit proposals for articles.  You can
submit proposals at http://www.satori.org/gems3/submit.htm.  Also, feel free
to contact me at scottp@tonebyte.com to talk about ideas you may have for
game audio gems.

I have included more background on the announcements and history below.

Sincerely,

Scott Patterson

-------------------------------------------------------------------

History of audio gems:

Game Programming Gems 2 was the first book in the series to have an audio
section.

These were the audio gems:

SECTION 6 AUDIO PROGRAMMING
Introduction: Audio Programming
6.1 Game Audio Design Patterns
6.2 A Technique to Instantaneously Reuse Voices in a Sample-based
Synthesizer
6.3 Software-based DSP Effects
6.4 Interactive Processing Pipeline for Digital Audio
6.5 A Basic Music Sequencer for Games
6.6 An Interactive Music Sequencer for Games
6.7 A Low-Level Sound API

Many of these articles were introductory in nature and there is much more
detail and many new topics ahead for the next book.

-------------------------------------------------------------------

The Game Programming Gems 3 announcement:

Announcing Game Programming Gems 3! We are now accepting proposals for Gems
at http://www.satori.org/gems3. This is your opportunity to contribute to
the development community and write your name in history as a published
author. We are looking for experienced programmers to write 2-15 page
articles on a variety of subjects. GPG3 will have sections on General
Programming, Graphics, Math, AI, Audio, and an exciting new section on
Networking and Multi-player games.

About the book series:

The Game Programming Gems books are for professional and aspiring game
developers.  It is designed to be your first resource when you're working on
a challenging new programming problem. As PCs, game consoles, and graphics
and audio chips become faster and more capable, the pressure on game
developers to create new and interesting gaming experiences increases:
timelines shorten, team sizes grow, and the content benchmark elevates.
Despite these pressures, game programmers often find themselves isolated and
reinventing the wheel. The Game Programming Gems series is designed to
relieve these pressures by providing practical techniques that can be used
to solve multiple problems.

The CD-ROM that comes with each book in the series includes portable source
code in C & C++. Most of the techniques will work in OpenGL and Linux.
However, there are some techniques which will only work on Windows/Xbox/
DirectX.

About the first book:

The book Game Programming Gems is all about sharing information among game
programmers. It was designed in response to a perceived demand from the
community, and it has been exceptionally well received. Gems was designed to
be accessible to a wide variety of skill levels. Many of the gems were
fairly long and some of them were designed to be introductory, which
surprised many people. However, the book has done extremely well. The
Artificial Intelligence section was particularly well received due to the
way the section was organized-- fundamental algorithms were explained,
optimizations were discussed, and then more esoteric algorithms were
detailed toward the end of the section. One could readily read through the
section and learn about many different techniques which could be used to
solve similar problems.

About the second book:

Game Programming Gems 2 has fewer of the "tutorial-style" longer Gems
that
you found in Gems.  However, the continuity of each section has been much
improved by having dedicated section editors.   This also gives each section
more credibility, being designed and verified by an expert in the topic,
someone who knows the issues that are important to developers specializing
in that section's topic.  A new section was introduced for Gems 2: Audio.

About the third book:

Game Programming Gems 3 will be structured like Gems 2 with experienced
section editors dedicated to ensure the consistency and quality of each
section. A new section will be introduced with Gems 3: Network and
Multiplayer Games. The advent of network-capable consoles and the
ever-growing online presence demand that we address the challenges of this
growing field with its very own section.

--- >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-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

Just out of curiosity, did any of you developers take this challenge? It 
could be one of the most important thing so far in Vorbis history! The Game 
Programming Gems series is VERY popular among game programmers (I know a few 
of them)! This is a really good chance to push Ogg Vorbis and break some new 
ground!!

Regards
Per Wigren

Wednesday 07 November 2001 12:28 skrev Scott Patterson:
> I'm interested to see if a senior vorbis developer would like to write
an
> article introducing vorbis for the audio section of Game Programming Gems
> 3.
>
> The proposal summary needs to be entered in the next few days.
>
> Here is the official announcement:
>
> Hi, I'm the audio section editor for the newly announced Game
Programming
> Gems 3.
>
> This is your opportunity to contribute to the development community and
> write your name in history as a published author.  It is also an
> opportunity to introduce technology to the influential world of game
> developers.
>
> There is only one week left to submit proposals for articles.  You can
> submit proposals at http://www.satori.org/gems3/submit.htm.  Also, feel
> free to contact me at scottp@tonebyte.com to talk about ideas you may have
> for game audio gems.
>
> I have included more background on the announcements and history below.
>
> Sincerely,
>
> Scott Patterson
>
> -------------------------------------------------------------------
>
> History of audio gems:
>
> Game Programming Gems 2 was the first book in the series to have an audio
> section.
>
> These were the audio gems:
>
> SECTION 6 AUDIO PROGRAMMING
> Introduction: Audio Programming
> 6.1 Game Audio Design Patterns
> 6.2 A Technique to Instantaneously Reuse Voices in a Sample-based
> Synthesizer
> 6.3 Software-based DSP Effects
> 6.4 Interactive Processing Pipeline for Digital Audio
> 6.5 A Basic Music Sequencer for Games
> 6.6 An Interactive Music Sequencer for Games
> 6.7 A Low-Level Sound API
>
> Many of these articles were introductory in nature and there is much more
> detail and many new topics ahead for the next book.
>
> -------------------------------------------------------------------
>
> The Game Programming Gems 3 announcement:
>
> Announcing Game Programming Gems 3! We are now accepting proposals for Gems
> at http://www.satori.org/gems3. This is your opportunity to contribute to
> the development community and write your name in history as a published
> author. We are looking for experienced programmers to write 2-15 page
> articles on a variety of subjects. GPG3 will have sections on General
> Programming, Graphics, Math, AI, Audio, and an exciting new section on
> Networking and Multi-player games.
>
> About the book series:
>
> The Game Programming Gems books are for professional and aspiring game
> developers.  It is designed to be your first resource when you're
working
> on a challenging new programming problem. As PCs, game consoles, and
> graphics and audio chips become faster and more capable, the pressure on
> game developers to create new and interesting gaming experiences increases:
> timelines shorten, team sizes grow, and the content benchmark elevates.
> Despite these pressures, game programmers often find themselves isolated
> and reinventing the wheel. The Game Programming Gems series is designed to
> relieve these pressures by providing practical techniques that can be used
> to solve multiple problems.
>
> The CD-ROM that comes with each book in the series includes portable source
> code in C & C++. Most of the techniques will work in OpenGL and Linux.
> However, there are some techniques which will only work on Windows/Xbox/
> DirectX.
>
> About the first book:
>
> The book Game Programming Gems is all about sharing information among game
> programmers. It was designed in response to a perceived demand from the
> community, and it has been exceptionally well received. Gems was designed
> to be accessible to a wide variety of skill levels. Many of the gems were
> fairly long and some of them were designed to be introductory, which
> surprised many people. However, the book has done extremely well. The
> Artificial Intelligence section was particularly well received due to the
> way the section was organized-- fundamental algorithms were explained,
> optimizations were discussed, and then more esoteric algorithms were
> detailed toward the end of the section. One could readily read through the
> section and learn about many different techniques which could be used to
> solve similar problems.
>
> About the second book:
>
> Game Programming Gems 2 has fewer of the "tutorial-style" longer
Gems that
> you found in Gems.  However, the continuity of each section has been much
> improved by having dedicated section editors.   This also gives each
> section more credibility, being designed and verified by an expert in the
> topic, someone who knows the issues that are important to developers
> specializing in that section's topic.  A new section was introduced for
> Gems 2: Audio.
>
> About the third book:
>
> Game Programming Gems 3 will be structured like Gems 2 with experienced
> section editors dedicated to ensure the consistency and quality of each
> section. A new section will be introduced with Gems 3: Network and
> Multiplayer Games. The advent of network-capable consoles and the
> ever-growing online presence demand that we address the challenges of this
> growing field with its very own section.
>
>
> --- >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-dev-request@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-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

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_!

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.

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)

Alen


--
Alen Ladavac, Lead Programmer, Croteam
email: alen@croteam.com    web: http://www.croteam.com

----- Original Message -----
From: "Per Wigren" <wigren@home.se>
To: <vorbis-dev@xiph.org>; <vorbis@xiph.org>
Sent: Thursday, November 08, 2001 07:27
Subject: [vorbis] Re: [vorbis-dev] Audio Section - Game Programming Gems 3
> Just out of curiosity, did any of you developers take this challenge? It
> could be one of the most important thing so far in Vorbis history! The
Game
> Programming Gems series is VERY popular among game programmers (I know a
few
> of them)! This is a really good chance to push Ogg Vorbis and break some
new
> ground!!
>
> Regards
> Per Wigren
>
> Wednesday 07 November 2001 12:28 skrev Scott Patterson:
> > I'm interested to see if a senior vorbis developer would like to
write
an
> > article introducing vorbis for the audio section of Game Programming
Gems
> > 3.
> >
> > The proposal summary needs to be entered in the next few days.
> >
> > Here is the official announcement:
> >
> > Hi, I'm the audio section editor for the newly announced Game
Programming
> > Gems 3.
> >
> > This is your opportunity to contribute to the development community
and
> > write your name in history as a published author.  It is also an
> > opportunity to introduce technology to the influential world of game
> > developers.
> >
> > There is only one week left to submit proposals for articles.  You can
> > submit proposals at http://www.satori.org/gems3/submit.htm.  Also,
feel
> > free to contact me at scottp@tonebyte.com to talk about ideas you may
have
> > for game audio gems.
> >
> > I have included more background on the announcements and history
below.
> >
> > Sincerely,
> >
> > Scott Patterson
> >
> > -------------------------------------------------------------------
> >
> > History of audio gems:
> >
> > Game Programming Gems 2 was the first book in the series to have an
audio
> > section.
> >
> > These were the audio gems:
> >
> > SECTION 6 AUDIO PROGRAMMING
> > Introduction: Audio Programming
> > 6.1 Game Audio Design Patterns
> > 6.2 A Technique to Instantaneously Reuse Voices in a Sample-based
> > Synthesizer
> > 6.3 Software-based DSP Effects
> > 6.4 Interactive Processing Pipeline for Digital Audio
> > 6.5 A Basic Music Sequencer for Games
> > 6.6 An Interactive Music Sequencer for Games
> > 6.7 A Low-Level Sound API
> >
> > Many of these articles were introductory in nature and there is much
more
> > detail and many new topics ahead for the next book.
> >
> > -------------------------------------------------------------------
> >
> > The Game Programming Gems 3 announcement:
> >
> > Announcing Game Programming Gems 3! We are now accepting proposals for
Gems
> > at http://www.satori.org/gems3. This is your opportunity to contribute
to
> > the development community and write your name in history as a
published
> > author. We are looking for experienced programmers to write 2-15 page
> > articles on a variety of subjects. GPG3 will have sections on General
> > Programming, Graphics, Math, AI, Audio, and an exciting new section on
> > Networking and Multi-player games.
> >
> > About the book series:
> >
> > The Game Programming Gems books are for professional and aspiring game
> > developers.  It is designed to be your first resource when you're
working
> > on a challenging new programming problem. As PCs, game consoles, and
> > graphics and audio chips become faster and more capable, the pressure
on
> > game developers to create new and interesting gaming experiences
increases:
> > timelines shorten, team sizes grow, and the content benchmark
elevates.
> > Despite these pressures, game programmers often find themselves
isolated
> > and reinventing the wheel. The Game Programming Gems series is
designed
to
> > relieve these pressures by providing practical techniques that can be
used
> > to solve multiple problems.
> >
> > The CD-ROM that comes with each book in the series includes portable
source
> > code in C & C++. Most of the techniques will work in OpenGL and
Linux.
> > However, there are some techniques which will only work on
Windows/Xbox/
> > DirectX.
> >
> > About the first book:
> >
> > The book Game Programming Gems is all about sharing information among
game
> > programmers. It was designed in response to a perceived demand from
the
> > community, and it has been exceptionally well received. Gems was
designed
> > to be accessible to a wide variety of skill levels. Many of the gems
were
> > fairly long and some of them were designed to be introductory, which
> > surprised many people. However, the book has done extremely well. The
> > Artificial Intelligence section was particularly well received due to
the
> > way the section was organized-- fundamental algorithms were explained,
> > optimizations were discussed, and then more esoteric algorithms were
> > detailed toward the end of the section. One could readily read through
the
> > section and learn about many different techniques which could be used
to
> > solve similar problems.
> >
> > About the second book:
> >
> > Game Programming Gems 2 has fewer of the "tutorial-style"
longer Gems
that
> > you found in Gems.  However, the continuity of each section has been
much
> > improved by having dedicated section editors.   This also gives each
> > section more credibility, being designed and verified by an expert in
the
> > topic, someone who knows the issues that are important to developers
> > specializing in that section's topic.  A new section was
introduced for
> > Gems 2: Audio.
> >
> > About the third book:
> >
> > Game Programming Gems 3 will be structured like Gems 2 with
experienced
> > section editors dedicated to ensure the consistency and quality of
each
> > section. A new section will be introduced with Gems 3: Network and
> > Multiplayer Games. The advent of network-capable consoles and the
> > ever-growing online presence demand that we address the challenges of
this
> > growing field with its very own section.
> >
> >
> > --- >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-dev-request@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@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@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

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@3dgamedev.com]
Sent: Thursday, November 08, 2001 5:10 AM
To: vorbis@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@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@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

Re: the standard lib thing - Replacing standard lib functions with your own
implementation isn't as easy as it sounds. For one, I'm a programmer who
can
get Vorbis support into a game through another library. I have absolutely no
control over what gets linked into the 30 or 40 games that use that library
though, so "I" can't do anything about that.

Game developers usually do not replace all standard lib functions. The first
rule is they completely avoid their use where possible. Then, they may only
use a handful from the standard library. There may be many functions in a
standard library - let's say the math library has 50 functions in it. The
game may only use 3 or 4 of those. But the way the standard lib code is laid
out, it may link in all 50 in one swoop. Now we certainly don't want to
re-write 50 functions if we may only use 3 or 4 of them. And before you say
it we have no idea which 3 or 4 of the standard lib may be used. Code in a
typical game is contributed by hundreds of programmers, and the projects are
very large, and certainly not everyone knows what everyone else is doing or
needs.

Anyway, if we had a function table of the functions we had to replace, we
could just fill it in with our versions, write custom versions just for the
sake of Vorbis, or we could fill some of them in with standard lib
functions. The Vorbis code should then maybe strive to use as few external
functions as possible to simplify this interface. If something like this
isn't done, it's a case of hack the Vorbis source to make it compatible
in
our game, and that's a bad thing if we want to move forward easily (e.g. to
Vorbis V2.0). This is how most of our code works and it makes life easier.
All our audio codecs don't use standard C functions, save maybe memcpy and
memset replacements - of course Vorbis is more complex, and we'll have to do
more work to get it hooked in.

I don't want to push this too hard anyway, I'm just trying to let you
know
how it looks from the perspective of one game developer. 

Thanks,
Dave.

-----Original Message-----
From: Michael Smith [mailto:msmith@labyrinth.net.au]
Sent: Friday, November 09, 2001 12:21 AM
To: vorbis@xiph.org
Subject: Re: [vorbis] Audio Section - Game Programming Gems 3
>Ok, this might be completely off-track, and I am probably completely wrong,
>but I have a strange feeling in the back of my head.... Is that memory
usage
>dependent on the size of the stream? Have you tried with very small streams
>(a few seconds) ? How exactly did you measure the memory usage? By checking
>difference before and after opening a decoder, or by calculating it
>manually?
No, he's right - libvorbis memory usage is pretty bad (compared to mp3,
at least). For common cases it can be greatly reduced (with some substantial
work, though), though worst-case will probably still be like this.
>Why don't you create wrapper stubs for stdlib functions? I mean, if you
>don't want to use the stdlib functions and you don't link with them,
I
guess
>you must have your implementations, right? So wouldn't it be easy to
just
>make wrappers that are named exactly as stdlib functions and that call your
>functions, then liknk with your wrapper library instead of the stdlib?
>It is same effect as doing vectorization, it requires approximately the
same
>effort on your side, yet it doesn't require a single line of code
changed
in
>vorbis.
>What do you think?
Yes. This is a much, much better way of doing things.

Michael

--- >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@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@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.