Re: Wav loop point support

Now I'm a bit overwhelmed to be honest. This is an entirely different 
idea for me and offers new solutions for such problems with OpenAL.

I think this is based on a misunderstanding in the first place.

I attached now a wav file (I hope I can attach it here)which does have a 
loop point.
Edit: sent as attachment doesn't seem to work, so here is a screenshot 
and the .wav file:
www.oldunreal.com/temp/loop-point.jpg
www.oldunreal.com/temp/sample.wav

It can be specified with a tool like Soundforge or with the free 
Wavosaur. It specifies a part of a wav file which is looped until the 
playback is effectively stopped.

But this is maybe still the solution (and maybe an even better in the end)

For the looping API- which can be very useful in any case-

I'd personally prefer

alSourcei(sID, AL_LOOP_START, startpoint);
alSourcei(sID, AL_LOOP_END, endpoint);

aside this everything else you said makes perfectly sense to use it in 
any way needed. Also if I find a way to read out such loop points from a 
.wav file then it can be used easily for that purpose too.

~Jochen


On 06.05.2010 15:08, Chris Robinson wrote:
> On Thursday 06 May 2010 3:54:09 am [email protected] wrote:
>
>> I put this into the discussion a while ago already, but somehow it got
>> lost. The last answer I got was that it shouldn't be to difficult to
>> implement it. But at the moment I have no idea where to start. Maybe
>> someone can give me a hint, so I could try it myself, since this would be
>> quite useful for me.
>>
> We'd first need to decide on an API to specify the loop points, and define the
> behavior. Something like:
>
> alSourcei(sID, AL_LOOP_START, startpoint);
> alSourcei(sID, AL_LOOP_END, endpoint);
> // or
> ALint points[2] = { startpoint, endpoint };
> alSourceiv(sID, AL_LOOP_POINTS, points);
>
> where the points are specified in (compressed) byte offsets; in other words,
> in relation to the size given to alBufferData. I considered sample offsets,
> but that may be difficult given that OpenAL can resample audio when loading
> it.
>
> If looping is off, or if the end point is effectively<= the start point, the
> points are ignored (doesn't loop or loops over the whole queue, respectively).
> Otherwise, when playback of the source reaches the end point, it loops back to
> the start point. If the current byte offset is before the start point, it will
> continue to play from its current position (it's not forced forward into the
> loop range). If the source offset is set to the end point or beyond, however,
> it would effectively become:
>
> newoffset = ((offset-startpoint)%(endpoint-startpoint)) + startpoint
>
> This would allow a looping source to have a lead-in before getting into the
> loop. Turning off looping while the source is playing would let it finish its
> current iteration before playing through a lead-out and stopping.
>
> The loop points are also implicitly clamped to 0 and the total size of the
> buffer queue. For instance, setting the loop start to MIN_INT and loop end to
> MAX_INT would make the source loop normally over all the buffers.. although
> querying the points would still give you back MIN_INT and MAX_INT.
>
> Additionally for buffer queues, if the start point is past the end of one or
> more buffers, those buffers will NOT be marked processed when they finish
> playing.
>
> Any thoughts or comments?
> _______________________________________________
> Openal mailing list
> [email protected]
> http://opensource.creative.com/mailman/listinfo/openal
>
>


_______________________________________________
Openal mailing list
[email protected]
http://opensource.creative.com/mailman/listinfo/openal