Arch Linux User Repository

Here's an audio capture: http://www.filedropper.com/file_274 I have sound issues on an i7 @ 3.10GHz. I've tried buffer lengths from 50 all the way to 500 ms. I tried setting SDL_AUDIODRIVER and fiddling with every audio-related option xnp2 has to offer. I also tried cranking up the PC-98's memory and using 20x (and 32x) CPU multipliers: http://seaside-tears.sblo.jp/article/29687381.html Nothing seems to work. Any ideas?

The sound stutter seems to be related to SDL's pulseaudio driver. You can force SDL to use a different driver (eg. alsa) by setting SDL_AUDIODRIVER in your environment to work around the issue

Here sound doesn’t slutter, during slowdowns (I’m on a 1.3GHz Sandy Bridge i3) it will stretch instead. Still, it sounds pretty bad compared to pmdwin (http://hg.linkmauve.fr/pmdwin) or to a recording from a real PC-9801. You may want to look at this project, which aims at rewriting those games’ engine, function by function: https://github.com/nmlgc/ReC98

A couple of other things of note: It seemed like when I disabled the stack protector without the patch, it failed to draw any graphics (text was fine). Could have been human error though as this was pretty early in the debug process. And as I'm 90% sure you're using this for touhou: have you found a way around the sound stutters? (Or is that just my computer?)

I came to the same conclusion while fiddling with gdb, thanks for the report. :)

It's not a gcc bug. These structures aren't packed so they're subject to the usual alignment rules. If you exclude the very last member of the structs, sizeof(XF86VidModeModeLine without last member) = 8*sizeof(short) + 2*sizeof(int) = 24 sizeof(XF86VidModeModeInfo without last member) = 8*sizeof(short) + 3*sizeof(int) = 28 On 64 bit machines the last member is 8 bytes long and needs 8 byte alignment. 24 is a multiple of 8 so it needs no padding, but 28 is not so it gets 4 bytes of padding inserted - meaning that in one of these structs there is an invisible 4 bytes that prevents them from being similar to each other. The type punning used here is exactly the kind that leads to undefined behaviour. Also see http://en.wikipedia.org/wiki/Data_structure_alignment#Data_structure_padding

It’s apparently the -fstack-protector-strong default parameter for gcc, set by makepkg, that is creating this crash. I don’t see any obvious issue with the current code, aside from potential alignment issue in gcc. To me this looks much more like a gcc bug than a bug in this code.

Explanation: The developer has assumed that XF86VidModeModeInfo can be turned into an XF86VidModeModeLine through pointer arithmetic, not realizing that the alignment differences prevent this on x86_64