Prince of Persia

SDL 1.2 to 2.0 Migration Guide wrote:Audio

The good news for audio is that, with one exception, it's entirely backwards compatible with 1.2. If you want the new features, they're available to you, but you'll probably just compile and run without them.

That one really important exception: The audio callback does NOT start with a fully initialized buffer anymore. You must fully write to the buffer in all cases. If you don't have enough audio, your callback should write silence. If you fail to do this, you'll hear repeated audio, or maybe audio corruption. If you want to restore the old behavior of unconditionally initializing the buffer, just put an SDL_memset(stream, 0, len) at the start of your callback.

console wrote:norbert@ren ~/Desktop/apoplexy-2.1b/wav $ mplayer *|grep '1ch\|wav'
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.
Playing check_box.wav.
AO: [pulse] 11025Hz 1ch u8 (1 bytes per sample)
Playing chomper.wav.
AO: [pulse] 11000Hz 1ch u8 (1 bytes per sample)
Playing cross.wav.
AO: [pulse] 11025Hz 1ch u8 (1 bytes per sample)
Playing dosbox.wav.
AO: [pulse] 11025Hz 1ch u8 (1 bytes per sample)
Playing extras.wav.
AO: [pulse] 11000Hz 1ch u8 (1 bytes per sample)
Playing hum_adj.wav.
AO: [pulse] 11025Hz 1ch u8 (1 bytes per sample)
Playing level_change.wav.
AO: [pulse] 11025Hz 1ch u8 (1 bytes per sample)
Playing move_room.wav.
AO: [pulse] 11025Hz 1ch u8 (1 bytes per sample)
Playing ok_close.wav.
AO: [pulse] 11025Hz 1ch u8 (1 bytes per sample)
Playing plus_minus.wav.
AO: [pulse] 11025Hz 1ch u8 (1 bytes per sample)
Playing popup_close.wav.
AO: [pulse] 11025Hz 1ch u8 (1 bytes per sample)
Playing popup.wav.
AO: [pulse] 11025Hz 1ch u8 (1 bytes per sample)
Playing popup_yn.wav.
AO: [pulse] 11025Hz 1ch u8 (1 bytes per sample)
Playing save.wav.
AO: [pulse] 11025Hz 1ch u8 (1 bytes per sample)
Playing screen2or3.wav.
AO: [pulse] 11025Hz 1ch u8 (1 bytes per sample)
Playing scroll.wav.
AO: [pulse] 11025Hz 1ch u8 (1 bytes per sample)
norbert@ren ~/Desktop/apoplexy-2.1b/wav $

cvt.buf = malloc (dlen*cvt.len_mult);

cvt.buf = (Uint8 *)malloc (dlen*cvt.len_mult);

Norbert wrote:Suggestions on how to proceed are most welcome.

Norbert wrote:Maybe I should point people from the SDL mailing list (or IRC channel) to this thread; maybe a bug report is in order?

        if (src_rate < dst_rate) {
            const double mult = ((double) dst_rate) / ((double) src_rate);
            cvt->len_mult *= (int) SDL_ceil(mult);
            cvt->len_ratio *= mult;
        } else {
            cvt->len_ratio /= ((double) src_rate) / ((double) dst_rate);
        }

double
SDL_ceil(double x)
{
#ifdef HAVE_CEIL
    return ceil(x);
#else
    return (double)(int)((x)+0.5);
#endif /* HAVE_CEIL */
}

When a finite value of real floating type is converted to an integer type other than _Bool, the fractional part is discarded (i.e., the value is truncated toward zero).

The SDL_ceil function is implemented incorrectly when HAVE_CEIL is not defined (HAVE_LIBC not defined).
[...]
This functions is used in the SDL_BuildAudioResampleCVT function of the audio subsystem (SDL_audiocvt.c), and causes a bug in that function.

Norbert wrote:After I had made that first change, two samples were still distorted, chomper.wav and extras.wav, the two WAVs that you also mentioned.
[...]
I decided: I'll try various sampling rates other than 22050 and if nothing works, I'll file a bug report.
Since 44100 fixed the problem (on Linux), I didn't do the latter.

    const int dstsize = (int) (((double)cvt->len_cvt) * cvt->rate_incr);

David wrote:The simplest workaround would be to replace "dlen*cvt.len_mult" with "dlen*(cvt.len_mult+1)".

David wrote:I attached the port to this post.

David wrote:[...], the former is not even reported in the bugzilla [...]

Norbert wrote:Will you report it, including your sample code?

Norbert wrote:By the way, now I'm curious why I didn't run into the heap corruption problem on Linux, since I didn't use a bleeding edge SDL2 either; any ideas?

David wrote:Done: https://bugzilla.libsdl.org/show_bug.cgi?id=2389

Norbert wrote:Hm... when PoP2 editing (maybe also PoP1) under Linux (maybe also Windows), v2.1b apparently has (major) memory leakage, especially when a zoomed (2x) view is used.

	SDL_DestroyTexture(messaget);
	SDL_FreeSurface(message);

Norbert wrote:It also messes up PoP2 images in zoomed mode, for example in the starting room of level 11, but basically all over the place.

Norbert wrote:The memory problem makes sense, since I never really looked into making sure I free up stuff