I didn’t find any answer on this by the search-function:
The behaviour of streams in combination with FSOUND_SetLoopMode looks a bit inconsistent to me:
If you load a stream and set the flag FSOUND_LOOP_NORMAL for it, you are able to stop it’s looping by calling FSOUND_SetLoopMode(1, FSOUND_LOOP_OFF) for the channel where it’s played on – fine.
So a loop-stream will not loop on a non-loop-channel.
But in opposite if you do not set the FSOUND_LOOP_NORMAL-flag for the stream, then calling FSOUND_SetLoopMode(1, FSOUND_LOOP_NORMAL) for the channel where it is played on, will not force it to be played as looped!
So a non-loop-stream will [i:32tkh7xx]not [/i:32tkh7xx]loop on a loop-channel – though it should, shouldn’t it ?
For samples instead all works fine, so you can force samples to be played as looped when they are played on a channel for that FSOUND_SetLoopMode(1, FSOUND_LOOP_NORMAL) was called.
So ‘non-loop’-samples will loop on a loop-channel.
Isn’t this a bit inconsistent ? Or is there a concept behind that I do not see atm ? If not, couldn’t this be changed in a future version – so that playing a non-loop-stream on a loop-channel will loop it ?
OK, FSOUND_SetLoopMode is for samples only, but why does it affect streams then in the way that looped streams are not looped on a channel with FSOUND_SetLoopMode set to FSOUND_LOOP_OFF ?
It’s no big problem, of course, it just seems to be a bit unlogically to me.
Either FSOUND_SetLoopMode should affect streams always or never.
Ah! Now the die is cast! Thanks for clearing the stream/sample-coherence (I didn’t knew that exactly). So there [i:2c0zu74r]is[/i:2c0zu74r] a strict logical reason for it that helps to understand & remember. (would be strange, if there wouldn’t be any )
Please login first to submit.