|
|
|
This thread is locked; no one can reply to it.
|
| Audio: Modules loop even with ALLEGRO_PLAYMODE_ONCE |
|
Bruce Pascoe
Member #15,931
April 2015
 |
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.
|
|
SiegeLord
Member #7,827
October 2006
 |
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. "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
|
Bruce Pascoe
Member #15,931
April 2015
|
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): 112itr = duh_get_it_sigrenderer(df->sig);
113dumb_it_set_loop_callback(itr, stream->spl.loop == _ALLEGRO_PLAYMODE_STREAM_ONCE
114 ? dumb_it_callback_terminate : NULL, NULL);
This indeed prevented it from looping, but caused a buffer overrun that I can't track down.
|
|
SiegeLord
Member #7,827
October 2006
|
Bruce Pascoe said: I know this will blow up if it's not an .it file, hence why it's experimental 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. "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
|
Bruce Pascoe
Member #15,931
April 2015
|
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
|
|
SiegeLord
Member #7,827
October 2006
|
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. "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
|
Bruce Pascoe
Member #15,931
April 2015
|
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!
|
|
|
