[Openal] Audio Entry Point/Compositing(? -- Mix)

[Scott Harper]

What would probably be useful to me and my application is something  
as simple as saying to OpenAL alGetNext[TIME_SEGMENT]Data(&byteData 
[], AL_SAMPLE_RATE_CHOICE); or something similar to that.  Or perhaps  
you could specify how much to pull based on some timecode, like a  
video runs ar 30 or 60 FPS, so you want to pull out 1/30th or 1/60th  
of a second's worth of mixed audio from where you left off.  Also,  
this gives you the ability to say "Hey, this OTHER sound is scheduled  
to start playing at this time, so start that, OAL, to be included in  
the mix."  And then you have a good ability to mix the audio, and  
then do whatever else you want with it, be that raplay it, or encode  
it using Quicktime or anything else you could dream of.

So:
alGetNextSecondMixed(&byteData, AL_44_1_KHZ);
alGetNextFrame24Mized(&byteData, AL_22_KHZ);

as two possible functions.

Am I completely off-track here for what would work/is feasible/ 
consistent with the rest of OpenAL...?

--Scott

PS:  Ryan, sorry about the message sent directly to you... >.<

On 15 Sep, 2005, at 4:44 PM, Ryan C. Gordon wrote:

>
>
>> Even if you pursuaded it to generate a readable WAV file, it would  
>> still
>> take an hour to mix together an hours worth of music.  What you'd  
>> like is
>> to have it work at maximum speed using close to 100% of the CPU to  
>> mix
>> an hour's worth of music in 30 seconds or so...but there is no way  
>> to do
>> that.
>>
>
> Ok, I'm intrigued, I admit.
>
> In terms of extension, how would this work?
>
> Perhaps open a "file:///x.wav" device or something in alcOpenDevice(),
> make sure the context is synchronous, so it mixes during
> alcProcessContext() when the app has adjusted all the sources (etc)  
> and
> never any other time, and maybe add a query for ALC_TICKS (or  
> something
> better named) that reports the number of milliseconds that the AL has
> processed (which may be way ahead of or way behind wallclock time,
> depending on the processing involved)?
>
> GL totally dodges this issue by the nature of graphics...you don't
> actually care how long a given frame takes. Well, okay, you CARE, but
> not in the same way audio processing cares.
>
> --ryan.
>
> _______________________________________________
> openal mailing list
> openal at opensource.creative.com
> http://opensource.creative.com/mailman/listinfo/openal
>