[vorbis] Audio Section - Game Programming Gems 3

Firelight Multimedia support at fmod.org
Sat Nov 10 03:47:07 PST 2001



Just for some background info this is what I found a while ago with
overriding ogg and vorbis's mallocs, im not sure if it has improved
since..

codebook.c memusage   : max 69184
sharedbook.c memusage : max 512248
vorbisfile.c memusage : max 100
block.c memusage      : max 102948
framing.c memusage    : max 74210
res0.c memusage       : max 31960
floor0.c memusage     : max 6176
window.c memusage     : max 33792
mdct.c memusage       : max 13824
info.c memusage       : max 4677
other files memusage  : max 6832

it adds up to about 850k

Cheers
Brett

> -----Original Message-----
> From: owner-vorbis at xiph.org [mailto:owner-vorbis at xiph.org] On Behalf
Of
> Mercier, Dave
> Sent: Friday, 9 November 2001 7:27 PM
> To: 'vorbis at xiph.org'
> Subject: RE: [vorbis] Audio Section - Game Programming Gems 3
> 
> 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 at labyrinth.net.au]
> Sent: Friday, November 09, 2001 12:21 AM
> To: vorbis at 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 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.

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