[Openal-devel] Ogg Vorbis implementation query

[Daniel Vogel]

Before I forget - a licensee actually looked into using Ogg Vorbis for all
sounds and noticed that the file format overhead rendered it useless unless
you have a big vorbis file and index "subregions". This might be interesting
though I think ADPCM is a much better approach for small one shot sounds.

-- Daniel, Epic Games Inc.

> -----Original Message-----
> From: openal-devel-admin at opensource.creative.com
> [mailto:openal-devel-admin at opensource.creative.com]On Behalf Of Daniel
> Vogel
> Sent: Saturday, April 05, 2003 2:19 PM
> To: Daniel PEACOCK
> Cc: Bernd Kreimeier; openal-devel at opensource.creative.com
> Subject: RE: [Openal-devel] Ogg Vorbis implementation query
>
>
> Very good idea!  The cut off size should be a per buffer property and not
> be global and there could be an implementation specific minimum cut off
> point you could query for. I assume it doesn't make sense to decompress
> and stream on the fly for say a decompressed size of 64 KByte or
> something
> like that.
>
> BTW, Garin, does an app simply pass in 0 as the rate argument to
> BufferData for Ogg Vorbis?
>
> -- Daniel, Epic Games Inc.
>
> On Sat, 5 Apr 2003, Daniel PEACOCK wrote:
>
> >
> > Hi,
> >
> > I've seen a couple of audio engines that will make the decision
> of whether to decompress the
> > compressed audio data immediately, or at playtime, based on the
> size of the actual data (this was
> > with MP3s).  For compressed files with big headers, it can
> actually save you memory to decompress
> > the audio at load time.
> >
> > I guess UT2003 has a much bigger graphic file size footprint
> than audio - but that is not true of
> > all games, I remember talking to a few developers at this last
> GDC who have 1GB of raw audio data
> > ... so they need some serious compression / decompression !
> >
> > Perhaps we could add a new function in AL that allows the
> application to specify a 'cut-off' file
> > size for when a compressed file should be decompressed at load
> time, rather than run-time.   Any
> > buffers smaller than the cut-off size will be decompressed
> immediately.  That way if a game wants to
> > save memory, and doesn't mind run-time decompression +
> streaming of all their compressed audio they
> > can set the cut-off to 0 bytes.   But a different application
> that has memory to spare can raise the
> > cut-off level to lower the CPU hit.
> >
> > Dan
> >
> >
> >
> >
>
>
> >                       ghiebert at creativelabs.com
>
>
> >                       Sent by:
> To:       openal-devel at opensource.creative.com
>
> >                       openal-devel-admin at opensource.c
> cc:       "Bernd Kreimeier" <bk at oddworld.com>, "Daniel Vogel"
> <vogel at epicgames.com>
> >                       reative.com
> Subject:  RE: [Openal-devel] Ogg Vorbis implementation query
>
> >
>
>
> >
>
>
> >                       04/04/03 20:13
>
>
> >
>
>
> >
>
>
> >
> >
> >
> >
> >
> > Daniel:
> >
> > I suppose that I see your point -- you could perhaps justify
> loading a 4MB compressed Ogg Vorbis
> > file into memory and just use it if the impelementation kept it
> compressed in memory.  I'll take the
> > comment as a definate vote for "decompress all Ogg Vorbis on
> the fly."  I can certainly do it that
> > way -- that's what I was planning on doing originally, and then
> I suddenly found myself thinking
> > "Hmm -- maybe there's another way..."
> >
> > I suppose the other side-benefit for the hardware
> implementations is that we could look into
> > accelerating the Ogg Vorbis support and have a serious
> performance advantage over implementations
> > that have to resort to software for handling lots of compressed
> content at once...
> >
> > Garin
> >
> >
> >
> >
> >
>
> _______________________________________________
> openal-devel mailing list
> openal-devel at opensource.creative.com
> http://opensource.creative.com/mailman/listinfo/openal-devel
>