[Openal-devel] Ogg Vorbis extension

Daniel Vogel vogel at epicgames.com
Wed Apr 2 19:56:31 PST 2003


Do you have an ETA for the new extension? I'm asking as I just finished
rewriting our mid to low level sound code and would be keen to use the new
extension right away. Actually rewrote our streaming code as well though I'm
happy to throw that away if it means less code to maintain on my end :)

-- 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
> ghiebert at creativelabs.com
> Sent: Wednesday, March 26, 2003 2:33 AM
> To: Daniel Vogel; openal-devel at opensource.creative.com
> Subject: RE: [Openal-devel] Ogg Vorbis extension
>
>
>
> It will have to be on the fly, otherwise streaming would be a problem.
> Doing the decompression on the fly in small chunks will help keep the CPU
> drain consistent as well, which is probably the right thing to do.
>
> Some insight into the implementation -- The data is kept
> compressed until a
> small chunk of uncompressed data is needed.  At that time, enough data is
> uncompressed to fill the immediate need for new data, and any remaining
> uncompressed data is stored for the next retrieval.  This works for
> queueing as well by storing the last-known stream header information with
> the source.   Whenever a new buffer is attached which doesn't have header
> information, the last-known header (for that source) will be used.   As
> long as the host program queues the correct data with the right sources,
> there shouldn't even be a problem with handling multiple streams in this
> way.
>
> I had considered (and may re-consider) a scheme where small Ogg Vorbis
> buffers which have their own headers are completely decompressed and kept
> around in that form.  This would allow short one-shot sounds to be played
> with no decompression CPU hit at play-time.  I'm not planning on
> doing this
> for now, however, as I'm not sure how useful it would be.   Strangely, the
> amount of memory used to store a small sound uncompressed may be
> very close
> to the original file size (or even smaller) with Ogg Vorbis -- the size of
> the header information can be pretty large.  Ogg Vorbis is definately most
> lucrative for large files.
>
> BTW -- Once the infrastructure is in place for Ogg Vorbis, adding ADPCM
> should be extremely easy.  That's next, and will also be done by copying
> the extension format already done in the Linux code.
>
> Garin
>
>
>
>
>
>                     "Daniel Vogel"
>
>                     <vogel at epicgam       To:
> <ghiebert at creativelabs.com>,
>                     es.com>
> <openal-devel at opensource.creative.com>
>                                          cc:
>
>                     03/25/2003           Subject:     RE:
> [Openal-devel] Ogg Vorbis extension
>                     09:33 PM
>
>
>
>
>
>
>
>
>
> How do you plan to implement the decompression? On the fly or all at load
> time? The latter would be of limited use.
>
> -- 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
> ghiebert at creativelabs.com
> Sent: Tuesday, March 25, 2003 9:20 PM
> To: openal-devel at opensource.creative.com
> Subject: [Openal-devel] Ogg Vorbis extension
>
>
>
> Attached is a document showing what I intend to do for the Ogg Vorbis
> extension for MacOS and Windows.  I'm not expecting much controversy on
> this
> one since I'm just copying what's already done on the Linux
> codebase, but I
> figured I might as well get things going in a formal way...  Feel free to
> comment, though.
>
>
>
> Garin
>
>
>
>
>
> _______________________________________________
> openal-devel mailing list
> openal-devel at opensource.creative.com
> http://opensource.creative.com/mailman/listinfo/openal-devel
>




More information about the Openal-devel mailing list