Exactly what the post title says, if you use the audio stream API to load a module (.it, etc.), even if you set the playmode to ALLEGRO_PLAYMODE_ONCE, the music will loop indefinitely.

I'll investigate this a bit, but keep in mind that (as far as I know), modules may specify a loop inside the file itself. If that's the case, there's nothing Allegro can do about that. Maybe try playing this file inside a different player and see if it loops forever there as well.

EDIT: I tried out a few mod's and xm's I had, and indeed many of them had internal loop events (or worse, events that literally just stopped the music). That said, turns out Allegro can do something about it. I'll investigate what's appropriate to do, but perhaps we could disable those loop points for PLAYMODE_ONCE.

Having finally gotten Allegro to build on Windows, I tried making this experimental change at the beginning of modaudio_stream_update() (I know this will blow up if it's not an .it file, hence why it's experimental):

This indeed prevented it from looping, but caused a buffer overrun that I can't track down.

It actually won't, those functions work for most module formats (although you need to check the return itr just in case regardless). Strange about your buffer overrun though, I did not observe that when I tried the very same modification yesterday.

Yeah, with that modification in place, when the stream is destroyed, MSVC reports heap corruption, breaking into the debugger in kcm_stream.c on line 152:

al_free(stream->main_buffer);

Meaning stream->main_buffer was overrun somehow. In Release mode, the application segfaults after the track ends, so it's not specific to a debug build. Compiler is MSVC 2013 x86, for what it's worth. Assuming the forums will let me post it, here's a link to the .it file I used for testing:

https://drive.google.com/open?id=0BxPKLRqQOUSNVXhxNEpNdUJWbUE&authuser=0

Thanks that was useful, it crashed for me too. There indeed was a buffer overflow bug, which is now fixed.

I've also committed essentially the change you suggested, alongside with disabling the XM zero-speed events entirely: commit.

Awesome, this fixes both issues. I'm glad, because I never would have found that buffer overrun... who knew it would be something as stupid as writing ints instead of bytes? Certainly not me!