2014/1/6 Christian T. Steigies <c...@debian.org>: > On Sun, Jan 05, 2014 at 10:09:08PM +0000, Manuel A. Fernandez Montecelo wrote: >> 2014/1/5 Christian T. Steigies <c...@debian.org>: >> > Manuel, >> > maybe you as the "new" sdl-mixer maintainer have an idea sdl-mixer1.2 can >> > not play xm audio files anymore? Perhaps this is an SDL bug? Or is it a >> > feature and XM files should be converted? >> > >> > Christian >> >> I added modplug support about a year ago. This was motivated by this >> change upstream for 2.0.0 version: >> >> 2.0.0: >> Sam Lantinga - Sun Jun 9 14:45:30 PDT 2013 >> * Made libmodplug the default MOD player as it is now in the public domain >> >> >> The same support existed in 1.2 since 2009 although disabled, so I >> thought that it would be useful to have modplug enabled in 1.2 if it >> was the preferred lib for SDL2_mixer: > > How did gemdropx play this file then if support was disabled?
When I said "disabled" I meant, as the changelog above, that support existed but "not the default", "disabled by default", so it was not enabled at compilation time because mikmod took precedence. I thought that I had changed the default to be modplug, coinciding with our release of SDL2 version (seeing that they preferred modplug), because support for modplug existed in SDL_mixer 1.2 and modplug was more popular (popcon) than mikmod. (Clear now what I meant?) But looking at the build logs, it seems that we didn't change it and SDL_mixer 1.2 is using still mikmod, while SDL_mixer 2.0 uses modplug to play all .mod like files, including .xm I guess. In fact only mikmod appear as dependency in the package page: http://packages.debian.org/sid/libsdl-mixer1.2 >> So I think that this failure might be because the XM files are now >> interpreted by modplug which cannot read the file. >> >> It would be useful if you install "mikmod" and "modplug-tools" and try >> to verify if they both can play the file, or have some problem, etc. > > mikmod and modplug123 play the XM files just fine. However, modplugplay does > not: > > cts@guido:~/debian/package/gemdropx/gemdropx-0.9/data/sounds>modplugplay > 2force.xm > opened /dev/dsp for playing 2force.xm [1/1] [207732] > Segmentation fault > > strace ends with this, maybe you can decrypt it: > > write(1, "opened /dev/dsp for playing 2for"..., 53opened /dev/dsp for playing > 2force.xm [1/1] [207732] ) = 53 > ioctl(3, SNDCTL_DSP_SETFMT or SOUND_PCM_READ_BITS, 0x7fff18b609e4) = 0 > ioctl(3, SNDCTL_DSP_CHANNELS or SOUND_PCM_READ_CHANNELS, 0x7fff18b609e8) = 0 > ioctl(3, SNDCTL_DSP_SPEED or SOUND_PCM_READ_RATE, 0x7fff18b609ec) = 0 > brk(0xde1000) = 0xde1000 > brk(0xe05000) = 0xe05000 > ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) > = 0 > ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) > = 0 > ioctl(0, SNDCTL_TMR_START or TCSETS, {B38400 opost isig -icanon -echo ...}) = > 0 > ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig -icanon -echo > ...}) = 0 > write(3, > "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377"..., > 4096) = 4096 > --- SIGSEGV (Segmentation fault) @ 0 (0) --- > +++ killed by SIGSEGV +++ > Segmentation fault I guess that it's worth submitting a but report to modplugplay. Also segfaults for me with a random .xm file: $ modplugplay Strange_.xm opened /dev/dsp for playing Strange_.xm [1/1] [1232927] Segmentation fault >> If this is the case, I think that it would be useful to either fix the >> XM files (if it's a problem with the format of the file itself, if the >> most popular interpreter has problems) or report the bug to ModPlug >> (maybe it's more popular but the support for XM is incomplete). > > modplugplay and modplug123 both come from modplug-tools and use libmodplug. > One works, the other does not. So where is the bug? > mikmod does not use libmodplug, and works. Scrap this, as I explained above we only use mikmod for 1.2 after all. >> Other changes might have caused this, e.g. overflow protection now >> enabled for sdl-mixer1.2 getting in the way. > > Maybe there is an overflow (how can I find out?) which triggers in > modplugplay and libsdl-mixer, but not in mikmod and modplug123. But why was > this never noticed before? Some of these protections were added when they were made the default by Debian (though dpkg-buildflags and dh compat level 9, IIRC), and we made SDL packages use this compat level 1 or 2 years ago. I am not saying that this is the cause, I'm suggesting it as a possibility and don't know how likely. About why not was noticed before, well, only since relatively recently a version with this protection enabled it's been shipped in stable versions, and .xm files are not immensely popular (unlike, say, .wav, .ogg or .mp3), so I can well imagine that there can be people experiencing failures but not bothering to report or thinking that the file is corrupt. In fact, maybe the file is corrupt or wrong in some way (e.g. declaring more channels or instruments than what are really used), or uses unusual features of the format that make the libs choke when trying to interpret the data. This is indeed the first report that we got of .xm not working with sdl-mixer (1.2 or 2), as far as I can remember. I think that valgrind might show some clue if this happens, but I think that with stack protection the program simply aborts and notifies about the problem. I will try to get a closer look at the problem and try to reproduce it, but it might take a while since I'm pretty swamped and have other pending tasks to do regarding Debian. > frozen-bubble has only ogg files no xm, so we can not compare with that. > I downloaded the first free XM mod that I could find: It seems that frozen-bubble and many other packages contain .xm files: http://packages.debian.org/search?searchon=contents&keywords=.xm&mode=path&suite=unstable&arch=any Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
