Re: [Plib-users] Toying with Ogg
Brought to you by:
sjbaker
From: Cameron M. <li...@to...> - 2001-06-29 15:11:43
|
* sjb...@ai... [2001.06.29 02:26]: > Cameron Moore wrote: > > > > * sjb...@ai... [2001.06.29 00:20]: > > > Cameron Moore wrote: > > > > > > > I'm playing around with Ogg Vorbis at the moment, and I'm stuck trying > > > > to figure out how to use it with plib. My first goal is to use > > > > slSample( Uchar *buff, int leng ) to play the stream. > > > > > > Isn't that going to be a rather large file though? > > > > If by 'file' you mean the .ogg file, then why does it have to be large? > > What are you getting at? > > The input '.ogg' files are highly compressed - right - but the output is > just a regular audio stream - so it's gonna be *HUGE* - if you have figured > out how to get Ogg to generate (say) 1/10th second of audio into a buffer, > then return to the calling program - then you can make it stream into > PLIB/SL - but if it insists on unpacking the entire track into a buffer, > or a file on disk then it's going to be REALLY big. Ahh...I see what you mean. And yes, libvorbisfile decodes the streams in sections (which you define the size of), so you could decode a section and send it to plib. > > > But I think you really need to find a way for Ogg's output to continuously > > > churn out bytes and feed them into SL...that's *hard* to do...but 2.4 Megabytes > > > per minute of music is a heck of a lot of memory to burn. > > > > That's probably more work than I want to do, but we'll see. 8-) And > > about the mem usage, how is ogg harder on memory than wav or au? > > Oh - it's not harder - it should be exactly the same...but we don't normally > ship in-game music as WAV or AU...we use MOD - or something similar that > is *MUCH* more compact. Okay, I wasn't familiar with MOD. > > IIRC, Q3A uses MP3s for some of it's intro music and doesn't seem to > > have any problems with it. > > Well, it ships on CD-ROM for starters! But in any case, it's unpacking > the MP3 into raw uncompressed audio in realtime...so it never has to > hold than a tiny fraction of a second of audio at one time...just > before the hardware has finished playing that small chunk, you go back to > the MP3 (or Ogg or MOD) decoder and tell it to generate the next tiny > chunk. Okay, this is starting to make more sense to me. Thanks for clearing some of this up. -- Cameron Moore |