This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Patch to add version check to configure (SDL_mixer.FLAC_config.patch, text/plain, 2008-04-16 05:39:04 +0000, 3408 bytes)
• Patch to add FLAC version checking in configure (SDL_mixer.FLAC_config.patch, text/plain, 2008-04-16 13:51:02 +0000, 3406 bytes)

Reported in version: unspecified
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2008-03-12 10:00:55 +0000, Ozkan Sezer wrote:

FLAC support, as implemented in SDL_mixer requires flac version >= 1.1.3 :
I have 1.1.2 installed and it surely fails compiling. Can you add a check
for

defined(FLAC_API_VERSION_CURRENT) && (FLAC_API_VERSION_CURRENT >= 8)

in the configure scripts (or document this requirement) please?
Sorry that I can't provide a patch, I'm not good with autotools stuff.

Regards,
Ozkan Sezer

On 2008-04-15 13:22:42 +0000, Austen Dicken wrote:

I am currently working on a patch to get this tested during the configure script. I'll have it posted in a few days.

On 2008-04-16 05:39:04 +0000, Austen Dicken wrote:

Created attachment 252
Patch to add version check to configure

Added a patch to check for the proper version. Not sure if it is done the best way possible but it does work.

On 2008-04-16 06:32:58 +0000, Ozkan Sezer wrote:

(In reply to comment # 2)

Created an attachment (id=252) [details]
Patch to add version check to configure

Added a patch to check for the proper version. Not sure if it is done the best
way possible but it does work.

Seems to work for me on linux:
configure: error: *** FLAC library so-name version >= 8 not found!

Although, it would probably be better to have a behavior like in
the case of --enable-music-mp3, ie. disable the option and spit out
a warning, instead, but that's a personal preference.

On 2008-04-16 13:51:02 +0000, Austen Dicken wrote:

Created attachment 253
Patch to add FLAC version checking in configure

I modified the patch so that now it should only print a warning if the proper version of FLAC is not found, and then disable it.

Thanks for the suggestion!

On 2009-09-26 02:16:38 +0000, Sam Lantinga wrote:

This is in for the next release. Thanks!

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• wavestream.c.diff (wavestream.c.diff, text/plain, 2006-01-24 01:46:57 +0000, 878 bytes)

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2006-01-24 01:46:30 +0000, Sam Lantinga wrote:

Date: Tue, 15 Apr 2003 23:36:17 +0300
From: King Of The Bongo [email protected]
Subject: [SDL] SDL_mixer patch

SDL_mixer

Hi, this is modified version of wavestream.c

When you call Mix_VolumeMusic (volume) and play PCM wav stream it does
not apply and the wav file plays with the old values.

On 2006-01-24 01:46:57 +0000, Sam Lantinga wrote:

Created attachment 33
wavestream.c.diff

On 2006-01-24 01:47:33 +0000, Sam Lantinga wrote:

Obviously we don't want to do a malloc and a free here, but his observation seems valid. What do you think, Ryan?

On 2006-01-24 04:12:46 +0000, Ryan C. Gordon wrote:

We probably can't avoid the malloc altogether, but we can make it just realloc() if a buffer is too small.

However, we're always mixing against silence here, and just need to adjust volume...I'm wondering if we should avoid calling SDL_MixAudio altogether, which would totally eliminate the need for a second buffer.

--ryan.

On 2006-01-24 12:46:33 +0000, Sam Lantinga wrote:

(In reply to comment # 3)

We probably can't avoid the malloc altogether, but we can make it just
realloc() if a buffer is too small.
However, we're always mixing against silence here, and just need to adjust
volume...I'm wondering if we should avoid calling SDL_MixAudio altogether,
which would totally eliminate the need for a second buffer.
--ryan.

Sounds reasonable to me. Do we need an SDL_AttenuateVolume call? :)

On 2006-01-24 14:42:43 +0000, Ryan C. Gordon wrote:

That might be nice, actually, but for now, we should just put a fix in here that doesn't require an SDL API change. I'll write up a patch.

--ryan.

On 2006-01-27 11:23:22 +0000, Ryan C. Gordon wrote:

Setting Sam as "QA Contact" on all bugs (even resolved ones) so he'll definitely be in the loop to any further discussion here about SDL.

--ryan.

On 2006-04-30 23:27:41 +0000, Sam Lantinga wrote:

Hey Ryan, any progress on this?

On 2006-05-07 17:19:40 +0000, Sam Lantinga wrote:

I'd like to get this fixed for SDL_mixer 1.2.7 release, if possible.

On 2006-05-09 00:34:03 +0000, Ryan C. Gordon wrote:

eh...mixing against silence isn't ideal, but SDL handles all the different data formats under the hood, so it's not worth changing it for the small performance boost.

I'd say use the existing patch, but use an alloca() instead of malloc()/free(). Everything else is going to make things worse for otherwise stable code.

--ryan.

On 2006-05-09 04:02:57 +0000, Sam Lantinga wrote:

This patch is in Subversion, modified to use alloca instead of malloc.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 1.2.8
Reported for operating system, platform: Windows (XP), x86

Comments on the original bug report:

On 2008-01-09 03:46:47 +0000, Carl Castanier wrote:

We use sdl_mixer for http://svn.gna.org/viewcvs/freeciv-warclient/trunk/client/audio_sdl.c?rev=799&view=log
We don't use other function of SDL so I submit bug here.

I compile under Windows with SDL 1.2.13 (latest). During games, I have sometimes a crash. It's appends when many sounds must be played at same times. In our case many units attacks and each play sounds. I have recorded backtrave with gdb if it can help you.

(gdb) bt

0 0x62760fbd in _libuser32_a_iname ()

1 0x6276e5f4 in _libuser32_a_iname ()

2 0x6b06c388 in _libuser32_a_iname ()

3 0x6b06c3b0 in _libuser32_a_iname ()

4 0x6b06f7fb in _libuser32_a_iname ()

5 0x6b070e74 in _libuser32_a_iname ()

6 0x7e398734 in _libmsvcrt_a_iname ()

7 0x7e398816 in _libmsvcrt_a_iname ()

8 0x7e39b4c0 in _libmsvcrt_a_iname ()

9 0x7e39b50c in _libmsvcrt_a_iname ()

10 0x7c91eae3 in _libmsvcrt_a_iname ()

11 0x6b06c3b0 in _libuser32_a_iname ()

12 0x6b06f7fb in _libuser32_a_iname ()

13 0x6b070e74 in _libuser32_a_iname ()

14 0x7e398734 in _libmsvcrt_a_iname ()

15 0x7e398816 in _libmsvcrt_a_iname ()

16 0x7e39b4c0 in _libmsvcrt_a_iname ()

17 0x7e39b50c in _libmsvcrt_a_iname ()

18 0x7c91eae3 in _libmsvcrt_a_iname ()

19 0x7e39b3f9 in _libmsvcrt_a_iname ()

20 0x5b093c20 in end_ ()

21 0x5b0ae300 in end_ ()

22 0x5b091ac7 in end_ ()

23 0x5b091b3d in end_ ()

24 0x7e39bb15 in _libmsvcrt_a_iname ()

25 0x6b06db10 in _libuser32_a_iname ()

26 0x6b070e74 in _libuser32_a_iname ()

27 0x7e398734 in _libmsvcrt_a_iname ()

28 0x7e398816 in _libmsvcrt_a_iname ()

29 0x7e39b89b in _libmsvcrt_a_iname ()

30 0x7e39b903 in _libmsvcrt_a_iname ()

31 0x5b0b881f in end_ ()

32 0x5b091ac7 in end_ ()

33 0x5b091b3d in end_ ()

34 0x7e39bb15 in _libmsvcrt_a_iname ()

35 0x6b06db10 in _libuser32_a_iname ()

36 0x6b070e74 in _libuser32_a_iname ()

37 0x7e398734 in _libmsvcrt_a_iname ()

38 0x7e398816 in _libmsvcrt_a_iname ()

39 0x7e3989cd in _libmsvcrt_a_iname ()

40 0x7e398a10 in _libmsvcrt_a_iname ()

41 0x6b070f6d in _libuser32_a_iname ()

42 0x6b0710ed in _libuser32_a_iname ()

43 0x672de877 in _libmsvcrt_a_iname ()

44 0x672dfd5b in _libmsvcrt_a_iname ()

45 0x672dff3a in _libmsvcrt_a_iname ()

46 0x60589c2e in end_ ()

47 0x004c227f in ui_main ()

48 0x004055ec in SDL_main ()

49 0x00505eeb in console_main (argc=1, argv=0x3d4c90)

at ./src/main/win32/SDL_win32_main.c:246

50 0x005060c9 in WinMain (hInst=0x400000, hPrev=0x0, szCmdLine=0x241f12 "",

sw=10) at ./src/main/win32/SDL_win32_main.c:382

Cordially

On 2008-06-30 20:50:39 +0000, Roger Booth wrote:

This bug report may be a duplicate of 539 - Segmentation fault on playing sounds.

However, I can give a specific procedure to quickly and easily replicate the crash.

I created a standard Single-Document-Interface Windows SDK application. In WinMain, before creating the main window, I initialized SDL and after the main loop exited, I shut down SDL. One menu option invoked a dialog. On this dialog were three buttons, although two would be sufficient.

Two of the the three buttons on the dialog were set up to play wave files using Mix_LoadWAV() and Mix_PlayChannel().

The third was set up to play a .MP3 file using Mix_LoadMUS() and Mix_PlayMusic(). I used a Windows timer to poll for the end of the .MP3 file, calling Mix_PlayingMusic() on each timer message. The button to play the .MP3 was disabled while the .MP3 file was being played.

I found that I could start up many of the wave files in rapid succession, such that I could hear them overlapping each other - that part worked fine.

I found that I could play the .MP3 file in succession many times without problems. The fact that the button to play the .MP3 was disabled until the file was finished playing kept me from mixing two .MP3 files together, which I assume is beyond the capabilities of SDL_mixer. No complaints there.

I am able to trigger the bug very regularly (not every time, but most times) by playing a wave file, and while the wave file is still playing, start to play the .MP3 file.

When I trigger the error, the error is in the file mpegstream.cpp in the function MPEGstream::copy_byte(), in the final statement - return(*data++);

The error is an attempt to dereference a null pointer. The Microsoft Development Environment reports the following:

Unhandled exception at 0x01741242 (smpeg.dll) in TestApplication.exe: 0xC0000005: Access violation reading location 0x00000000.

SDL 1.2.13
SDL_mixer 1.2.8
SMPEG 0.4.5
MSWindows 2000 Professional Service Pack 4
Microsoft Development Environment 2003 7.1.3088

On 2009-10-03 02:56:45 +0000, Sam Lantinga wrote:

We've fixed a bunch of crash bugs lately, can you check out this snapshot?
http://www.libsdl.org/tmp/SDL_mixer.zip

Thanks!

On 2009-10-10 02:16:32 +0000, Ryan C. Gordon wrote:

I'm inclined to think this is an SMPEG bug and not an SDL_mixer bug.

This is what Valgrind finds in playmus for a random MP3 that is otherwise playing fine with SDL_mixer...

(SMPEG predates Valgrind, and hasn't received much attention since.)

Opened audio at 22050 Hz 16 bit stereo (LE), 4096 bytes audio buffer
==31631== Conditional jump or move depends on uninitialised value(s)
==31631== at 0x6FCE96C: MPEGaudio::Stop() (MPEGaudio.cpp:205)
==31631== by 0x6FCEA89: MPEGaudio::Rewind() (MPEGaudio.cpp:219)
==31631== by 0x6FE0C66: MPEGaudio::initialize() (mpegtoraw.cpp:128)
==31631== by 0x6FCEE28: MPEGaudio::MPEGaudio(MPEGstream*, bool) (MPEGaudio.cpp:33)
==31631== by 0x6FC857D: MPEG::parse_stream_list() (MPEG.cpp:492)
==31631== by 0x6FC8EEA: MPEG::Init(SDL_RWops*, bool) (MPEG.cpp:106)
==31631== by 0x6FCE422: SMPEG_new (smpeg.cpp:84)
==31631== by 0x4E39534: Mix_LoadMUS (music.c:521)
==31631== by 0x401884: main (playmus.c:196)
Playing /home/icculus/rodeo.mp3
==31631==
==31631== Thread 3:
==31631== Conditional jump or move depends on uninitialised value(s)
==31631== at 0x6FDDBF6: MPEGaudio::layer3hybrid(int, int, float () [18], float () [32]) (mpeglayer3.cpp:1631)
==31631== by 0x6FDF547: MPEGaudio::extractlayer3() (mpeglayer3.cpp:1762)
==31631== by 0x6FE0934: MPEGaudio::run(int, double*) (mpegtoraw.cpp:314)
==31631== by 0x6FE0A2F: Decode_MPEGaudio(void*) (mpegtoraw.cpp:372)
==31631== by 0x5088816: SDL_RunThread (SDL_thread.c:204)
==31631== by 0x50D07D8: RunThread (SDL_systhread.c:47)
==31631== by 0x5E373B9: start_thread (in /lib/libpthread-2.9.so)
==31631== by 0x6131FCC: clone (in /lib/libc-2.9.so)
==31631==
==31631== Conditional jump or move depends on uninitialised value(s)
==31631== at 0x6FDDBF6: MPEGaudio::layer3hybrid(int, int, float () [18], float () [32]) (mpeglayer3.cpp:1631)
==31631== by 0x6FDF746: MPEGaudio::extractlayer3() (mpeglayer3.cpp:1766)
==31631== by 0x6FE0934: MPEGaudio::run(int, double*) (mpegtoraw.cpp:314)
==31631== by 0x6FE0A2F: Decode_MPEGaudio(void*) (mpegtoraw.cpp:372)
==31631== by 0x5088816: SDL_RunThread (SDL_thread.c:204)
==31631== by 0x50D07D8: RunThread (SDL_systhread.c:47)
==31631== by 0x5E373B9: start_thread (in /lib/libpthread-2.9.so)
==31631== by 0x6131FCC: clone (in /lib/libc-2.9.so)

--ryan.

On 2009-10-10 19:27:28 +0000, Ryan C. Gordon wrote:

svn revision # 386 in smpeg's repository fixes the valgrind issues mentioned here, but I can't say if they cause this bug (however, one of them is an uninitialized variable being checked when starting playback of a new MP3). This is as far as I can go with this bug.

--ryan.

On 2009-10-10 21:08:01 +0000, Sam Lantinga wrote:

Can you retest with the latest code from subversion?

Thanks!

On 2010-04-16 20:26:24 +0000, wrote:

(And by quick and dirty fix, bad organization of needed headers in the project).

On 2010-04-16 20:28:41 +0000, wrote:

(Sorry about the above comment - browser decided to (unknowingly) move me to this bug while commenting on a different bug)

On 2011-12-31 10:48:00 +0000, Sam Lantinga wrote:

Waiting for several years on this one. :)

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: Windows (XP), x86

Comments on the original bug report:

On 2006-07-08 02:35:43 +0000, Markus Kettunen wrote:

I wanted to make my game a choice of turning sounds off from the menu to release them for use by other programs, but encountered a bug I myself find strange:

Initialize SDL_mixer
Deinitialize SDL_mixer
Initialize SDL_mixer
Deinitializing SDL_mixer now crashes

The code needed to reproduce the crash is in that URL.

On 2006-09-11 15:19:26 +0000, Dmitry Yakimov wrote:

URL provided is incorrect :(

On 2006-11-28 14:20:37 +0000, Patrice Mandin wrote:

*** Bug 295 has been marked as a duplicate of this bug. ***

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: Windows (All), x86

Comments on the original bug report:

On 2007-03-06 13:02:23 +0000, Richard Natal wrote:

As you can see at this link: http://xiph.org/vorbis/doc/vorbisfile/ov_open.html
Call ov_open loading it with LoadLibrary using visual C compiler/libraries may fail because of multiples CRT in memory.
The bug is in file dynamic_ogg.c because it calls ov_open.
I've made a small correction in my PC and it works now... the entire file is listed here. See the 2 #ifdef WIN32 blocks to see what was made.
Sorry about my poor english ... An as I'm new to bugzilla and SDL, sorry if I didn't submit the code throw SVN (I've never made this... if someone could teach me...)
[]s
Richard (Bigous)

/*
SDL_mixer: An audio mixer library based on the SDL library
Copyright (C) 1997-2004 Sam Lantinga

This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Library General Public
License as published by the Free Software Foundation; either
version 2 of the License, or (at your option) any later version.

This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
Library General Public License for more details.

You should have received a copy of the GNU Library General Public
License along with this library; if not, write to the Free
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA

Sam Lantinga
[email protected]

*/

#ifdef OGG_MUSIC

#include "SDL/SDL_loadso.h"

#include "dynamic_ogg.h"

vorbis_loader vorbis = {
0, NULL
};

#ifdef OGG_DYNAMIC

#ifdef WIN32
/*

• In Win32, dinamic link vorbis and call ov_open causes access violation is some circunstances.
• It's better explained here: http://xiph.org/vorbis/doc/vorbisfile/ov_open.html
• This is a work arround to make the SDL_mixer work correctly in Windows.
• []s Bigous
  */

static int bigous_fseek64_wrap(FILE *f,ogg_int64_t off,int whence){
if(f==NULL)return(-1);
return fseek(f,(long)off,whence);
}

ov_callbacks bigous_callbacks = {
(size_t (*)(void *, size_t, size_t, void )) fread,
(int ()(void , ogg_int64_t, int)) bigous_fseek64_wrap,
(int ()(void )) fclose,
(long ()(void *)) ftell
};

int bigous_ov_open(FILE *f,OggVorbis_File *vf,char *initial,long ibytes)
{
return vorbis.ov_open_callbacks(f, vf, initial, ibytes, bigous_callbacks);
}

#endif

int Mix_InitOgg()
{
if ( vorbis.loaded == 0 ) {
vorbis.handle = SDL_LoadObject(OGG_DYNAMIC);
if ( vorbis.handle == NULL ) {
return -1;
}
vorbis.ov_clear =
(int (*)(OggVorbis_File *))
SDL_LoadFunction(vorbis.handle, "ov_clear");
if ( vorbis.ov_clear == NULL ) {
SDL_UnloadObject(vorbis.handle);
return -1;
}
vorbis.ov_info =
(vorbis_info ()(OggVorbis_File ,int))
SDL_LoadFunction(vorbis.handle, "ov_info");
if ( vorbis.ov_info == NULL ) {
SDL_UnloadObject(vorbis.handle);
return -1;
}
vorbis.ov_open =
#ifdef WIN32
bigous_ov_open;
#else
(int ()(FILE *,OggVorbis_File *,char ,long))
SDL_LoadFunction(vorbis.handle, "ov_open");
#endif
if ( vorbis.ov_open == NULL ) {
SDL_UnloadObject(vorbis.handle);
return -1;
}
vorbis.ov_open_callbacks =
(int ()(void *, OggVorbis_File *, char , long, ov_callbacks))
SDL_LoadFunction(vorbis.handle, "ov_open_callbacks");
if ( vorbis.ov_open_callbacks == NULL ) {
SDL_UnloadObject(vorbis.handle);
return -1;
}
vorbis.ov_pcm_total =
(ogg_int64_t ()(OggVorbis_File ,int))
SDL_LoadFunction(vorbis.handle, "ov_pcm_total");
if ( vorbis.ov_pcm_total == NULL ) {
SDL_UnloadObject(vorbis.handle);
return -1;
}
vorbis.ov_read =
(long ()(OggVorbis_File *,char *,int, int,int,int,int ))
SDL_LoadFunction(vorbis.handle, "ov_read");
if ( vorbis.ov_read == NULL ) {
SDL_UnloadObject(vorbis.handle);
return -1;
}
vorbis.ov_time_seek =
(int ()(OggVorbis_File *,double))
SDL_LoadFunction(vorbis.handle, "ov_time_seek");
if ( vorbis.ov_time_seek == NULL ) {
SDL_UnloadObject(vorbis.handle);
return -1;
}
}
++vorbis.loaded;

return 0;
}
void Mix_QuitOgg()
{
if ( vorbis.loaded == 0 ) {
return;
}
if ( vorbis.loaded == 1 ) {
SDL_UnloadObject(vorbis.handle);
}
--vorbis.loaded;
}
#else
int Mix_InitOgg()
{
if ( vorbis.loaded == 0 ) {
vorbis.ov_clear = ov_clear;
vorbis.ov_info = ov_info;
vorbis.ov_open = ov_open;
vorbis.ov_open_callbacks = ov_open_callbacks;
vorbis.ov_pcm_total = ov_pcm_total;
vorbis.ov_read = ov_read;
vorbis.ov_time_seek = ov_time_seek;
}
++vorbis.loaded;

return 0;
}
void Mix_QuitOgg()
{
if ( vorbis.loaded == 0 ) {
return;
}
if ( vorbis.loaded == 1 ) {
}
--vorbis.loaded;
}
#endif /* OGG_DYNAMIC */

#endif /* OGG_MUSIC */

On 2007-07-14 21:09:50 +0000, Sam Lantinga wrote:

This is fixed in subversion revision 3275. Thanks!

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: Mac OS Classic, PowerPC

Comments on the original bug report:

On 2006-01-03 12:08:53 +0000, Ryan C. Gordon wrote:

Hello !

On Windows and Linux SDL_mixer works without problems.
When i compile it on Mac OSX SDL_mixers internal MikMod
version produces no sound output.

MIDI, WAVE and others formats work, also libmikmod works.

Is this a known problem ?

iBook G4 1 GHz, Latest OSX Tiger with all Updates.
XCode 2.2

CU

On 2006-01-03 12:09:13 +0000, Ryan C. Gordon wrote:

Ryan C. Gordon wrote:

When i compile it on Mac OSX SDL_mixers internal MikMod version
produces no sound output.

I believe it's been posted before, but I haven't had a chance to
research it at all.

Ryan, I think it has something to do with some interesting code in virtch2.c
;-)

#if defined(macintosh) || defined(APPLE)
#define NO_64BIT_MIXER
#endif
[... snip ...]

#ifdef NO_64BIT_MIXER
/* Uh oh, the 64-bit mixers don't compile...
*/;
#else

The latter essentially translates to "produce no output if the song is long
enough", where 'long enough' is a few milliseconds at 22.5KHz.
We should see how later versions of MikMod handled 64bit ints on Apple
compilers.

-Alex.

On 2006-01-04 02:58:32 +0000, Jon Atkins wrote:

what about using the external libmikmod linkage, which should be later (if if gets updated of course) than the one in SDL_mixer. At least try that option (which is already in SDL_mixer's configure script) to see if a later version does fix the problem.

On 2006-01-04 13:11:55 +0000, Alex Volkov wrote:

Though I don't have MacOSX myself, I've checked the various libmikmod versions (pre- and post- the mentioned change). None of the libmikmod versions ever had such #ifdef code. According to CVS, these #ifdefs were introduced during a port to MacOS (classic?) in virtch2.c rev 1.2.
The next revision (1.3) added the defined(APPLE) to the existing #ifdef, which broke MacOSX:
"Darrell Walisser - Sun Aug 19 00:47:22 PDT 2001

• Fixed compilation problems with mikmod under MacOS"
  -#ifdef macintosh
  +#if defined(macintosh) || defined(APPLE)

I am willing to bet the disabled code will, in fact, compile just fine on MacOSX ;) But someone should try it, of course. Perhaps some better #ifdef checks should be used so that they only apply to MacOS classic.

On 2006-01-19 06:28:23 +0000, Ryan C. Gordon wrote:

Tossing the SDL_mixer bugs to Sam (all three of which might be the same bug in practice)...if you don't want these, toss them back to me.

--ryan.

On 2006-01-27 11:23:04 +0000, Ryan C. Gordon wrote:

Setting Sam as "QA Contact" on all bugs (even resolved ones) so he'll definitely be in the loop to any further discussion here about SDL.

--ryan.

On 2006-04-30 21:16:19 +0000, Sam Lantinga wrote:

Fixed in subversion, thanks!

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Patch to implement desired behavior without breaking current users (sdl-timidity.patch, text/x-patch, 2007-11-18 05:34:40 +0000, 933 bytes)

Reported in version: unspecified
Reported for operating system, platform: Windows (All), x86

Comments on the original bug report:

On 2007-11-18 05:32:54 +0000, wrote:

The default path \TIMIDITY has two problems:

1. if the current drive is D:, and timidity.cfg is in C:\TIMIDITY,
   it won't be found. Relative drive names are almost never a good idea
   when looking for config files.

2. On Wine, the default drive is usually Z:, the whole Linux
   drive. And we can't really put a symlink /timidity -> /etc/timidity
   just for Wine. But we could very easily arrange for e.g.
   C:\Windows\Timidity to point to /etc/timidity.

I'll attach a suggested patch. (Hi Sam!)

On 2007-11-18 05:34:40 +0000, wrote:

Created attachment 236
Patch to implement desired behavior without breaking current users

By the way, see http://bugs.winehq.org/show_bug.cgi?id=10492
for a recipe for reproducing the problem in real life.

On 2007-11-18 05:39:08 +0000, wrote:

I should mention that patch is untested, it's just to show the idea.

On 2008-07-07 08:49:54 +0000, Trygve Vea wrote:

A little advice

Instead of using C:, I'd suggest you fetch the environment variable %SYSTEMDRIVE%. Perhaps fall back on C: if the environment variable (for some reason) does not exist.

It is possible to remap the drives in Windows - a common process on Citrix-solutions. %SYSTEMDRIVE%\timidity\timidity.cfg should work regardless of the letter of the system drive.

Regards, Trygve

On 2009-10-03 02:51:40 +0000, Sam Lantinga wrote:

Hi Dan! :)

This is fixed for the next release. I default Windows to C:\TIMIDITY and added a TIMIDITY_CFG environment variable so you can fully specify the timidity.cfg file.

Thanks!

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: Windows (XP), x86

Comments on the original bug report:

On 2006-08-02 08:22:32 +0000, JeZ+Lee wrote:

SDL_mixer1.2.7 - MP3 playback is unstable on WinXP...

I read the instructions and checked my source code and everything seems to be written ok, but using certain values for "int Mix_OpenAudio(int frequency, Uint16 format, int channels, int chunksize)" produces program lock-ups (crashes).

Example:

Using:

Mix_OpenAudio(MIX_DEFAULT_FREQUENCY, MIX_DEFAULT_FORMAT , MIX_DEFAULT_CHANNELS, 1024)

sometimes crashes on initialization (Mix_OpenAudio) and sometimes crashes on switching current MP3 music playing (Mix_PlayMusic) and sometimes crashes on de-initialization (Mix_CloseAudio).

Changing to:

Mix_OpenAudio(44100, MIX_DEFAULT_FORMAT , MIX_DEFAULT_CHANNELS, 512)

seems to fix the crash problems.

Hope someone can fix these issues and release fixes in SDL_mixer 1.2.8

Jesse "JeZ+Lee" Palser
[email protected]
Silent Hero Productions(R)
http://www.SilentHeroProductions.com/

On 2006-10-03 09:08:41 +0000, Peter Mulholland wrote:

SMPEG is pretty poor. I would suggest using either mpglib (which is now LGPL) or decmpa to support MP3 files.

On 2007-07-14 11:26:35 +0000, Sam Lantinga wrote:

There was a bug in SDL with certain sample rate conversions which might be the cause of this problem. Can you download the SDL 1.2.12 prerelease DLL at http://www.libsdl.org/tmp/SDL.dll and see if that fixes your problem?

If you still get the crash, can you try it with the playmus sample application and see if that also crashes? Either way, can you attach the song that crashes and as much debug information about the actual crash as you can? (stack trace, local variables, etc.)

Thanks!

On 2007-07-14 11:29:23 +0000, Sam Lantinga wrote:

By the way, Peter, mpg123 is in unstable development and doesn't have a clean library API yet. decmpa is based on splay, which is what smpeg uses, but smpeg includes several crash fixes and decoding improvements accumulated over several years of game porting use.

On 2007-07-21 00:42:26 +0000, Sam Lantinga wrote:

I believe this is fixed in SDL_mixer 1.2.8. Please reopen this bug if you're still seeing the problem. Thanks!

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2006-12-19 00:11:35 +0000, Pascal Sclafer wrote:

Version: SDL_mixer-1.2.7 SDL-1.2.11
Distribution: Slackware 11.0

Load a midi file using Mix_LoadMUS_RW().
If timidity.cfg cannot be found, the function returns NULL. That's right.
But after that, Mix_GetError() returns an empty string. It should return a more explicit message...

If you use Mis_LoadMUS() instead of Mix_LoadMUS_RW(), then Mix_GetError() returns the expected message. The bug is only present when you use Mix_LoadMUS_RW().

That can be illustrated using playmus:

pascal@portable_pascal:/# playmus /tmp/test.mid
Opened audio at 22050 Hz 16 bit stereo (LE), 4096 bytes audio buffer
Couldn't load /tmp/test.mid: /etc/timidity/timidity.cfg: No such file or directory

pascal@portable_pascal:/# playmus -rwops /tmp/test.mid
Opened audio at 22050 Hz 16 bit stereo (LE), 4096 bytes audio buffer
Couldn't load /tmp/test.mid:

In the second example, an emty string is returned instead of the right error message.

P.S: Sorry for my bad english.

On 2006-12-19 14:43:05 +0000, Patrice Mandin wrote:

Fixed in svn, revision 2927

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: Mac OS X (All), PowerPC

Comments on the original bug report:

On 2006-07-10 19:34:12 +0000, Peter Mulholland wrote:

I noticed by examining the resulting libSDL_mixer.dylib with otool -L, even when built with dynamic loading of OGG Vorbis, that the library binaryu still specifies dependancies on libogg, libvorbis and libvorbisfile.

Surely this defeats the point of loading these libs at run time? This would be a great bonus on OS X as it would avoid having to use install_name_tool when setting up your app bundle with the dylibs included, due to Apple's stupidity in hard-coding lib paths into the binaries!

I build SDL_mixer using the gcc-fat.sh script as the compiler. Could this be related? It doesn't seem so to me, it seems more like a ./configure issue

On 2007-02-12 21:11:33 +0000, Ryan C. Gordon wrote:

Dynamic loading was forcibly disabled in the configure script on Mac OS X...so it wasn't that it was loading it at runtime and also explicitly linking against it, it's that it was ONLY linking explicitly against it.

I've corrected this in Subversion now, for both Ogg Vorbis and SMPEG.

Fixed in svn revision # 2959.

--ryan.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: Windows (XP), x86

Comments on the original bug report:

On 2006-06-24 19:43:09 +0000, joda.bot wrote:

hi

OS: Windows 2000
Soundcard: SB Live Value with 4 Channels

The MP3 playback (using SMPEG) is too fast when using more than 2 sound channels on windows. I don't hear any surround sound with SDL release 1.2.10. There might be some bugs in the code calling SDL.

I'm using SDL_mixer 1.2.7 with SDL 1.2.10. There was a problem compiling SDL_mixer against SDL 1.2.10 (using MinGW).

Compile time error: already defined int8_t when SDL_mixer includes <stdint.h>.

Orignal code:
#else
typedef signed char int8_t;
typedef unsigned char uint8_t;
typedef signed short int16_t;
typedef unsigned short uint16_t;
typedef signed int int32_t;
typedef unsigned int uint32_t;
typedef signed long long int64_t;
typedef unsigned long long uint64_t;
#ifndef SIZE_T_DEFINED
#define SIZE_T_DEFINED
typedef unsigned int size_t;
#endif
typedef unsigned int uintptr_t;
#endif /* _MSC_VER */

Fix: Just include <stdint.h>
#else
#include <stdint.h>
#ifndef SIZE_T_DEFINED
#define SIZE_T_DEFINED
typedef unsigned int size_t;
#endif
#endif /* _MSC_VER */

Perhaps you can spot an error in the code:
https://svn.sourceforge.net/svnroot/armagetronad/armagetronad/branches/0.3.0/armagetronad/src/engine/sound/sdl_mixer/

The code was not written by me, but one of my fellow Armagetron Advanced developers.

Download Alpha Test Canditate:
http://beta.armagetronad.net/fetch.php/0.3%252F20060624%252Farmagetronad-0.3.0_alpha5009.win32.exe

Steps:

1. Set System Settings->Sound->Channels to 4 or 6
2. Restart game to activate 4 or 6 channel sound
3. Set System Settings->Sound->Custom Playlist: [path to some .m3u list]
   Note: The .m3u has to be outside the game directory and should contain an mp3.
4. Set System Settings->Sound->Use Playlist: Custom
5. Restart game to activate 4 or 6 channel sound
6. Bind "next track" in System Settings->Misc Settings->Global Keybindings
   "next track" to some key
7. Start a local game: Game->Local Game
8. press next track

Note: The last time I tried to start it with the "waveout" driver the game just crashed with 4 channels, so you probably need dsound driver (or even 4 channels).

Hope you can help out. I noticed that you applied some fixes to SVN. Are some of the problems already fixed ?

On 2006-06-25 13:18:49 +0000, Sam Lantinga wrote:

The compiling bug is fixed in subversion, thanks!

SMPEG doesn't support 4/6 channel sound, you'd have to write a patch for that and send it to [email protected].

I don't have a surround sound setup, so I can't really test any of the surround sound code myself.

On 2006-06-26 02:48:37 +0000, joda.bot wrote:

A simple patch already exists.
See ftp://ling.lll.hawaii.edu/pub/greg/Surround-SDL.tgz aka Bug 96 :)

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 1.2.8
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2008-02-13 06:50:15 +0000, Alex wrote:

I don't know if this is a bug or feature, but IMO it would be much more sensible for it to call the hook function. Mix_HaltChannel does call callback functions, so there's confusing difference in behavior.

On 2008-02-18 03:13:33 +0000, Alex wrote:

Sorry, accidentally created duplicates.

*** This bug has been marked as a duplicate of bug 549 ***

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• test file (level2.mid, application/octet-stream, 2006-01-31 02:43:38 +0000, 31157 bytes)

Reported in version: unspecified
Reported for operating system, platform: OpenBSD, x86

Comments on the original bug report:

On 2006-01-31 02:42:07 +0000, Jolan Luff wrote:

when playing a certain midi file, i always get a crash:

$ gdb playmus
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-openbsd3.9"...
(gdb) set args level2.mid
(gdb) run
Starting program: /usr/local/bin/playmus level2.mid
Opened audio at 22050 Hz 16 bit stereo, 4096 bytes audio buffer
Playing level2.mid

Program received signal SIGSEGV, Segmentation fault.
[Switching to process 29597, thread 0x7ddd7000]
0x0be2ab93 in pre_resample (sp=0x7f52d200) at resample.c:723
723 v1 = *(vptr - 1);
(gdb) bt

0 0x0be2ab93 in pre_resample (sp=0x7f52d200) at resample.c:723

1 0x0be1de54 in load_instrument (name=0x81f61400 "gsdrum00/congalo",

font_type=0, percussion=1, panning=-1, amp=-1, cfg_tuning=0, 
note_to_use=64, strip_loop=1, strip_envelope=1, strip_tail=-1, bank=0, 
gm_num=192, sf_ix=0) at instrum.c:827

2 0x0be1e2c3 in fill_bank (dr=1, b=0) at instrum.c:900

3 0x0be1e5ba in load_missing_instruments () at instrum.c:990

4 0x0be26ed4 in Timidity_Start (song=0x86df29e0) at playmidi.c:1729

5 0x0be12bd0 in music_internal_play (music=0x81f615c0, position=0)

at music.c:741

6 0x0be12d93 in Mix_FadeInMusicPos (music=0x81f615c0, loops=0, ms=2000,

position=0) at music.c:811

7 0x0be12ddc in Mix_FadeInMusic (music=0x81f615c0, loops=0, ms=2000)

at music.c:818

8 0x1c00137f in main (argc=2, argv=0xcfbe7810) at playmus.c:192

On 2006-01-31 02:43:38 +0000, Jolan Luff wrote:

Created attachment 56
test file

On 2006-01-31 02:51:14 +0000, Jolan Luff wrote:

BTW, if I use timidity++ 2.13.2 standalone the file plays OK.

On 2006-05-01 06:48:12 +0000, Sam Lantinga wrote:

I don't have the same patch set as you, apparently. Can you post a link to your timidity.cfg and your instrument set (including gsdrum00/congalo)

On 2006-05-01 11:49:47 +0000, Jolan Luff wrote:

here you go:

http://protection.cx/~jolan/tmp/timiditystuff.tar.gz

On 2006-05-07 13:30:07 +0000, Sam Lantinga wrote:

I can't reproduce this in the code from CVS, is it fixed?
http://www.libsdl.org/tmp/SDL_mixer-1.2.7.tar.gz

On 2006-05-08 11:31:14 +0000, Jolan Luff wrote:

No, it crashes in the same exact place with the code from the 1.2.7 tarball:

Starting program: /usr/obj/ports/sdl-mixer-1.2.7/SDL_mixer-1.2.7/build/playmus ~/level2.mid
Opened audio at 22050 Hz 16 bit stereo (LE), 4096 bytes audio buffer
Playing /usr/home/jolan/level2.mid

Program received signal SIGSEGV, Segmentation fault.
[Switching to process 32757, thread 0x7c586000]
0x1c034b33 in pre_resample (sp=0x80526200) at timidity/resample.c:723
723 v1 = *(vptr - 1);
(gdb) bt

0 0x1c034b33 in pre_resample (sp=0x80526200) at timidity/resample.c:723

1 0x1c030e51 in load_instrument (name=0x836f7400 "gsdrum00/congalo",

font_type=0, percussion=1, panning=-1, amp=-1, cfg_tuning=0, 
note_to_use=64, strip_loop=1, strip_envelope=1, strip_tail=-1, bank=0, 
gm_num=192, sf_ix=0) at timidity/instrum.c:834

2 0x1c03128a in fill_bank (dr=1, b=0) at timidity/instrum.c:907

3 0x1c031512 in load_missing_instruments () at timidity/instrum.c:997

4 0x1c019950 in Timidity_Start (song=0x7f366a00) at timidity/playmidi.c:1754

5 0x1c00614e in music_internal_play (music=0x836f7600, position=0)

at music.c:768

6 0x1c0062f1 in Mix_FadeInMusicPos (music=0x836f7600, loops=0, ms=2000,

position=0) at music.c:838

7 0x1c00632a in Mix_FadeInMusic (music=0x836f7600, loops=0, ms=2000)

at music.c:845

8 0x1c002620 in main (argc=2, argv=0xcf7f326c) at playmus.c:203

On 2006-05-09 04:16:31 +0000, Sam Lantinga wrote:

Could this be an optimizer bug? I just tested this again, with ElectricFence to catch memory overwrites, and I confirmed that it's loading that instrument and resampling it with no problems here. I'm running on Linux with gcc 4.0.

On 2006-06-25 16:16:18 +0000, Ryan C. Gordon wrote:

Can't reproduce here, too, and valgrind doesn't complain either.

--ryan.

On 2006-10-17 13:58:34 +0000, Mike Swanson wrote:

I'm having the same problem on OpenBSD 3.9. SDL_mixer always crashes on certain levels of DOOM (previously posted MIDI is exactly the same as E2M1). It happens on DOOM 2 MAP02 and Ultimate DOOM E2M1, at least; I haven't done extensive testing of all the levels, but I know that Ultimate E1 and E3 are completely okay (also meaning you can't reproduce with only the shareware IWAD). Happens in Chocolate Doom and PrBoom, at least (I'm not going to try all the source ports)

On 2006-10-17 14:09:44 +0000, Jolan Luff wrote:

I don't think this is an optimizer bug since this happens on multiple OpenBSD architectures (amd64, arm, i386, powerpc). It's my understanding that gcc optimizations are platform specific.

OpenBSD does have a rather zealous malloc which will crash even in the event of a reading one byte too much, maybe this is the problem?

I'd be willing to provide a login to an OpenBSD machine if needed.

On 2007-07-14 15:10:26 +0000, Sam Lantinga wrote:

Okay, I was finally able to reproduce this on OpenBSD 4.1. I'm looking into it now.

On 2007-07-14 16:47:34 +0000, Sam Lantinga wrote:

This is fixed with subversion revision 3267.

Hooray for paranoid operating systems! This was a long standing memory corruption problem in the timidity code. :)

On 2007-07-14 18:07:36 +0000, Jolan Luff wrote:

Great, thank you very much!

On 2007-07-14 18:53:03 +0000, Sam Lantinga wrote:

You're welcome! :)

On 2007-07-15 03:21:34 +0000, Ryan C. Gordon wrote:

Are we sending that Timidity patch upstream? I'm not sure who maintains Timidity at this point...

--ryan.

On 2007-07-15 07:08:44 +0000, Sam Lantinga wrote:

No, the version of timidity we use is no longer being maintained.

On 2007-07-15 08:04:23 +0000, Ryan C. Gordon wrote:

Argh, I just went to apply this fix to the Timidity in SDL_sound and found this:

http://svn.icculus.org/SDL_sound/branches/stable-1.0/decoders/timidity/resample.c?r1=204&r2=259&p1=trunk/decoders/timidity/resample.c&p2=trunk/decoders/timidity/resample.c

  vptr = src + (ofs >> FRACTION_BITS);
      /*
       * Electric Fence to the rescue: Accessing *(vptr - 1) is not a
       * good thing to do when vptr <= src. (TiMidity++ has a similar
       * safe-guard here.)
       */
  v1 = (vptr > src) ? *(vptr - 1) : 0;

Apparently I fixed this exact bug about 5 years ago. I'm really sorry this got left open so long in Bugzilla (and that I never backported the fix to SDL_mixer in the first place).

Sorry about that. :/

--ryan.

On 2007-07-15 08:24:06 +0000, Sam Lantinga wrote:

Hah. SDL_mixer's fix is probably a little better since it doesn't distort the first sample.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2006-02-02 01:57:13 +0000, Sam Lantinga wrote:

Update the version of libmikmod used in SDL_mixer

On 2009-10-03 01:43:49 +0000, Sam Lantinga wrote:

Updated to version 3.1.12 in revision 4915

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2006-08-07 11:35:55 +0000, Facundo Dominguez wrote:

Hello:
I call Mix_OpenAudio.
Then call Mix_ColseAudio().
Then call Mix_OpenAudio again (then it crashes).

This is with last versions of SDL (1.2.11) and SDL_mixer (1.2.7) on linux Fedora Core 4 and Windows.
I recompile SDL_mixer without midi support and then the program ran ok.

I give you here both the program and the memory report of valgrind (Line 133 of main is the second call to Mix_OpenAudio).

This bug may have something to do with bug 274.

=========== Crashing PROGRAM ===============

int main(){

// up SDL
if (SDL_Init(SDL_INIT_VIDEO | SDL_INIT_AUDIO | SDL_INIT_NOPARACHUTE) != 0) {
cerr<<"Unable to initialize SDL: "<<SDL_GetError()<<"\n";
exit(1);
}
SDL_EnableUNICODE(1);

// up the video
SDL_Surface * screen = SDL_SetVideoMode(640, 480, 8, SDL_HWSURFACE | SDL_DOUBLEBUF);
if (screen == NULL) {
fprintf(stderr,"Unable to set video mode: %s\n", SDL_GetError());
exit(1);
}

// up the audio
if (Mix_OpenAudio(MIX_DEFAULT_FREQUENCY, MIX_DEFAULT_FORMAT, MIX_DEFAULT_CHANNELS,int(pow(2,9)))) {
cleanUp(VIDEO);
cerr<<"Could not initialize audio system: "<<Mix_GetError()<<"\n";
exit(1);
};
Mix_CloseAudio();
if (SDL_Init(SDL_INIT_VIDEO | SDL_INIT_AUDIO | SDL_INIT_NOPARACHUTE) != 0) {
cerr<<"Unable to initialize SDL: "<<SDL_GetError()<<"\n";
exit(1);
}
if (Mix_OpenAudio(MIX_DEFAULT_FREQUENCY, MIX_DEFAULT_FORMAT, MIX_DEFAULT_CHANNELS,int(pow(2,9)))) {
cleanUp(VIDEO);
cerr<<"Could not initialize audio system: "<<Mix_GetError()<<"\n";
exit(1);
};

return 0;
}

==18245== Memcheck, a memory error detector for x86-linux.
==18245== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==18245== Using valgrind-2.4.0, a program supervision framework for x86-linux.
==18245== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==18245== For more details, rerun with: -v
==18245==
==18245== Invalid read of size 4
==18245== at 0xD6FE69: open_file (in /usr/lib/libSDL_mixer-1.2.so.0.2.5)
==18245== by 0xD80EEC: read_config_file (in /usr/lib/libSDL_mixer-1.2.so.0.2.5)
==18245== by 0xD81F91: Timidity_Init (in /usr/lib/libSDL_mixer-1.2.so.0.2.5)
==18245== by 0xD4C594: open_music (in /usr/lib/libSDL_mixer-1.2.so.0.2.5)
==18245== by 0xD4986C: Mix_OpenAudio (in /usr/lib/libSDL_mixer-1.2.so.0.2.5)
==18245== by 0x804EBE2: main (sjsound.cpp:133)
==18245== Address 0x1BBACE10 is 0 bytes inside a block of size 8 free'd
==18245== at 0x1B909743: free (vg_replace_malloc.c:152)
==18245== by 0xD70228: free_pathlist (in /usr/lib/libSDL_mixer-1.2.so.0.2.5)
==18245== by 0xD7CDDB: Timidity_Close (in /usr/lib/libSDL_mixer-1.2.so.0.2.5)==18245== by 0xD4DBEA: close_music (in /usr/lib/libSDL_mixer-1.2.so.0.2.5)
==18245== by 0xD4B1EE: Mix_CloseAudio (in /usr/lib/libSDL_mixer-1.2.so.0.2.5)==18245== by 0x804EB66: main (sjsound.cpp:128)
==18245==
==18245== Invalid read of size 1
==18245== at 0xD6FE79: open_file (in /usr/lib/libSDL_mixer-1.2.so.0.2.5)
==18245== by 0xD80EEC: read_config_file (in /usr/lib/libSDL_mixer-1.2.so.0.2.5)
==18245== by 0xD81F91: Timidity_Init (in /usr/lib/libSDL_mixer-1.2.so.0.2.5)
==18245== by 0xD4C594: open_music (in /usr/lib/libSDL_mixer-1.2.so.0.2.5)
==18245== by 0xD4986C: Mix_OpenAudio (in /usr/lib/libSDL_mixer-1.2.so.0.2.5)
==18245== by 0x804EBE2: main (sjsound.cpp:133)
==18245== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==18245==
==18245== Process terminating with default action of signal 11 (SIGSEGV)
==18245== Access not within mapped region at address 0x0
==18245== at 0xD6FE79: open_file (in /usr/lib/libSDL_mixer-1.2.so.0.2.5)
==18245== by 0xD80EEC: read_config_file (in /usr/lib/libSDL_mixer-1.2.so.0.2.5)
==18245== by 0xD81F91: Timidity_Init (in /usr/lib/libSDL_mixer-1.2.so.0.2.5)
==18245== by 0xD4C594: open_music (in /usr/lib/libSDL_mixer-1.2.so.0.2.5)
==18245== by 0xD4986C: Mix_OpenAudio (in /usr/lib/libSDL_mixer-1.2.so.0.2.5)
==18245== by 0x804EBE2: main (sjsound.cpp:133)
==18245==
==18245== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 64 from 3)
==18245== malloc/free: in use at exit: 1371611 bytes in 2920 blocks.
==18245== malloc/free: 8081 allocs, 5161 frees, 1592297 bytes allocated.
==18245== For counts of detected errors, rerun with: -v
==18245== searching for pointers to 2920 not-freed blocks.
==18245== checked 12428256 bytes.

On 2006-11-28 14:20:37 +0000, Patrice Mandin wrote:

*** This bug has been marked as a duplicate of 274 ***

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2006-07-01 01:34:26 +0000, David Rose wrote:

This patch adds optional support for libmad, to be selected at configure time. If the user selects --disable-music-mp3 and --enable-music-mp3-mad, then the use of the smpeg library will be disabled, while the libmad library will be configured in its place for mp3 playback. (It is also possible to configure both of them on in one build, in which case smpeg will be chosen most of the time at runtime, unless you name a file with the .mad extension.)

The patch is built against SDL_mixer-1.2.7.

libmad is particularly useful for embedded devices, which might not have hardware floating-point support. On such devices, smpeg is not usable as an mp3 library, whereas libmad performs quite nicely. Even on the PC, libmad seems to run slightly faster than smpeg in my test cases.

As Ryan Gordon pointed out on the mailing list, libmad is GPL rather than LGPL, which means that an end-user who enables libmad must be prepared to release his application under a GPL-compatible license. This is a good reason to have libmad support off by default. However, this issue does not impact SDL or SDL_mixer itself, which do not themselves incorporate libmad; it only affects users who decide to enable this feature and build a version of SDL_mixer that does incorporate libmad.

The patch is pasted into this bug report below. In case the web form damages it, it is also available at the above URL.

Thanks!
David Rose

[email protected]

Index: README

RCS file: /cvs/SDL_mixer/README,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- README 29 Jun 2006 06:06:41 -0000 1.1.1.1
+++ README 29 Jun 2006 06:09:05 -0000 1.2
@@ -7,7 +7,7 @@
Due to popular demand, here is a simple multi-channel audio mixer.
It supports 8 channels of 16 bit stereo audio, plus a single channel
of music, mixed by the popular MikMod MOD, Timidity MIDI and SMPEG MP3
-libraries.
+(or libmad MP3) libraries.

See the header file SDL_mixer.h and the examples playwave.c and playmus.c
for documentation on this mixer library.
@@ -16,7 +16,8 @@
files as audio samples, and can load MIDI files via Timidity and the
following music formats via MikMod: .MOD .S3M .IT .XM. It can load
Ogg Vorbis streams as music if built with the Ogg Vorbis libraries,
-and finally it can load MP3 music using the SMPEG library.
+and finally it can load MP3 music using either the SMPEG or the libmad
+libraries.

The process of mixing MIDI files to wave output is very CPU intensive,
so if playing regular WAVE files sound great, but playing MIDI files
Index: SDL_mixer.h

RCS file: /cvs/SDL_mixer/SDL_mixer.h,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- SDL_mixer.h 29 Jun 2006 06:06:41 -0000 1.1.1.1
+++ SDL_mixer.h 29 Jun 2006 06:09:05 -0000 1.2
@@ -20,7 +20,7 @@
[email protected]
*/

-/* $Id: SDL_mixer.h,v 1.1.1.1 2006/06/29 06:06:41 drose Exp $ /
+/ $Id: SDL_mixer.h,v 1.2 2006/06/29 06:09:05 drose Exp $ */

#ifndef _SDL_MIXER_H
#define _SDL_MIXER_H
@@ -103,7 +103,8 @@
MUS_MOD,
MUS_MID,
MUS_OGG,

• MUS_MP3

• MUS_MP3,
• MUS_MP3_MAD
  } Mix_MusicType;

/* The internal format for a music chunk interpreted via mikmod */
Index: SDL_mixer.spec

RCS file: /cvs/SDL_mixer/SDL_mixer.spec,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- SDL_mixer.spec 29 Jun 2006 06:06:41 -0000 1.1.1.1
+++ SDL_mixer.spec 29 Jun 2006 06:09:05 -0000 1.2
@@ -16,7 +16,7 @@
Due to popular demand, here is a simple multi-channel audio mixer.
It supports 4 channels of 16 bit stereo audio, plus a single channel
of music, mixed by the popular MikMod MOD, Timidity MIDI and SMPEG MP3
-libraries.
+(or libmad MP3) libraries.

%package devel
Summary: Libraries, includes and more to develop SDL applications.
@@ -27,7 +27,7 @@
Due to popular demand, here is a simple multi-channel audio mixer.
It supports 4 channels of 16 bit stereo audio, plus a single channel
of music, mixed by the popular MikMod MOD, Timidity MIDI and SMPEG MP3
-libraries.
+(or libmad MP3) libraries.

%prep
%setup
Index: SDL_mixer.spec.in

RCS file: /cvs/SDL_mixer/SDL_mixer.spec.in,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- SDL_mixer.spec.in 29 Jun 2006 06:06:07 -0000 1.1.1.1
+++ SDL_mixer.spec.in 29 Jun 2006 06:09:05 -0000 1.2
@@ -16,7 +16,7 @@
Due to popular demand, here is a simple multi-channel audio mixer.
It supports 4 channels of 16 bit stereo audio, plus a single channel
of music, mixed by the popular MikMod MOD, Timidity MIDI and SMPEG MP3
-libraries.
+(or libmad MP3) libraries.

%package devel
Summary: Libraries, includes and more to develop SDL applications.
@@ -27,7 +27,7 @@
Due to popular demand, here is a simple multi-channel audio mixer.
It supports 4 channels of 16 bit stereo audio, plus a single channel
of music, mixed by the popular MikMod MOD, Timidity MIDI and SMPEG MP3
-libraries.
+(or libmad MP3) libraries.

%prep
%setup
Index: configure

RCS file: /cvs/SDL_mixer/configure,v
retrieving revision 1.1.1.1
retrieving revision 1.3
diff -u -r1.1.1.1 -r1.3
--- configure 29 Jun 2006 06:06:41 -0000 1.1.1.1
+++ configure 1 Jul 2006 05:16:29 -0000 1.3
@@ -1047,6 +1047,7 @@
--disable-smpegtest Do not try to compile and run a test SMPEG program
--enable-music-mp3-shared
dynamically load MP3 support [default=yes]

• --enable-music-mp3-mad enable MP3 music via libmad [default=no]

Optional Packages:
--with-PACKAGE[=ARG] use PACKAGE [ARG=yes]
@@ -3155,7 +3156,7 @@
;;
--irix6*)

Find out which ABI we are using.

• echo '#line 3158 "configure"' > conftest.$ac_ext

• echo '#line 3159 "configure"' > conftest.$ac_ext
  if { (eval echo "$as_me:$LINENO: "$ac_compile"") >&5
  (eval $ac_compile) 2>&5
  ac_status=$?
  @@ -4887,7 +4888,7 @@

Provide some information about the compiler.

-echo "$as_me:4890:"
+echo "$as_me:4891:"
"checking for Fortran 77 compiler version" >&5
ac_compiler=set X $ac_compile; echo $2
{ (eval echo "$as_me:$LINENO: "$ac_compiler --version </dev/null >&5"") >&5
@@ -5960,11 +5961,11 @@
-e 's:.*FLAGS}{0,1} :&$lt_compiler_flag :; t'
-e 's: [^ ]*conftest.: $lt_compiler_flag&:; t'
-e 's:$: $lt_compiler_flag:'`

• (eval echo ""$as_me:5963: $lt_compile"" >&5)

• (eval echo ""$as_me:5964: $lt_compile"" >&5)
  (eval "$lt_compile" 2>conftest.err)
  ac_status=$?
  cat conftest.err >&5

• echo "$as_me:5967: $? = $ac_status" >&5

• echo "$as_me:5968: $? = $ac_status" >&5
  if (exit $ac_status) && test -s "$ac_outfile"; then

  The compiler can only warn and ignore the option if not recognized

  So say no if there are warnings other than the usual output.

@@ -6228,11 +6229,11 @@
-e 's:.*FLAGS}{0,1} :&$lt_compiler_flag :; t'
-e 's: [^ ]*conftest.: $lt_compiler_flag&:; t'
-e 's:$: $lt_compiler_flag:'`

• (eval echo ""$as_me:6231: $lt_compile"" >&5)

• (eval echo ""$as_me:6232: $lt_compile"" >&5)
  (eval "$lt_compile" 2>conftest.err)
  ac_status=$?
  cat conftest.err >&5

• echo "$as_me:6235: $? = $ac_status" >&5

• echo "$as_me:6236: $? = $ac_status" >&5
  if (exit $ac_status) && test -s "$ac_outfile"; then

  The compiler can only warn and ignore the option if not recognized

  So say no if there are warnings other than the usual output.

@@ -6332,11 +6333,11 @@
-e 's:.*FLAGS}{0,1} :&$lt_compiler_flag :; t'
-e 's: [^ ]*conftest.: $lt_compiler_flag&:; t'
-e 's:$: $lt_compiler_flag:'`

• (eval echo ""$as_me:6335: $lt_compile"" >&5)

• (eval echo ""$as_me:6336: $lt_compile"" >&5)
  (eval "$lt_compile" 2>out/conftest.err)
  ac_status=$?
  cat out/conftest.err >&5

• echo "$as_me:6339: $? = $ac_status" >&5

• echo "$as_me:6340: $? = $ac_status" >&5
  if (exit $ac_status) && test -s out/conftest2.$ac_objext
  then

  The compiler can only warn and ignore the option if not recognized

@@ -8679,7 +8680,7 @@
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat > conftest.$ac_ext <<EOF
-#line 8682 "configure"
+#line 8683 "configure"
#include "confdefs.h"

#if HAVE_DLFCN_H
@@ -8779,7 +8780,7 @@
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat > conftest.$ac_ext <<EOF
-#line 8782 "configure"
+#line 8783 "configure"
#include "confdefs.h"

#if HAVE_DLFCN_H
@@ -11123,11 +11124,11 @@
-e 's:.*FLAGS}{0,1} :&$lt_compiler_flag :; t'
-e 's: [^ ]*conftest.: $lt_compiler_flag&:; t'
-e 's:$: $lt_compiler_flag:'`

• (eval echo ""$as_me:11126: $lt_compile"" >&5)

• (eval echo ""$as_me:11127: $lt_compile"" >&5)
  (eval "$lt_compile" 2>conftest.err)
  ac_status=$?
  cat conftest.err >&5

• echo "$as_me:11130: $? = $ac_status" >&5

• echo "$as_me:11131: $? = $ac_status" >&5
  if (exit $ac_status) && test -s "$ac_outfile"; then

  The compiler can only warn and ignore the option if not recognized

  So say no if there are warnings other than the usual output.

@@ -11227,11 +11228,11 @@
-e 's:.*FLAGS}{0,1} :&$lt_compiler_flag :; t'
-e 's: [^ ]*conftest.: $lt_compiler_flag&:; t'
-e 's:$: $lt_compiler_flag:'`

• (eval echo ""$as_me:11230: $lt_compile"" >&5)

• (eval echo ""$as_me:11231: $lt_compile"" >&5)
  (eval "$lt_compile" 2>out/conftest.err)
  ac_status=$?
  cat out/conftest.err >&5

• echo "$as_me:11234: $? = $ac_status" >&5

• echo "$as_me:11235: $? = $ac_status" >&5
  if (exit $ac_status) && test -s out/conftest2.$ac_objext
  then

  The compiler can only warn and ignore the option if not recognized

@@ -12799,11 +12800,11 @@
-e 's:.*FLAGS}{0,1} :&$lt_compiler_flag :; t'
-e 's: [^ ]*conftest.: $lt_compiler_flag&:; t'
-e 's:$: $lt_compiler_flag:'`

• (eval echo ""$as_me:12802: $lt_compile"" >&5)

• (eval echo ""$as_me:12803: $lt_compile"" >&5)
  (eval "$lt_compile" 2>conftest.err)
  ac_status=$?
  cat conftest.err >&5

• echo "$as_me:12806: $? = $ac_status" >&5

• echo "$as_me:12807: $? = $ac_status" >&5
  if (exit $ac_status) && test -s "$ac_outfile"; then

  The compiler can only warn and ignore the option if not recognized

  So say no if there are warnings other than the usual output.

@@ -12903,11 +12904,11 @@
-e 's:.*FLAGS}{0,1} :&$lt_compiler_flag :; t'
-e 's: [^ ]*conftest.: $lt_compiler_flag&:; t'
-e 's:$: $lt_compiler_flag:'`

• (eval echo ""$as_me:12906: $lt_compile"" >&5)

• (eval echo ""$as_me:12907: $lt_compile"" >&5)
  (eval "$lt_compile" 2>out/conftest.err)
  ac_status=$?
  cat out/conftest.err >&5

• echo "$as_me:12910: $? = $ac_status" >&5

• echo "$as_me:12911: $? = $ac_status" >&5
  if (exit $ac_status) && test -s out/conftest2.$ac_objext
  then

  The compiler can only warn and ignore the option if not recognized

@@ -15112,11 +15113,11 @@
-e 's:.*FLAGS}{0,1} :&$lt_compiler_flag :; t'
-e 's: [^ ]*conftest.: $lt_compiler_flag&:; t'
-e 's:$: $lt_compiler_flag:'`

• (eval echo ""$as_me:15115: $lt_compile"" >&5)

• (eval echo ""$as_me:15116: $lt_compile"" >&5)
  (eval "$lt_compile" 2>conftest.err)
  ac_status=$?
  cat conftest.err >&5

• echo "$as_me:15119: $? = $ac_status" >&5

• echo "$as_me:15120: $? = $ac_status" >&5
  if (exit $ac_status) && test -s "$ac_outfile"; then

  The compiler can only warn and ignore the option if not recognized

  So say no if there are warnings other than the usual output.

@@ -15380,11 +15381,11 @@
-e 's:.*FLAGS}{0,1} :&$lt_compiler_flag :; t'
-e 's: [^ ]*conftest.: $lt_compiler_flag&:; t'
-e 's:$: $lt_compiler_flag:'`

• (eval echo ""$as_me:15383: $lt_compile"" >&5)

• (eval echo ""$as_me:15384: $lt_compile"" >&5)
  (eval "$lt_compile" 2>conftest.err)
  ac_status=$?
  cat conftest.err >&5

• echo "$as_me:15387: $? = $ac_status" >&5

• echo "$as_me:15388: $? = $ac_status" >&5
  if (exit $ac_status) && test -s "$ac_outfile"; then

  The compiler can only warn and ignore the option if not recognized

  So say no if there are warnings other than the usual output.

@@ -15484,11 +15485,11 @@
-e 's:.*FLAGS}{0,1} :&$lt_compiler_flag :; t'
-e 's: [^ ]*conftest.: $lt_compiler_flag&:; t'
-e 's:$: $lt_compiler_flag:'`

• (eval echo ""$as_me:15487: $lt_compile"" >&5)

• (eval echo ""$as_me:15488: $lt_compile"" >&5)
  (eval "$lt_compile" 2>out/conftest.err)
  ac_status=$?
  cat out/conftest.err >&5

• echo "$as_me:15491: $? = $ac_status" >&5

• echo "$as_me:15492: $? = $ac_status" >&5
  if (exit $ac_status) && test -s out/conftest2.$ac_objext
  then

  The compiler can only warn and ignore the option if not recognized

@@ -20408,6 +20409,74 @@
fi
fi
fi
+# Check whether --enable-music-mp3-mad or --disable-music-mp3-mad was given.
+if test "${enable_music_mp3_mad+set}" = set; then

• enableval="$enable_music_mp3_mad"

+else

• enable_music_mp3_mad=no
  +fi;
  +if test x$enable_music_mp3_mad = xyes; then
• echo "$as_me:$LINENO: checking for libmad headers" >&5
  +echo $ECHO_N "checking for libmad headers... $ECHO_C" >&6
• have_libmad=no
• cat >conftest.$ac_ext <<_ACEOF
  +/* confdefs.h. /
  +_ACEOF
  +cat confdefs.h >>conftest.$ac_ext
  +cat >>conftest.$ac_ext <<_ACEOF
  +/ end confdefs.h. */

• #include "mad.h"
  

+int
+main ()
+{
+
+

• ;
• return 0;
  +}
  +_ACEOF
  +rm -f conftest.$ac_objext
  +if { (eval echo "$as_me:$LINENO: "$ac_compile"") >&5
• (eval $ac_compile) 2>conftest.er1
• ac_status=$?
• grep -v '^ *+' conftest.er1 >conftest.err
• rm -f conftest.er1
• cat conftest.err >&5
• echo "$as_me:$LINENO: $? = $ac_status" >&5
• (exit $ac_status); } &&
• { ac_try='test -z "$ac_c_werror_flag"

• 	 || test ! -s conftest.err'
  

• { (eval echo "$as_me:$LINENO: "$ac_try"") >&5
• (eval $ac_try) 2>&5
• ac_status=$?
• echo "$as_me:$LINENO: $? = $ac_status" >&5
• (exit $ac_status); }; } &&
• { ac_try='test -s conftest.$ac_objext'
• { (eval echo "$as_me:$LINENO: "$ac_try"") >&5
• (eval $ac_try) 2>&5
• ac_status=$?
• echo "$as_me:$LINENO: $? = $ac_status" >&5
• (exit $ac_status); }; }; then
• have_libmad=yes

+else

• echo "$as_me: failed program was:" >&5
  +sed 's/^/| /' conftest.$ac_ext >&5

+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext

• echo "$as_me:$LINENO: result: $have_libmad" >&5
  +echo "${ECHO_T}$have_libmad" >&6
• if test x$have_libmad = xyes; then

•    SOURCES="$SOURCES $srcdir/mp3_mad.c"
  

•    EXTRA_CFLAGS="$EXTRA_CFLAGS -DMP3_MAD_MUSIC"
  

•    EXTRA_LDFLAGS="$EXTRA_LDFLAGS -lmad"
  

• fi
  +fi

OBJECTS=echo $SOURCES | sed 's,[^ ]*/\([^ ]*\)\.c,$(objects)/\1.lo,g'

Index: configure.in

RCS file: /cvs/SDL_mixer/configure.in,v
retrieving revision 1.1.1.1
retrieving revision 1.3
diff -u -r1.1.1.1 -r1.3
--- configure.in 29 Jun 2006 06:06:07 -0000 1.1.1.1
+++ configure.in 1 Jul 2006 05:14:21 -0000 1.3
@@ -292,6 +292,25 @@
fi
fi
fi
+AC_ARG_ENABLE(music-mp3-mad,
+[ --enable-music-mp3-mad enable MP3 music via libmad [[default=no]]],

•          , enable_music_mp3_mad=no)
  

+if test x$enable_music_mp3_mad = xyes; then

• AC_MSG_CHECKING(for libmad headers)
• have_libmad=no
• AC_TRY_COMPILE([

• #include "mad.h"
  

• ],[
• ],[
• have_libmad=yes
• ])
• AC_MSG_RESULT($have_libmad)
• if test x$have_libmad = xyes; then

•    SOURCES="$SOURCES $srcdir/mp3_mad.c"
  

•    EXTRA_CFLAGS="$EXTRA_CFLAGS -DMP3_MAD_MUSIC"
  

•    EXTRA_LDFLAGS="$EXTRA_LDFLAGS -lmad"
  

• fi
  +fi

OBJECTS=echo $SOURCES | sed 's,[[^ ]]*/\([[^ ]]*\)\.c,$(objects)/\1.lo,g'

Index: mp3_mad.c

RCS file: mp3_mad.c
diff -N mp3_mad.c
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ mp3_mad.c 30 Jun 2006 23:55:43 -0000 1.3
@@ -0,0 +1,352 @@
+/*

• SDL_mixer: An audio mixer library based on the SDL library
• Copyright (C) 1997-2004 Sam Lantinga
• This library is free software; you can redistribute it and/or
• modify it under the terms of the GNU Library General Public
• License as published by the Free Software Foundation; either
• version 2 of the License, or (at your option) any later version.
• This library is distributed in the hope that it will be useful,
• but WITHOUT ANY WARRANTY; without even the implied warranty of
• MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
• Library General Public License for more details.
• You should have received a copy of the GNU Library General Public
• License along with this library; if not, write to the Free
• Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
• Sam Lantinga
• [email protected]
  +*/

+#ifdef MP3_MAD_MUSIC
+
+#include "mp3_mad.h"
+#include <stdio.h>
+#include <assert.h>
+#include <malloc.h>
+#include <string.h>
+
+
+mad_data *
+mad_openFile(const char *filename, SDL_AudioSpec *mixer) {

• SDL_RWops *rw;
• rw = SDL_RWFromFile(filename, "rb");
• if (rw == NULL) {
• return NULL;
• }
• return mad_openFileRW(rw, mixer);
  +}

+mad_data *
+mad_openFileRW(SDL_RWops *rw, SDL_AudioSpec *mixer) {

• mad_data *mp3_mad;
• mp3_mad = (mad_data *)malloc(sizeof(mad_data));
• mp3_mad->rw = rw;
• mad_stream_init(&mp3_mad->stream);
• mad_frame_init(&mp3_mad->frame);
• mad_synth_init(&mp3_mad->synth);
• mp3_mad->frames_read = 0;
• mad_timer_reset(&mp3_mad->next_frame_start);
• mp3_mad->volume = MIX_MAX_VOLUME;
• mp3_mad->status = 0;
• mp3_mad->output_begin = 0;
• mp3_mad->output_end = 0;
• mp3_mad->mixer = *mixer;
• return mp3_mad;
  +}

+void
+mad_closeFile(mad_data *mp3_mad) {

• SDL_FreeRW(mp3_mad->rw);
• mad_stream_finish(&mp3_mad->stream);
• mad_frame_finish(&mp3_mad->frame);
• mad_synth_finish(&mp3_mad->synth);
• free(mp3_mad);
  +}

+/* Starts the playback. */
+void
+mad_start(mad_data *mp3_mad) {

• mp3_mad->status |= MS_playing;
  +}

+/* Stops the playback. */
+void
+mad_stop(mad_data *mp3_mad) {

• mp3_mad->status &= ~MS_playing;
  +}

+/* Returns true if the playing is engaged, false otherwise. */
+int
+mad_isPlaying(mad_data *mp3_mad) {

• return ((mp3_mad->status & MS_playing) != 0);
  +}

+/* Reads the next frame from the file. Returns true on success or

• false on failure. */
  +static int
  +read_next_frame(mad_data *mp3_mad) {
• if (mp3_mad->stream.buffer == NULL ||
• mp3_mad->stream.error == MAD_ERROR_BUFLEN) {
• size_t read_size;
• size_t remaining;
• unsigned char *read_start;
• /* There might be some bytes in the buffer left over from last
• time. If so, move them down and read more bytes following
• them. */
• if (mp3_mad->stream.next_frame != NULL) {
• remaining = mp3_mad->stream.bufend - mp3_mad->stream.next_frame;
• memmove(mp3_mad->input_buffer, mp3_mad->stream.next_frame, remaining);
• read_start = mp3_mad->input_buffer + remaining;
• read_size = MAD_INPUT_BUFFER_SIZE - remaining;
• } else {
• read_size = MAD_INPUT_BUFFER_SIZE;
• read_start = mp3_mad->input_buffer;
• remaining = 0;
• }
• /* Now read additional bytes from the input file. */
• read_size = SDL_RWread(mp3_mad->rw, read_start, 1, read_size);
• if (read_size <= 0) {
• if ((mp3_mad->status & (MS_input_eof | MS_input_error)) == 0) {

• if (read_size == 0) {
  

•   fprintf(stderr, "end of input stream\n");
  

•   mp3_mad->status |= MS_input_eof;
  

• } else {
  

•   fprintf(stderr, "read error on input stream\n");
  

•   mp3_mad->status |= MS_input_error;
  

• }
  

• /* At the end of the file, we must stuff MAD_BUFFER_GUARD
  

•    number of 0 bytes. */
  

• memset(read_start + read_size, 0, MAD_BUFFER_GUARD);
  

• read_size += MAD_BUFFER_GUARD;
  

• } else {

• fprintf(stderr, "repeated eof\n");
  

• }
• }
• /* Now feed those bytes into the libmad stream. */
• mad_stream_buffer(&mp3_mad->stream, mp3_mad->input_buffer,

• 			  read_size + remaining);
  

• mp3_mad->stream.error = MAD_ERROR_NONE;
• }
• /* Now ask libmad to extract a frame from the data we just put in
• its buffer. */
• if (mad_frame_decode(&mp3_mad->frame, &mp3_mad->stream)) {
• if (MAD_RECOVERABLE(mp3_mad->stream.error)) {
• return 0;
• } else if (mp3_mad->stream.error == MAD_ERROR_BUFLEN) {
• return 0;
• } else {
• fprintf(stderr,"unrecoverable frame level error (%s).\n",

• 	  mad_stream_errorstr(&mp3_mad->stream));
  

• mp3_mad->status |= MS_decode_error;
• return 0;
• }
• }
• mp3_mad->frames_read++;
• mad_timer_add(&mp3_mad->next_frame_start, mp3_mad->frame.header.duration);
• return 1;
  +}

+/* Scale a MAD sample to 16 bits for output. */
+static signed int
+scale(mad_fixed_t sample) {

• /* round */
• sample += (1L << (MAD_F_FRACBITS - 16));
• /* clip */
• if (sample >= MAD_F_ONE)
• sample = MAD_F_ONE - 1;
• else if (sample < -MAD_F_ONE)
• sample = -MAD_F_ONE;
• /* quantize */
• return sample >> (MAD_F_FRACBITS + 1 - 16);
  +}

+/* Once the frame has been read, copies its samples into the output

• buffer. */
  +static void
  +decode_frame(mad_data *mp3_mad) {
• struct mad_pcm *pcm;
• unsigned int nchannels, nsamples;
• mad_fixed_t const *left_ch, *right_ch;
• unsigned char *out;
• int ret;
• mad_synth_frame(&mp3_mad->synth, &mp3_mad->frame);
• pcm = &mp3_mad->synth.pcm;
• out = mp3_mad->output_buffer + mp3_mad->output_end;
• if ((mp3_mad->status & MS_cvt_decoded) == 0) {
• mp3_mad->status |= MS_cvt_decoded;
• /* The first frame determines some key properties of the stream.
• In particular, it tells us enough to set up the convert
• structure now. */
• ret = SDL_BuildAudioCVT(&mp3_mad->cvt,

• 					AUDIO_S16, pcm->channels, mp3_mad->frame.header.samplerate, 
  

• 					mp3_mad->mixer.format, mp3_mad->mixer.channels,
  

• 					mp3_mad->mixer.freq);
  

• if (ret == -1) {
• fprintf(stderr, "Couldn't convert audio!\n");
• }
• }
• /* pcm->samplerate contains the sampling frequency */
• nchannels = pcm->channels;
• nsamples = pcm->length;
• left_ch = pcm->samples[0];
• right_ch = pcm->samples[1];
• while (nsamples--) {
• signed int sample;
• /* output sample(s) in 16-bit signed little-endian PCM */
• sample = scale(*left_ch++);
• *out++ = ((sample >> 0) & 0xff);
• *out++ = ((sample >> 8) & 0xff);
• if (nchannels == 2) {

•  sample = scale(*right_ch++);
  

•  *out++ = ((sample >> 0) & 0xff);
  

•  *out++ = ((sample >> 8) & 0xff);
  

• }
• }
• mp3_mad->output_end = out - mp3_mad->output_buffer;
• assert(mp3_mad->output_end <= MAD_OUTPUT_BUFFER_SIZE);
  +}

+void
+mad_getSamples(mad_data *mp3_mad, Uint8 *stream, int len) {

• int bytes_remaining;
• int num_bytes;
• Uint8 *out;
• if ((mp3_mad->status & MS_playing) == 0) {
• /* We're not supposed to be playing, so send silence instead. */
• memset(stream, 0, len);
• return;
• }
• out = stream;
• bytes_remaining = len;
• while (bytes_remaining > 0) {
• if (mp3_mad->output_end == mp3_mad->output_begin) {
• /* We need to get a new frame. */
• mp3_mad->output_begin = 0;
• mp3_mad->output_end = 0;
• if (!read_next_frame(mp3_mad)) {

• if ((mp3_mad->status & MS_error_flags) != 0) {
  

•   /* Couldn't read a frame; either an error condition or
  

• 	 end-of-file.  Stop. */
  

•   memset(out, 0, bytes_remaining);
  

•   mp3_mad->status &= ~MS_playing;
  

•   return;
  

• }
  

• } else {

• decode_frame(mp3_mad);
  

• /* Now convert the frame data to the appropriate format for
  

•    output. */
  

• mp3_mad->cvt.buf = mp3_mad->output_buffer;
  

• mp3_mad->cvt.len = mp3_mad->output_end;
  

• mp3_mad->output_end = (int)(mp3_mad->output_end * mp3_mad->cvt.len_ratio);
  

• assert(mp3_mad->output_end <= MAD_OUTPUT_BUFFER_SIZE);
  

• if (SDL_ConvertAudio(&mp3_mad->cvt) < 0) {
  

•   fprintf(stderr, "Unable to convert!\n");
  

• }
  

• }
• }
• num_bytes = mp3_mad->output_end - mp3_mad->output_begin;
• if (bytes_remaining < num_bytes) {
• num_bytes = bytes_remaining;
• }
• if (mp3_mad->volume == MIX_MAX_VOLUME) {
• memcpy(out, mp3_mad->output_buffer + mp3_mad->output_begin, num_bytes);
• } else {
• SDL_MixAudio(out, mp3_mad->output_buffer + mp3_mad->output_begin,

• 		   num_bytes, mp3_mad->volume);
  

• }
• out += num_bytes;
• mp3_mad->output_begin += num_bytes;
• bytes_remaining -= num_bytes;
• }
  +}

+void
+mad_seek(mad_data *mp3_mad, double position) {

• mad_timer_t target;
• int int_part;
• int_part = (int)position;
• mad_timer_set(&target, int_part,

• 		(int)((position - int_part) * 1000000), 1000000);
  

• if (mad_timer_compare(mp3_mad->next_frame_start, target) > 0) {
• /* In order to seek backwards in a VBR file, we have to rewind and
• start again from the beginning. This isn't necessary if the
• file happens to be CBR, of course; in that case we could seek
• directly to the frame we want. But I leave that little
• optimization for the future developer who discovers she really
• needs it. */
• mp3_mad->frames_read = 0;
• mad_timer_reset(&mp3_mad->next_frame_start);
• mp3_mad->status &= ~MS_error_flags;
• mp3_mad->output_begin = 0;
• mp3_mad->output_end = 0;
• SDL_RWseek(mp3_mad->rw, 0, SEEK_SET);
• }
• /* Now we have to skip frames until we come to the right one.
• Again, only truly necessary if the file is VBR. */
• while (mad_timer_compare(mp3_mad->next_frame_start, target) < 0) {
• if (!read_next_frame(mp3_mad)) {
• if ((mp3_mad->status & MS_error_flags) != 0) {

• /* Couldn't read a frame; either an error condition or
  

•    end-of-file.  Stop. */
  

• mp3_mad->status &= ~MS_playing;
  

• return;
  

• }
• }
• }
• /* Here we are, at the beginning of the frame that contains the
• target time. Ehh, I say that's close enough. If we wanted to,
• we could get more precise by decoding the frame now and counting
• the appropriate number of samples out of it. */
  +}

+void
+mad_setVolume(mad_data *mp3_mad, int volume) {

• mp3_mad->volume = volume;
  +}

+#endif /* MP3_MAD_MUSIC */
+
+
Index: mp3_mad.h

RCS file: mp3_mad.h
diff -N mp3_mad.h
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ mp3_mad.h 29 Jun 2006 16:27:25 -0000 1.2
@@ -0,0 +1,74 @@
+/*

• SDL_mixer: An audio mixer library based on the SDL library
• Copyright (C) 1997-2004 Sam Lantinga
• This library is free software; you can redistribute it and/or
• modify it under the terms of the GNU Library General Public
• License as published by the Free Software Foundation; either
• version 2 of the License, or (at your option) any later version.
• This library is distributed in the hope that it will be useful,
• but WITHOUT ANY WARRANTY; without even the implied warranty of
• MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
• Library General Public License for more details.
• You should have received a copy of the GNU Library General Public
• License along with this library; if not, write to the Free
• Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
• Sam Lantinga
• [email protected]
  +*/

+#ifdef MP3_MAD_MUSIC
+
+#include "mad.h"
+#include "SDL_rwops.h"
+#include "SDL_audio.h"
+#include "SDL_mixer.h"
+
+#define MAD_INPUT_BUFFER_SIZE (5*8192)
+#define MAD_OUTPUT_BUFFER_SIZE 8192
+
+enum {

• MS_input_eof = 0x0001,
• MS_input_error = 0x0001,
• MS_decode_eof = 0x0002,
• MS_decode_error = 0x0004,
• MS_error_flags = 0x000f,
• MS_playing = 0x0100,
• MS_cvt_decoded = 0x0200,
  +};

+typedef struct {

• SDL_RWops *rw;
• struct mad_stream stream;
• struct mad_frame frame;
• struct mad_synth synth;
• int frames_read;
• mad_timer_t next_frame_start;
• int volume;
• int status;
• int output_begin, output_end;
• SDL_AudioSpec mixer;
• SDL_AudioCVT cvt;
• unsigned char input_buffer[MAD_INPUT_BUFFER_SIZE + MAD_BUFFER_GUARD];
• unsigned char output_buffer[MAD_OUTPUT_BUFFER_SIZE];
  +} mad_data;

+mad_data *mad_openFile(const char *filename, SDL_AudioSpec *mixer);
+mad_data *mad_openFileRW(SDL_RWops *rw, SDL_AudioSpec *mixer);
+void mad_closeFile(mad_data *mp3_mad);
+
+void mad_start(mad_data *mp3_mad);
+void mad_stop(mad_data *mp3_mad);
+int mad_isPlaying(mad_data *mp3_mad);
+
+void mad_getSamples(mad_data *mp3_mad, Uint8 *stream, int len);
+void mad_seek(mad_data *mp3_mad, double position);
+void mad_setVolume(mad_data *mp3_mad, int volume);
+
+#endif
Index: music.c

RCS file: /cvs/SDL_mixer/music.c,v
retrieving revision 1.1.1.1
retrieving revision 1.3
diff -u -r1.1.1.1 -r1.3
--- music.c 29 Jun 2006 06:06:08 -0000 1.1.1.1
+++ music.c 29 Jun 2006 16:27:25 -0000 1.3
@@ -20,7 +20,7 @@
[email protected]
*/

-/* $Id: music.c,v 1.1.1.1 2006/06/29 06:06:08 drose Exp $ /
+/ $Id: music.c,v 1.3 2006/06/29 16:27:25 drose Exp $ */

#include <stdlib.h>
#include <string.h>
@@ -85,10 +85,16 @@
#endif
#ifdef MP3_MUSIC
#include "dynamic_mp3.h"
+#endif
+#ifdef MP3_MAD_MUSIC
+#include "mp3_mad.h"
+#endif

+#if defined(MP3_MUSIC) || defined(MP3_MAD_MUSIC)
static SDL_AudioSpec used_mixer;
#endif

int volatile music_active = 1;
static int volatile music_stopped = 0;
static int music_loops = 0;
@@ -124,6 +130,9 @@
#ifdef MP3_MUSIC
SMPEG *mp3;
#endif
+#ifdef MP3_MAD_MUSIC

• mad_data *mp3_mad;
  

+#endif
} data;
Mix_Fading fading;
int fade_step;
@@ -341,6 +350,11 @@
smpeg.SMPEG_playAudio(music_playing->data.mp3, stream, len);
break;
#endif
+#ifdef MP3_MAD_MUSIC

• 	case MUS_MP3_MAD:
  

• 	    mad_getSamples(music_playing->data.mp3_mad, stream, len);
  

• 		break;
  

+#endif
default:
/* Unknown music type?? /
break;
@@ -455,7 +469,7 @@
++music_error;
}
#endif
-#ifdef MP3_MUSIC
+#if defined(MP3_MUSIC) || defined(MP3_MAD_MUSIC)
/ Keep a copy of the mixer */
used_mixer = *mixer;
#endif
@@ -608,6 +622,20 @@
}
} else
#endif
+#ifdef MP3_MAD_MUSIC

• if ( (ext && MIX_string_equals(ext, "MPG")) ||

•  (ext && MIX_string_equals(ext, "MP3")) ||
  

•  (ext && MIX_string_equals(ext, "MPEG")) ||
  

•  (ext && MIX_string_equals(ext, "MAD")) ||
  

•  (magic[0] == 0xFF && (magic[1] & 0xF0) == 0xF0) ) {
  

• music->type = MUS_MP3_MAD;
  

• music->data.mp3_mad = mad_openFile(file, &used_mixer);
  

• if (music->data.mp3_mad == 0) {
  

•     Mix_SetError("Could not initialize MPEG stream.");
  

• 	music->error = 1;
  

• }
  

• } else
  +#endif
  #if defined(MOD_MUSIC) || defined(LIBMIKMOD_MUSIC)
  if ( 1 ) {
  music->type = MUS_MOD;
  @@ -698,6 +726,11 @@
  Mix_QuitMP3();
  break;
  #endif
  +#ifdef MP3_MAD_MUSIC

• 	case MUS_MP3_MAD:
  

• 	    mad_closeFile(music->data.mp3_mad);
  

• 		break;
  

+#endif
default:
/* Unknown music type?? */
break;
@@ -787,6 +820,11 @@
smpeg.SMPEG_play(music_playing->data.mp3);
break;
#endif
+#ifdef MP3_MAD_MUSIC

• case MUS_MP3_MAD:
  

• mad_start(music->data.mp3_mad);
  

• break;
  

+#endif
default:
Mix_SetError("Can't play unknown music type");
retval = -1;
@@ -880,6 +918,11 @@
}
break;
#endif
+#ifdef MP3_MAD_MUSIC

• case MUS_MP3_MAD:
  

• mad_seek(music_playing->data.mp3_mad, position);
  

• break;
  

+#endif
default:
/* TODO: Implement this for other music backends */
retval = -1;
@@ -959,6 +1002,11 @@
smpeg.SMPEG_setvolume(music_playing->data.mp3,(int)(((float)volume/(float)MIX_MAX_VOLUME)*100.0));
break;
#endif
+#ifdef MP3_MAD_MUSIC

• case MUS_MP3_MAD:
  

• mad_setVolume(music_playing->data.mp3_mad, volume);
  

• break;
  

+#endif
default:
/* Unknown music type?? */
break;
@@ -1027,6 +1075,11 @@
smpeg.SMPEG_stop(music_playing->data.mp3);
break;
#endif
+#ifdef MP3_MAD_MUSIC

• case MUS_MP3_MAD:
  

• mad_stop(music_playing->data.mp3_mad);
  

• break;
  

+#endif
default:
/* Unknown music type?? */
return;
@@ -1170,6 +1223,13 @@
playing = 0;
break;
#endif
+#ifdef MP3_MAD_MUSIC

• case MUS_MP3_MAD:
  

• if (!mad_isPlaying(music_playing->data.mp3_mad)) {
  

• 	playing = 0;
  

• }
  

• break;
  

+#endif
default:
playing = 0;
break;
@@ -1408,6 +1468,16 @@
}
} else
#endif
+#ifdef MP3_MAD_MUSIC

• if ( magic[0] == 0xFF && (magic[1] & 0xF0) == 0xF0 ) {

• music->type = MUS_MP3_MAD;
  

• music->data.mp3_mad = mad_openFileRW(rw, &used_mixer);
  

• if (music->data.mp3_mad == 0) {
  

•     Mix_SetError("Could not initialize MPEG stream.");
  

• 	music->error = 1;
  

• }
  

• } else
  +#endif
  #ifdef MID_MUSIC
  /* MIDI files have the magic four bytes "MThd" */
  if ( strcmp((char *)magic, "MThd") == 0 ) {

On 2007-07-14 20:15:13 +0000, Sam Lantinga wrote:

This looks like a great patch, and I just checked out libmad and madplay on Mac OS X. All I got was static trying to play an MP3 file. I contacted the company and hopefully they'll respond.

On 2007-07-14 21:56:33 +0000, Sam Lantinga wrote:

I applied this patch anyway, and libmad itself works just fine. :)

On 2007-07-14 22:34:19 +0000, Sam Lantinga wrote:

This has been added in subversion revision 3278, thanks!

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2006-09-23 05:44:04 +0000, Patrice Mandin wrote:

The readmidi.c file is present in both ./timidity and ./native_midi_gpl subdirectories, and in the build process, they are both compiled to ./build/readmidi.o, hence one of them is deleted, and the build process fails.

You just have to enable both timidity and native-midi-gpl midi music players in configure to trigger it.

This is a big caveat coming from the reworking of the built process, and may happen in the other SDL libs in the same case.

On 2007-02-13 03:12:25 +0000, Ryan C. Gordon wrote:

I suspect that the number of source file name conflicts are going to be pretty low, so for now I'm going to be cheap and just rename one of the files in SDL_mixer.

We could also have the build system mirror the source tree (so it builds to build/timidity/readmidi.o and build/native_midi_gpl/readmidi.o instead of just build/readmidi.o), but it's not really worth spending time on it right now.

File was renamed in svn revision # 2960.

--ryan.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 1.2.8
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2008-02-13 07:17:38 +0000, Alex wrote:

I don't know if this is a bug or feature, but IMO it would be much more sensible for it to call the hook function. Mix_HaltChannel does call callback functions, so there's confusing difference in behavior.

On 2008-02-18 03:13:50 +0000, Alex wrote:

Sorry, accidentally created duplicates.

*** This bug has been marked as a duplicate of bug 549 ***

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 1.2.8
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2008-03-15 08:46:58 +0000, Lukasz Pawelczyk wrote:

When using SDL_mixer compiled with native midi support it freezes software that uses it. The only two examples I know that can use it this way are: dxx-rebirth and doomsday. I suspect its a bug in SDL_mixer cause both play fine when using timidity backend.

I'm using Audigy 2 ZS on alsa 1.0.14 with OSS emulation. Have no other problems with Native midi support on my system (both, by using alsa-synth and /dev/sequencer). Playmidi (which code I think is used in SDL_mixer) plays fine as well.

On 2008-03-16 17:52:46 +0000, Lukasz Pawelczyk wrote:

I didn't try to fix it, but I wrote alternative sequncer support for SDL-mixer based on alsa-seq. The code needs some cleanups but it already works very well. Would you be interested in its inclusion to SDL-mixer? I also got several questions about internal sdl-mixer functions behaviour. Error handling etc so this would fully follow sdl-mixer policy. Where could I ask them?

On 2009-10-03 02:58:01 +0000, Sam Lantinga wrote:

Sure, I'd love to get a patch for ALSA native midi. You can ask the questions here, or send e-mail to the SDL mailing list.

Thanks!

On 2009-10-03 04:35:12 +0000, Lukasz Pawelczyk wrote:

Wow, that was a long time ago :-)

Ok, I'll try to get this patch out of attic, dust it off a little and see what can be done with it.

This patch is based on aplaymidi code which is GPL based but I had permission from it's author back then to relicense it to LGPL if it's going to be included in SDL_mixer.

On 2009-10-27 07:57:33 +0000, Lukasz Pawelczyk wrote:

Small update.

I've been working ont his code for the past few days. In general it is very close to be ready (finished lots of things that were left in my TODO 1.5 year ago). The only thing I'm still working on is gracefully stopping of ALSA events. I had some thread race previously that could crash ALSA on some occasions. I've managed to eliminate it but still as I look at that code there is very very rare case that could cause it to crash (although it didn't happen for me in practice).

Anyway I hope this will be ready soon.

On 2011-12-28 09:49:56 +0000, wrote:

Debian bug reports [1] and [2] seem related with this problem:

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498984
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298982

On 2011-12-31 11:01:35 +0000, Sam Lantinga wrote:

I've removed the native MIDI code from SDL_mixer, since it was GPL and the new licensing is zlib.

Lukasz, if you have that ALSA patch ready, please submit a new bug with it attached and let me know! :)

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: Other, x86

Comments on the original bug report:

On 2007-02-21 11:08:22 +0000, Nicos wrote:

SDL_mixer does not upsample when the chunk sample rate < output sample rate but it incorrectly plays the sample with the output sample rate (from what I can hear). I realize that you might not want to support upsampling but at least it should be mentioned in the documentation and/or make Mix_PlayChannelTimed return an error in this case.

On 2007-02-22 02:23:26 +0000, Ryan C. Gordon wrote:

It supports upsampling if the sample rates are multiples (so it can do 11025 to 22050 or 44100, but not 8000 to 11025).

The cause of this issue is actually a bug in SDL and not SDL_mixer, which incorrectly resamples the audio without reporting an error.

As such, I'm marking this bug as a duplicate of that issue.

--ryan.

*** This bug has been marked as a duplicate of 58 ***

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• MOD which sounds wrong with Brandon's patch (pingus-1.it, application/octet-stream, 2009-10-04 22:56:51 +0000, 129499 bytes)
• Patch for libmikmod fixing both this bug and Brandon's crash (libmikmod-3.1.12-md_sngchn-fix.diff, text/plain, 2009-10-04 23:56:49 +0000, 3178 bytes)

Reported in version: unspecified
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2007-10-21 07:29:24 +0000, Torbjörn Andersson wrote:

It seems that revision 3439 [1] of SDL_mixer broke the music from Pingus 0.7.1 [2].

[1] http://lists.libsdl.org/pipermail/svn-libsdl.org/2007-August/000491.html
[2] http://pingus.seul.org/download.html

I noticed it first with data/music/pingus-1.it, which sounds all wrong. Reverting the change to pt_UpdateVoices() "fixes" it, but presumably re-introduces the bug that revision 3439 was supposed to fix. I'm afraid I don't have any ideas for how to fix it properly.

On 2009-10-03 02:13:56 +0000, Sam Lantinga wrote:

I upgraded libmikmod to version 3.1.12 and reverted the patch which caused this bug, which was fixing the following bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=422021

I've sent e-mail to Brandon, who submitted that patch to see if his bug is fixed by the libmikmod upgrade.

On 2009-10-04 22:53:41 +0000, Sam Lantinga wrote:

Brandon wrote back with more information on the debian bug:

The newest version of libmikmod still has the bug I reported and made a
patch for.
http://sourceforge.net/tracker/?func=detail&aid=1630158&group_id=40531&atid=428227
So if you upgraded libmikmod, and removed my patch, then SDL-mixer
would most likely again suffer from this bug.

I would be happy to help you out. I need to know which libraries I need
for the above functions.

If you want to try to duplicate this yourself:

1. download and build an older version of penguin command:
   http://prdownloads.sourceforge.net/penguin-command/penguin-command-1.6.10.tar.gz
2. run penguin command with the SDL mixer library you want to test

It should segfault 1/4 times on boot. Specifically, whenever
pennight.mod plays, it should segfault. If you were to continue to play
the game, then eventually it should segfault when the music eventually
transitions to pennight.mod.

On 2009-10-04 22:56:51 +0000, Sam Lantinga wrote:

Created attachment 396
MOD which sounds wrong with Brandon's patch

I verified that this MOD will not sound correct if Brandon's patch is applied. The pf->numchn is set to 8, but by the end of the song there are 41 voices playing.

On 2009-10-04 23:56:49 +0000, Sam Lantinga wrote:

Created attachment 397
Patch for libmikmod fixing both this bug and Brandon's crash

Okay, I tracked down the issue and have a patch for libmikmod that solves both this bug and the crash Brandon was trying to fix.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• simple test program and a midi file (test.tar.gz, application/x-gzip, 2006-11-04 01:31:45 +0000, 721 bytes)

Reported in version: unspecified
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2006-11-04 01:28:43 +0000, Darius Scerbavicius wrote:

On Ubuntu Edgy with SDL_mixer 1.2.7 and SDL_mixer 1.2.6, after setting music cmd and trying to play music forever ( Mix_PlayMusic(music, -1); ), after it loops the first time, I cannot quit in the middle. I have to wait for it to finish first. It quits fine before it starts looping.
Is this a bug or am i doing something wrong?

On 2006-11-04 01:31:45 +0000, Darius Scerbavicius wrote:

Created attachment 179
simple test program and a midi file

Seems to happen with both Mix_SetMusicCMD("timidity"); and Mix_SetMusicCMD("aplaymidi -p 17:0"); but doesn't happen when I don't use Mix_SetMusicCMD.

On 2009-10-11 01:41:49 +0000, Sam Lantinga wrote:

Thanks, this was a sneaky one!
When music loops, the looping music play call is done from the audio thread, and
SDL threads block signals to avoid signal side effects. So we just need to unb
lock those signals before executing the new process.

You provided a great test case, thanks!

This is fixed for the next release. :)

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 1.2.8
Reported for operating system, platform: Linux, All

Comments on the original bug report:

On 2007-10-27 04:52:36 +0000, Patrice Mandin wrote:

Hello,

in music.c, line 461:
native_midi_ok = !timidity_ok;

It means that you can't use native midi if timidity is ok and available, even if you set the SDL_NATIVE_MUSIC environment variable (as written in native_midi_gpl/README). It would be nice to be able to test either output without having to recompile with one or the other disabled.

On 2007-10-27 05:12:28 +0000, Patrice Mandin wrote:

Simple patch:

-- music.c (revision 3451)
+++ music.c (working copy)
@@ -459,6 +459,9 @@
#ifdef USE_NATIVE_MIDI
#ifdef USE_TIMIDITY_MIDI
native_midi_ok = !timidity_ok;

•   if (!native_midi_ok) {
  

•           native_midi_ok = (getenv("SDL_NATIVE_MUSIC") != NULL);
  

•   }
    if ( native_midi_ok )
  

#endif
native_midi_ok = native_midi_detect();

On 2009-10-03 02:30:03 +0000, Sam Lantinga wrote:

Fixed, thanks!

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2008-03-07 09:42:17 +0000, Alam Arias wrote:

in r3557 of SDL_Mixer, MUS_FLAC was added in the middle of Mix_MusicType list, so any program compiled with SDL_Mixer 1.2.8 and uses Mix_GetMusicType() and (MUS_MP3 or MUS_MP3_MAD) will be messed up when linked against this new SDL_Mixer code, let just move MUS_FLAC to the end of the list to fix this

diff --git a/SDL_mixer.h b/SDL_mixer.h
index 58e0713..4d6907a 100644
--- a/SDL_mixer.h
+++ b/SDL_mixer.h
@@ -103,9 +103,9 @@ typedef enum {
MUS_MOD,
MUS_MID,
MUS_OGG,

•   MUS_FLAC,
    MUS_MP3,
  

•   MUS_MP3_MAD
  

•   MUS_MP3_MAD,
  

•   MUS_FLAC,
  

} Mix_MusicType;

/* The internal format for a music chunk interpreted via mikmod */

On 2008-03-08 22:35:49 +0000, Ryan C. Gordon wrote:

Fixed in svn revision # 3571.

Thanks!

--ryan.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2008-03-12 09:51:13 +0000, Ozkan Sezer wrote:

SVN-3555 change to SDL_mixer/music_mad.c breaks compilation.
I think the intended return value should be mp3_mad and not
"data"; like so:

diff -urNp SDL_mixer-svn3571/music_mad.c SDL_mixer/music_mad.c
--- SDL_mixer-svn3571/music_mad.c 2008-03-12 17:55:11.000000000 +0200
+++ SDL_mixer/music_mad.c 2008-03-12 18:15:25.000000000 +0200
@@ -42,7 +42,7 @@ mad_openFile(const char *filename, SDL_A
return NULL;
}
mp3_mad->freerw = SDL_TRUE;

• return data;

• return mp3_mad;
  }

mad_data *

Regards,
Ozkan Sezer

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Audio sample (sdl_mixer_bug.wav, audio/wav, 2007-03-08 18:34:20 +0000, 24636 bytes)

Reported in version: unspecified
Reported for operating system, platform: Mac OS X 10.4 (Intel), PowerPC

Comments on the original bug report:

On 2007-03-08 18:27:40 +0000, Jesse Anders wrote:

In the mix_channels() function, it appears that looping and playback termination behaves incorrectly when the length of the sample is an even multiple of the value of the 'len' argument. When the 'loop' argument to Mix_PlayChannel() is > 0, the sound plays back one fewer times than requested, and the callback is not called when the sound finishes playing.

Here is a short program that demonstrates this behavior:

/******************************************************************************/

#include "SDL.h"
#include "SDL_mixer.h"

#include

void Callback(int) { std::cout << "Callback() was called." << std::endl; }

int main(int argc, char *argv[])
{
SDL_Init(SDL_INIT_AUDIO);
Mix_OpenAudio(44100, MIX_DEFAULT_FORMAT, 2, 1024);
Mix_ChannelFinished(Callback);

std::cout << "\nPlaying sample with loop = 1: Should play twice, but\n"
          << "will only play once and callback will not be called.\n\n"
          << "(Press any key followed by enter to quit)" << std::endl;

Mix_Chunk* sound = Mix_LoadWAV("sdl_mixer_bug.wav");
Mix_PlayChannel(-1, sound, 1);

std::cin.get();

Mix_FreeChunk(sound);
Mix_CloseAudio();
SDL_Quit();

return 0;

}

/******************************************************************************/

Here is the URL of the audio file used:

http://cmldev.net/wp-content/uploads/2007/03/sdl_mixer_bug.wav

The length of this particular sample is 98304, which is an even multiple of 4096, the value I get for the mix_channels() 'len' argument when the buffer size is set to 1024.

I'm using SDL_mixer 1.2.7 in OS X 10.4.8.

On 2007-03-08 18:34:20 +0000, Jesse Anders wrote:

Created attachment 197
Audio sample

Here is the audio sample as an attachment.

On 2007-07-14 21:42:10 +0000, Sam Lantinga wrote:

This is fixed in subversion revision 3277, thanks! This was a great test case, BTW.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• DWORD_PTR patch for native_midi_win32 (native_midi_win32-DWORD_PTR.patch, text/plain, 2008-12-22 08:57:42 +0000, 1576 bytes)

Reported in version: 1.2.8
Reported for operating system, platform: Windows (All), x86

Comments on the original bug report:

On 2008-05-13 13:31:36 +0000, Steven Noonan wrote:

I've just recently tested my application compiled for x86_64 (AMD64, x64, whatever you want to call it). Unfortunately there's one flaw in SDL_mixer which causes a pointer truncation and subsequent memory access violation and crash.

On 2008-05-13 13:33:52 +0000, Steven Noonan wrote:

I would normally attach the patch, but I'm getting Bugzilla internal errors when trying to upload it:

Internal Error

Bugzilla has suffered an internal error. Please save this page and send it to [email protected] with details of what you were doing at the time this message appeared.

URL: http://bugzilla.libsdl.org/attachment.cgi
undef error - Undefined subroutine Fh::slice at data/template/template/en/default/global/hidden-fields.html.tmpl line 58

So, here's the patch text:
--- SDL_mixer-1.2.8-1/native_midi/native_midi_win32.c 2008-05-13 13:24:56.287800000 -0700
+++ SDL_mixer-1.2.8/native_midi/native_midi_win32.c 2008-05-13 13:25:53.615000000 -0700
@@ -181,7 +181,7 @@
MMRESULT merr;
HMIDISTRM MidiStream;

• merr=midiStreamOpen(&MidiStream,&MidiDevice,1,(DWORD)&MidiProc,0,CALLBACK_FUNCTION);

• merr=midiStreamOpen(&MidiStream,&MidiDevice,1,(DWORD_PTR)&MidiProc,0,CALLBACK_FUNCTION);
  if (merr!=MMSYSERR_NOERROR)
  MidiStream=0;
  midiStreamClose(MidiStream);

On 2008-12-22 08:57:42 +0000, Ozkan Sezer wrote:

Created attachment 284
DWORD_PTR patch for native_midi_win32

I think more changes are necessary to MidiProc for win64:
see, for example, a ptr is being cast to DWORD in the switch
statement. Can any of you guys review the attached patch?

Ozkan

On 2009-09-26 02:19:31 +0000, Sam Lantinga wrote:

Looks good, your patch is in for the next release.

Thanks!

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• the patch for SDL_mixer-1.2.7 (SDL_mixer-1.2.7.tremor.patch, text/plain, 2006-08-08 14:49:35 +0000, 3798 bytes)

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2006-08-08 14:48:33 +0000, Philippe Simons wrote:

this patch (see attachment) add the --enable-music-ogg-tremor option to configure.
if selected SDL_mixer will try to compile with libtremor (integer only) for ogg payback.

On 2006-08-08 14:49:35 +0000, Philippe Simons wrote:

Created attachment 156
the patch for SDL_mixer-1.2.7

On 2007-07-14 20:39:07 +0000, Sam Lantinga wrote:

This has been added in revision 3274. Thanks!

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: Windows (XP), x86

Comments on the original bug report:

On 2006-08-24 00:08:29 +0000, Geoff Carlton wrote:

I've just found a memory crash bug that occurs with the latest SDL_mixer 1.2.7 on windows, when loading OGG files. The bug is this:

load_ogg.c mallocs a buffer internally:
*audio_buf = malloc(*audio_len)

mixer.c frees it via the SDL dll:
SDL_FreeWAV(chunk->abuf)

This can cause a problem since memory is allocated in one dll and freed in another. My solution was to hack around in mixer.c. I added an "int owner" variable, set to 1 in the OGG switch case, and replaced the couple of SDL_FreeWAV calls with:
if (owner) free(chunk->abuf) else SDL_FreeWAV(chunk->abuf)

On 2006-10-03 09:07:30 +0000, Peter Mulholland wrote:

I didn't get this bug, but I did recompile SDL.dll and SDL_mixer.dll with MSVC 2005, which my game also compiles with. Perhaps this compilers runtime handles this sort of issue.

On 2006-12-27 15:40:05 +0000, Patrice Mandin wrote:

Duplicate of bug 369?
http://bugzilla.libsdl.org/show_bug.cgi?id=369

On 2007-02-13 02:55:23 +0000, Ryan C. Gordon wrote:

Yes, this is a duplicate bug.

--ryan.

*** This bug has been marked as a duplicate of 369 ***

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Test .ogg file. (whoosh.ogg, application/octet-stream, 2007-02-12 20:24:44 +0000, 6913 bytes)

Reported in version: unspecified
Reported for operating system, platform: Mac OS X (All), PowerPC

Comments on the original bug report:

On 2006-01-03 12:26:53 +0000, Ryan C. Gordon wrote:

Date: Sun, 25 Sep 2005 11:33:08 -0700 (PDT)
From: Keith Nemitz [email protected]
Subject: Easily reproducible bug in SDL Mixer for Macintosh.
To: [email protected]
Cc: [email protected]

This may be a libvorbis bug, but I'm working down the
food chain.

On the Mac OSX, Panther and Tiger, ogg files less than
8k will hang when played as a sound effect.

I found the bug using the 1.7 version of PyGame. When
I downgrade my version of SDL_Mixer from 1.2.6, the
bug goes away. I hope you'll be able to reproduce the
problem and turn around a fix.

thank you for you time,

Keith Nemitz
Ordinauteur
Mousechief Co.
www.mousechief.com

On 2006-01-19 06:28:23 +0000, Ryan C. Gordon wrote:

Tossing the SDL_mixer bugs to Sam (all three of which might be the same bug in practice)...if you don't want these, toss them back to me.

--ryan.

On 2006-01-27 11:23:06 +0000, Ryan C. Gordon wrote:

Setting Sam as "QA Contact" on all bugs (even resolved ones) so he'll definitely be in the loop to any further discussion here about SDL.

--ryan.

On 2006-01-31 15:51:17 +0000, Eric wing wrote:

There was some other bug report I remember from a user (either on the list or directly to me) that the static version of vorbis used in our SDL_mixer/OS X package was out of date and caused problems. I was told that updating ogg/vorbis fixed this user's problems.

Because of the Universal Binaries, I've been updating all the components to everything including ogg/vorbis. Once I get these out, we should test to see if this bug goes away.

On 2007-02-12 20:24:44 +0000, Ryan C. Gordon wrote:

Created attachment 188
Test .ogg file.

Here's a .ogg that's less than 8k.

--ryan.

On 2007-02-12 20:27:27 +0000, Ryan C. Gordon wrote:

I just tried this on Mac OS X with the svn trunk of SDL_mixer, libogg-1.1.3 and libvorbis-1.1.2 and the "playmus" test app could play it back, so we either fixed this or it was a bug in an older libogg/libvorbis.

If it was a question of the prebuilt framework, then I'm not losing sleep over it, since it's definitely not a bug in any SDL code.

Closing bug as WORKSFORME.

--ryan.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2006-05-20 13:44:53 +0000, Hussam Al-Tayeb wrote:

After upgrading from "sdl_mixer 1.2.6 + sdl_mixer_mikmod patch" to vanilla "sdl_mixer 1.2.7 ( unpatched )", sdl games won't read sound.

Supertux won't load because of error
Error: Couldn't load musicfile
/usr/bin/../share/supertux/music/SALCON.MO

and frozen-bubble gives error:
Warning, could not create new music from
`/usr/share/frozen-bubble/snd/introzik.xm' (reason: Unrecognized music
format)

planetpenguinracer 0.5 cvs gives the same problem.
This was working ealier with and sdl_mixer 1.2.6 with sdl_mixer
mikmod patch

On 2006-05-20 20:12:44 +0000, Hussam Al-Tayeb wrote:

Apparently, the error was wrong configure options, sorry for the alarm. :)

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Patch to add/modify files for FLAC support (SDL_mixer.FLAC_support.patch, text/plain, 2008-01-30 19:14:05 +0000, 47523 bytes)
• Patch to add/modify files for FLAC support (SDL_mixer.FLAC_support.patch, text/plain, 2008-02-03 21:33:44 +0000, 47539 bytes)

Reported in version: unspecified
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2008-01-28 19:53:29 +0000, Austen Dicken wrote:

I was thinking it would be great to add support for the Free Lossless Audio Codec (FLAC), so I have been working on a patch to the current SVN checkout of SDL_mixer that would add support for it.

I am just kind of curious as to whether anyone thinks this would be a good idea? I am about 1/2 way done with the patch and then was going to start testing.

Any thoughts and/or suggestions would be greatly appreciated. ^.^

On 2008-01-28 21:13:16 +0000, Sam Lantinga wrote:

Sure, why not? Thanks! :)

On 2008-01-30 11:23:35 +0000, Austen Dicken wrote:

Good news! FLAC files are currently playing using the bundled "playmus" program! I still need to do a bit more testing as I know the load_flac.c file isn't working right, but I should have a patch for you by tonight or tomorrow!

On 2008-01-30 13:05:34 +0000, Sam Lantinga wrote:

Great, thanks!

On 2008-01-30 19:14:05 +0000, Austen Dicken wrote:

Created attachment 247
Patch to add/modify files for FLAC support

Ok, here is the patch I made for FLAC support.

I have tested it relatively thoroughly and currently the patch allows:

1. Pre-loading FLAC files and playing them via LoadWAV
2. The patch allows for FLAC support in the LoadMUS setting as well as:
   • Pause / Resume
   • Volume control
   • Seeking

I also did a little benchmarking by comparing memory/cpu usage of playmus to that of mplayer, and the results were very good. playmus typically took about half the RAM as mplayer, though that may be attributed to mplayer being a more "bulky" program. As such I would say that the two are probably about equal in efficiency.

Also, it is important to note that, similar to the OGG support currently built-in, my FLAC patch only supports 16 bit stereo-encoded sound. Also, it
is only for Native FLAC (standard) and not the derivative, Ogg-FLAC.

I have tried to find a simple way to detect Ogg-FLAC files, as the only difference between Ogg-FLAC and Native FLAC support is changing the init_ function call, but after digging a little deeper it seems that Ogg-FLAC is basically FLAC wrapped in an Ogg transport layer, so it would be better to have a way to read the Ogg transport layer which then reads the inner audio files according to the proper codec.

But anyway, that's another job for another day! For now this should provide Native FLAC support!

On 2008-02-03 21:33:44 +0000, Austen Dicken wrote:

Created attachment 248
Patch to add/modify files for FLAC support

I was continuing my testing of this patch and noticed an error where I was calling .ogg instead of .flac in a particular music union structure.

On 2008-02-03 21:36:04 +0000, Austen Dicken wrote:

I just had a quick question. I noticed that I have been assigned to this bug and was wondering what connotations that brings along with it. I am relatively new to the community development model and am not entirely sure of what my role is so far as what I should be doing to resolve this feature and the like.

On 2008-02-04 11:44:21 +0000, Sam Lantinga wrote:

It's just an internal note so we don't assume that we're responsible for implementing the functionality. By providing a patch and serving as a contact for related bugs, you're fulfilling your role as assignee. We'll apply the patch and run some basic testing and verification of it.

Thanks!

On 2008-02-26 23:31:58 +0000, Sam Lantinga wrote:

This has been added to subversion. Thanks!

On 2008-02-27 00:24:50 +0000, Austen Dicken wrote:

Glad to be of assistance. :)

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 1.2.8
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2008-02-13 06:41:14 +0000, Alex wrote:

I don't know if this is a bug or feature, but IMO it would be much more sensible for it to call the hook function. Mix_HaltChannel does call callback functions, so there's confusing difference in behavior.

On 2008-02-18 03:11:45 +0000, Alex wrote:

Sorry, accidentally created duplicates.

*** This bug has been marked as a duplicate of bug 549 ***

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: Windows (XP), x86

Comments on the original bug report:

On 2006-06-07 17:05:42 +0000, Sebastian Beschke wrote:

Using the prebuilt SDL_mixer DLLs, SDL_mixer 1.2.7 crashes with an access violation upon trying to load an OGG Vorbis file using Mix_LoadMUS().

Here's a small sample program:

#include <stdio.h>
#include "SDL.h"
#include "SDL_mixer.h"

int main(int argc, char* argv[])
{
fprintf(stderr, "SDL_Init(SDL_INIT_AUDIO);\n");
SDL_Init(SDL_INIT_AUDIO);

fprintf(stderr, "Mix_OpenAudio\n");
if(Mix_OpenAudio(22050, AUDIO_S16SYS, 2, 4096)) {
fprintf(stderr, "OpenAudio failed: %s\n", Mix_GetError());
exit(1);
}

fprintf(stderr, "Mix_LoadMUS()\n");
Mix_Music* music = Mix_LoadMUS("music.ogg");
if(!music) {
fprintf(stderr, "Could not load music.ogg: %s\n", Mix_GetError());
exit(1);
}

fprintf(stderr, "Mix_FreeMusic()\n");
Mix_FreeMusic(music);

Mix_CloseAudio();

SDL_Quit();

return 0;
}

On 2006-06-25 15:52:44 +0000, Ryan C. Gordon wrote:

This is working on Linux (and Valgrind doesn't smell anything fishy)...perhaps we fixed it? A broken ogg? Perhaps it's a Windows-specific thing or a misbuilt library?

Tossing it to Sam.

--ryan.

On 2006-06-25 16:54:30 +0000, Sebastian Beschke wrote:

The OGG file I used was fine; the problem occured for me on Windows XP and has been reproduced by several people (using the pre-built DLLs).
Sebastian

On 2006-06-25 17:28:04 +0000, Sam Lantinga wrote:

I can reproduce the problem as well, I'm looking into it.

On 2006-06-26 13:43:02 +0000, Sam Lantinga wrote:

This was caused by a C runtime mismatch. This is fixed in subversion, and you can get the updated 1.2.7 files here:
http://www.libsdl.org/projects/SDL_mixer/release/SDL_mixer-1.2.7-win32.zip

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• test case. (testmixerleak.c, text/x-csrc, 2007-07-15 08:17:07 +0000, 1160 bytes)

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2007-01-29 12:09:13 +0000, Ryan C. Gordon wrote:

Discussion:

http://lists.libsdl.org/pipermail/sdl-libsdl.org/2007-January/059515.html

Relevant detail:

"Because this is for unit test, I have the effects on a button press.
So it's very likely that Mix_SetPanning() gets called multiple times.
No other effects were set on that channel.

Here's the flow:

Mix_OpenAudio
Set volume to MAX
Allocate 2 channels
Load the 2 different chunks (1 on each channel)
Load the music
Play the music (loop forever)
Play chunk 0 on channel 0
(while sfx is playing) Set Panning on both channels to (255, 0)
Halt Channel (passing -1, i.e. halt all channels)
Free chunk 0
Free chunk 1
Mix_AllocateChannels(0) // free all channels
Halt Music
Free Music
Mix_CloseAudio

Cheers,
Kos"

--ryan.

On 2007-06-27 15:31:05 +0000, Ryan C. Gordon wrote:

Whoops, this is an SDL_mixer bug, not an SDL bug...

--ryan.

On 2007-07-14 20:40:45 +0000, Sam Lantinga wrote:

Ryan, can you take a look at this for the SDL_mixer 1.2.8 release?

On 2007-07-15 07:43:05 +0000, Ryan C. Gordon wrote:

Looking at this now.

--ryan.

On 2007-07-15 08:17:07 +0000, Ryan C. Gordon wrote:

Created attachment 228
test case.

Here's a test case that triggers the bug. "whoosh.wav" and "icculus.org" can be just about any file you have laying around your hard drive.

--ryan.

On 2007-07-15 08:57:57 +0000, Ryan C. Gordon wrote:

Fixed in svn revision # 3290.

--ryan.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2006-04-20 20:09:59 +0000, Michael Thomas wrote:

Midi music playback comes out very distorted and full of static on x86_64. Playing the same midi file on i386 plays cleanly. I've been able to reproduce this on Fedora Core 4 and Fedora Core 5.

Link to the Fedora bugzilla ticket:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175672

Here's the sample midi file from 'freedoom' that I used for testing:
http://www.kobold.org/~wart/fedora/prboom.mid

On 2006-04-20 22:23:10 +0000, Michael Thomas wrote:

Ah hah. This seems to be fixed in CVS. Is there an ETA for a 1.2.7 release? If not, then would you object if I make a patch from CVS for Fedora so that we can fix the problems reported there? The CVS page for SDL requests that the CVS files are not redistributed, so I thought I should ask first.

On 2006-04-27 05:06:47 +0000, Ryan C. Gordon wrote:

Wow, Fedora is still shipping 1.2.6?! We are up to 1.2.9 in releases, and it's literally years of development past 1.2.6.

Resolving this bug since it is apparently fixed on our end. Please tell Fedora to update their RPM, we'd appreciate it.

http://www.libsdl.org/download-1.2.php

Thanks,
--ryan.

On 2006-04-27 10:39:13 +0000, Michael Thomas wrote:

Fedora is shipping SDL 1.2.9, but this bug is with SDL_mixer, which is still at version 1.2.6:
http://www.libsdl.org/projects/SDL_mixer/release/

On 2006-04-27 11:46:34 +0000, Ryan C. Gordon wrote:

Oh, I totally misread that, sorry about that.

--ryan.

On 2006-04-29 23:40:49 +0000, Sam Lantinga wrote:

(In reply to comment # 1)

Ah hah. This seems to be fixed in CVS. Is there an ETA for a 1.2.7 release?

SDL_mixer 1.2.7 will be released soon after SDL 1.2.10, hopefully in the next month or so.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Patch to add this behaviour. (SDL_mixer-halt-music-callback-RYAN1.diff, text/plain, 2009-10-08 02:27:57 +0000, 312 bytes)
• Patch to call music callback anytime music is stopped (music_halt_callback.diff, text/plain, 2009-10-11 00:41:34 +0000, 724 bytes)

Reported in version: 1.2.8
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2008-02-13 06:34:47 +0000, Alex wrote:

I don't know if this is a bug or feature, but IMO it would be much more sensible for it to call the hook function. Mix_HaltChannel does call callback functions, so there's confusing difference in behavior.

On 2008-02-18 03:11:45 +0000, Alex wrote:

*** Bug 550 has been marked as a duplicate of this bug. ***

On 2008-02-18 03:13:33 +0000, Alex wrote:

*** Bug 551 has been marked as a duplicate of this bug. ***

On 2008-02-18 03:13:50 +0000, Alex wrote:

*** Bug 552 has been marked as a duplicate of this bug. ***

On 2009-10-03 02:57:11 +0000, Sam Lantinga wrote:

Ryan, can you evaluate this? Thanks!

On 2009-10-08 02:26:57 +0000, Ryan C. Gordon wrote:

The docs for Mix_HookMusicFinished() say: "This callback is only called if the music finishes naturally."

So, it might break existing programs if we change it to run the callback during Mix_HaltMusic().

Tossing bug to Sam to decide if that's okay.

--ryan.

On 2009-10-08 02:27:57 +0000, Ryan C. Gordon wrote:

Created attachment 401
Patch to add this behaviour.

This patch will add the behaviour requested here, if you think it's safe to do so.

--ryan.

On 2009-10-09 21:43:44 +0000, Ryan C. Gordon wrote:

Honestly, I'm sort of thinking we should do this and see what breaks.

--ryan.

On 2009-10-09 22:03:39 +0000, Sam Lantinga wrote:

Okay, I remember we added this for Heroes 3, so we should probably check to see if that breaks. ;)

On 2009-10-11 00:38:16 +0000, Sam Lantinga wrote:

I looked into this more closely, and this is a sensible but dangerous change to make.

The right thing to do here is to have both the channel and music callbacks always called when a channel or music stops for any reason, but it should be passed a reason why the sound stopped.

The typical use of the music stopped callback is to pick another song to play. The assumption is that if you're explicitly halting the music that you have some other action that you are in control of that you want to take place.

If we change this behavior, then suddenly applications will be getting a finished callback when they don't expect it, and this could cause anything from application bugs to crashes.

So, I'm punting this until we do an SDL_mixer API revamp.

On 2009-10-11 00:41:34 +0000, Sam Lantinga wrote:

Created attachment 409
Patch to call music callback anytime music is stopped

This is a more comprehensive patch that calls the finished hook anytime music stops playing. If this were applied, we'd also want to change the hook function to take a reason as a parameter, and update the channel finished hook to do the same thing.

On 2012-05-25 03:08:25 +0000, Aki Koskinen wrote:

Waking up a hibernating bug here...

If the behaviour of the lib is not changed as discussed in this bug (i.e. the attached patch won't be applied) would it be appropriate to fix the documentation to reflect the reality? It currently claims that the music finished callback would be called when Mix_HaltMusic() is called but that doesn't happen.

I just spent quite an amount of time believing the documentation and wondering why my callback doesn't get called. I might not be the only one wasting time this way...

On 2012-05-29 21:38:07 +0000, Ryan C. Gordon wrote:

(In reply to comment # 11)

If the behaviour of the lib is not changed as discussed in this bug (i.e. the
attached patch won't be applied) would it be appropriate to fix the
documentation to reflect the reality? It currently claims that the music
finished callback would be called when Mix_HaltMusic() is called but that
doesn't happen.

Where does it say this?

--ryan.

On 2012-05-31 02:33:01 +0000, Aki Koskinen wrote:

(In reply to comment # 12)

(In reply to comment # 11)

If the behaviour of the lib is not changed as discussed in this bug (i.e. the
attached patch won't be applied) would it be appropriate to fix the
documentation to reflect the reality? It currently claims that the music
finished callback would be called when Mix_HaltMusic() is called but that
doesn't happen.

Where does it say this?

In http://www.libsdl.org/projects/SDL_mixer/docs/SDL_mixer.html#SEC67

[--] Any callback set by Mix_HookMusicFinished will be called when the music stops. [--]

And in http://www.libsdl.org/projects/SDL_mixer/docs/SDL_mixer.html#SEC69

[--] This sets up a function to be called when music playback is halted. Any time music stops, the music_finished function will be called. [--]

On 2012-06-01 03:29:54 +0000, Ryan C. Gordon wrote:

Sam, can we update those docs?

--ryan.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: Other, All

Comments on the original bug report:

On 2007-07-20 06:35:22 +0000, Alec Holowka wrote:

Can be reproduced with playmus -l

Test file:

http://zaphire.ca/sdl_mixer/test.ogg

On 2007-07-21 00:48:59 +0000, Sam Lantinga wrote:

It looks like this will take a fair bit of rework of the music mixing loop. Ryan, you want to tackle that for SDL_mixer 1.2.9?

On 2007-07-21 01:11:48 +0000, Alec Holowka wrote:

Some info:

This thread on GameDev.net has some example code for looping to fill up the buffer from ov_read for seamless looping: http://www.gamedev.net/community/forums/topic.asp?topic_id=221938

It seems like that needs to be implemented in OGG_getsome(...)

One question is how OGG_getsome(...) should get access to the loop counter. The loop stuff is done at the higher level (checked in music_halt_or_loop), but for seamless it needs to be implemented at the buffer level.

I'd try to mess with it myself, but I'm not really sure how to go about tweaking the design.

On 2007-07-21 07:35:17 +0000, Alec Holowka wrote:

this seems to make looping seamless for me, but i'm not sure how robust/solid it is.

hacky: not sure how to get at the real loop variable, etc. (always loops)

#define OGG_BUFFER_SIZE 4096
/* Read some Ogg stream data and convert it for output */
static void OGG_getsome(OGG_music *music)
{

int section;
int len;
char data[OGG_BUFFER_SIZE];
SDL_AudioCVT *cvt;

int looping = 1;
int total_len = 0;

while (total_len < OGG_BUFFER_SIZE)
{

#ifdef OGG_USE_TREMOR
len = vorbis.ov_read(&music->vf, data + total_len, OGG_BUFFER_SIZE - total_len, &section);
#else
len = vorbis.ov_read(&music->vf, data + total_len, OGG_BUFFER_SIZE - total_len, 0, 2, 1, &section);
#endif

  total_len += len;

  if(len <= 0)
  {
  	if(looping==1)
  	{
  		vorbis.ov_time_seek(&music->vf, 0);
  	}
  	else 
  	{
  		music->playing = 0;
  		return;
  	}
  }
  else
  {
  	break;
  }

}

On 2009-10-02 07:16:34 +0000, Sam Lantinga wrote:

This is fixed for the next release, thanks!

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2006-03-07 13:48:13 +0000, Patrice Mandin wrote:

SDL_mixer is meant to be a generic API to mix fx samples and music, but
there are two things in it that are missing (from my pov):

• the ability to define raw samples (i.e. not necessarily in one of
  supported sample formats, like wav, aiff, voc, etc..): it just needs a
  function where you pass a pointer to sample start, length, freq, format.

• the ability to play fx samples at the freq of the audio device,
  whatever the fx freq is (i.e. specially when not a multiple of audio
  device freq), like playing a 15KHz sample on a 48KHz device.
  (See https://bugzilla.libsdl.org/show_bug.cgi?id=58 for more info)

On 2006-05-07 13:34:02 +0000, Sam Lantinga wrote:

(In reply to comment # 0)

SDL_mixer is meant to be a generic API to mix fx samples and music, but
there are two things in it that are missing (from my pov):

• the ability to define raw samples (i.e. not necessarily in one of
  supported sample formats, like wav, aiff, voc, etc..): it just needs a
  function where you pass a pointer to sample start, length, freq, format.

You mean something like Mix_QuickLoad_RAW()?
The only difference here is that Mix_QuickLoad_RAW() assumes you've already converted the audio data to the output format, which IMHO is a good assumption - either you have pre-converted the data for efficiency, or your data is already all in the same format and you've opened the mixer with that format.

On 2006-05-07 13:38:03 +0000, Sam Lantinga wrote:

*** This bug has been marked as a duplicate of 58 ***

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: Other, All

Comments on the original bug report:

On 2008-05-02 16:18:01 +0000, Rene Dudfield wrote:

Seems the left and right channels are reversed in 8bit mode.

There is a test case which uses pygame at the url:
http://pygame.motherhamster.org/bugzilla/show_bug.cgi?id=9

cheers,

On 2009-10-03 02:58:39 +0000, Sam Lantinga wrote:

Ryan, can you take a look at this really quick? Thanks!

On 2009-10-10 10:06:07 +0000, Ryan C. Gordon wrote:

Fixed in svn revision # 5038.

--ryan.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• SDL_mixer-1.2.6-effect_position.patch (SDL_mixer-1.2.6-effect_position.p, text/plain, 2006-01-30 00:42:48 +0000, 25885 bytes)

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2006-01-30 00:41:43 +0000, Sam Lantinga wrote:

Date: Fri, 11 Mar 2005 07:57:35 +0100
From: David Ergo [email protected]
Subject: Re: [SDL] SDL_mixer bugs

Here is a patch to correct the 2 bugs and also other bugs.
Bug 1 (LFE channel saturated) has been corrected in a more generic way :

• args->lfe_u8 = 255;
• args->lfe_f = 255.0f;

• args->lfe_u8 = speaker_amplitude[5];
• args->lfe_f = ((float) speaker_amplitude[5]) / 255.0f;

Bug 2 has been corrected by adding code in _WIN32 "ifdef".

Other bugs corrected :

• in SetDistance(), SetPanning() and SetPosition(), if args where no-op
  but effect was not already registered then it was registered instead of
  doing a no-op.
• in SetPanning(), if left=right=255, it's a no-op so angle must be 0.
• there was some copy/paste errors in channel amplitudes (e.g. using
  left instead of left_rear, etc.)

On 2006-01-30 00:42:48 +0000, Sam Lantinga wrote:

Created attachment 53
SDL_mixer-1.2.6-effect_position.patch

Ryan, could you take a look at this patch, and apply it if it looks good? Thanks!

On 2006-01-30 00:44:36 +0000, Sam Lantinga wrote:

Here's a description of bug # 2 that's addressed by this patch:

2. Sound channels interverted under Windows

---

Windows DirectX doesn't use the same channels order as Linux ALSA.
For Linux ALSA, this is FL-FR-RL-RR-C-LFE
and for Windows DirectX, this is FL-FR-C-LFE-RL-RR
where FL = Front Left
FR = Front Right
RL = Rear Left
RR = Rear Right
C = Center
LFE = Low Frequency Effects
If you don't do any SetPosition()/SetPanning() there won't be any
problems I think because the channels data is not modified, but if you
do SetPosition() or SetPanning(), it will use C/LFE instead of RL/RR and
RL/RR instead of C/LFE, so the channels data will be messed up for
RL/RR/C/LFE.

On 2006-01-30 11:23:01 +0000, Ryan C. Gordon wrote:

Ugh, we really need a way at the SDL level to guarantee that speakers are in a sane order...we shouldn't have to add #ifdefs to apps and libraries for each audio target that wants to use a different order!

--ryan.

On 2006-01-31 09:10:56 +0000, Sam Lantinga wrote:

(In reply to comment # 3)

Ugh, we really need a way at the SDL level to guarantee that speakers are in a
sane order...we shouldn't have to add #ifdefs to apps and libraries for each
audio target that wants to use a different order!

I agree. Should we add an API query or fix an order and remap the channels in the SDL audio driver?

On 2006-01-31 10:46:25 +0000, Ryan C. Gordon wrote:

I agree. Should we add an API query or fix an order and remap the channels in
the SDL audio driver?

It would make sense, in the same way that we let people request/force other parameters in SDL_OpenAudio(). Alternately, we can treat it like we treat stereo audio now: it's always in the same order (even if, say, the audio driver under the hood doesn't want the audio interleaved, this is hidden from the app).

I'd be inclined to say for 1.2, more-than-stereo audio has to be in a well-defined format. Since ALSA can bend more than DirectSound on this one, I'd say favor the Windows format. SDL should convert behind the scenes if necessary.

1.3 can add a means to get/set the format to avoid the conversion, probably as part of the AudioSpec handed to SDL_OpenAudio, which would let the app either avoid the conversion overhead or avoid caring about it, much like they currently do with frequency or channel conversion.

How's that sound?

--ryan.

On 2006-01-31 12:53:47 +0000, Sam Lantinga wrote:

(In reply to comment # 5)

How's that sound?

That sounds great. :) ALSA, take it in the pants! :)

On 2006-05-01 06:53:25 +0000, Sam Lantinga wrote:

Ryan, I'd like to get this taken care of for SDL 1.2.10 and the next SDL_mixer release, if possible. I assume that everything besides the Win32 ifdefs in the patch should be applied to SDL_mixer?

Also, what needs to happen inside SDL to switch to Windows channel order?

On 2006-05-07 17:20:20 +0000, Sam Lantinga wrote:

I'd like to get this fixed for SDL 1.2.10 release, if possible.

On 2006-06-21 03:19:11 +0000, Ryan C. Gordon wrote:

*** Bug 247 has been marked as a duplicate of this bug. ***

On 2006-06-21 04:30:55 +0000, Sam Lantinga wrote:

It was mentioned in bug # 247 that Mac OS X also uses the Windows channel ordering.

On 2006-06-21 05:01:18 +0000, Ryan C. Gordon wrote:

That's makes it a no-brainer to make the change in ALSA, then. I need to read up on the API and see if you can change the order you feed it data, otherwise, we'll just have to swizzle the channels before feeding it through to the driver.

--ryan.

On 2006-06-21 05:09:40 +0000, Sam Lantinga wrote:

(In reply to comment # 11)

That's makes it a no-brainer to make the change in ALSA, then. I need to read
up on the API and see if you can change the order you feed it data, otherwise,
we'll just have to swizzle the channels before feeding it through to the
driver.
--ryan.

Sounds good. I bet ALSA has some option somewhere to control that...

On 2006-06-23 04:35:04 +0000, Ryan C. Gordon wrote:

Comment on attachment 53
SDL_mixer-1.2.6-effect_position.patch

Not patching SDL_mixer for this bug, but SDL instead, so I'm obsoleting this patch.

--ryan.

On 2006-06-23 04:36:09 +0000, Ryan C. Gordon wrote:

Potential fix is now in SDL (not SDL_mixer!) Subversion. I don't have a 5.1 setup to test it, so please try it and reopen this bug if I botched it.

--ryan.

On 2006-06-23 04:51:38 +0000, Sam Lantinga wrote:

Ryan, it looks like there were a couple other fixes in that patch, besides the 5.1 audio swizzle. Can you check to make sure they aren't needed?

On 2006-06-23 05:08:16 +0000, Ryan C. Gordon wrote:

Took the win32 bits out of the patch, committed the rest.

--ryan.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Fix audio buffer being freed in the wrong library. (Fix audio buffer being freed in the wrong library.patch, text/plain, 2010-07-19 15:21:45 +0000, 2093 bytes)

Reported in version: unspecified
Reported for operating system, platform: Other, x86

Comments on the original bug report:

On 2006-12-01 23:35:34 +0000, aki. wrote:

It crashes in SDL_FreeWAV(chunk->abuf)
when the OGG file is passed to Mix_LoadWAV_RW().

It can be fixed by inserting "memset(chunk, 0, sizeof(Mix_Chunk));"
before a comment of "/* Find out what kind of audio file this is */."

On 2006-12-19 14:55:25 +0000, Patrice Mandin wrote:

Fixed in svn, revision 2929

On 2006-12-19 23:21:19 +0000, aki. wrote:

Confirmed it.
Thanks for your work.

On 2007-02-13 02:55:23 +0000, Ryan C. Gordon wrote:

*** Bug 307 has been marked as a duplicate of this bug. ***

On 2010-07-19 15:21:45 +0000, Daniel Liptrot wrote:

Created attachment 523
Fix audio buffer being freed in the wrong library.

Sorry to hijack this bug, but I believe it may not be fixed from the problems I'm getting, which seems identical to the symptoms here. I wasn't sure whether to hijack this or file a new bug, as the bug is slightly larger in scope than what is reported here. Here is probably the best place.

The issue seems to be that the audio buffer is being freed in the wrong library. When sounds are played in the WAV or RIFF format, SDL_LoadWAV_RW() is called which is part of the SDL shared library, and the audio buffer is allocated there. Calling SDL_FreeWAV() then frees the buffer in that library. However, when other formats are played such as OGG, the audio buffer is allocated in the SDL_mixer library instead, and SDL_FreeWAV() is still called. This attempts to free the buffer in the wrong library as it is not allocated there. It can result in memory corruption and a possible memory leak as the audio buffer in the SDL_mixer library is not freed.

The bug is slightly larger in scope because a similar thing happens in Mix_FreeChunk(). This time, free() is used to free the audio buffer, which frees it in the SDL_mixer library. However, it also means if the WAV or RIFF format is used for the chunk, the audio buffer is freed in the wrong library and could result in memory corruption and a memory leak.

The fix for this would be to call the correct free function depending on which library the audio buffer was allocated. This seems to fix the crashes I've been getting.

This patch is what I've done to my working copy. It should work for both 1.2.11 and the latest hg revision as the line numbers are identical. It adds a new internal function which acts as a wrapper to call the correct free function for the audio buffer. The Mix_Chunk struct was also modified to store whether or not the audio buffer is allocated in the SDL shared library or not. It's an API change but one which should retain backwards compatibility with all software that uses SDL_mixer. Hopefully, that's classed as acceptable. :)

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• patch.diff (patch.diff, text/plain, 2006-01-27 02:25:02 +0000, 1204 bytes)

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2006-01-27 02:24:38 +0000, Sam Lantinga wrote:

Date: Sun, 23 May 2004 15:39:33 -0300
From: Emmanuel NM [email protected]
Subject: [SDL] SDL_Mixer - [Patch] A couple of new functions

Hi everyone,

I implemented 3 functions for the SDL_mixer library, in the file music.c

Mix_GetMusicPosition()  - Returns the current position in seconds.
Mix_FFMusic(seconds) -  Fast Forward in seconds from the current

position. Only for MP3 and OGG
Mix_RewMusic(seconds) - Rewind in seconds from the current position.
Only for MP3 and OGG.

apply the patch with : "patch music.c patch.diff".

Sorry about my English.
Let me know what you think

On 2006-01-27 02:25:02 +0000, Sam Lantinga wrote:

Created attachment 44
patch.diff

On 2006-01-27 11:23:28 +0000, Ryan C. Gordon wrote:

Setting Sam as "QA Contact" on all bugs (even resolved ones) so he'll definitely be in the loop to any further discussion here about SDL.

--ryan.

On 2009-10-03 02:03:00 +0000, Sam Lantinga wrote:

These functions aren't as precise as you might expect, but we might be able to use SDL_GetTicks() to improve precision.

Thanks!

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: Mac OS X 10.4 (Intel), PowerPC

Comments on the original bug report:

On 2008-05-02 16:25:02 +0000, Rene Dudfield wrote:

Looping midi crashes on OSX.

1 com.apple.audio.CoreAudio 0x91476d9a
IOA_Device::CallIOProcs(AudioTimeStamp const&, AudioTimeStamp const&,
AudioTimeStamp const&) + 274
2 com.apple.audio.CoreAudio 0x91476b21
HP_IOThread::PerformIO(AudioTimeStamp const&) + 1299
3 com.apple.audio.CoreAudio 0x91474f49 HP_IOThread::WorkLoop() +
953
4 com.apple.audio.CoreAudio 0x91474b8b
HP_IOThread::ThreadEntry(HP_IOThread*) + 17
5 com.apple.audio.CoreAudio 0x91469171 CAPThread::Entry(CAPThread*)

• 93
  6 libSystem.B.dylib 0x90024227 _pthread_body + 84

Here's a test case which uses pygame here:
wget http://209.197.86.65/19841988/rock/beatles/ISawHerStandingThere.mid
wget http://rene.f0o.com/~rene/stuff/midi.py
python midi.py ISawHerStandingThere.mid

On 2008-05-04 16:19:30 +0000, Rene Dudfield wrote:

Updated the OS to mac osx 10.4 intel.

Also updated the Severity to critical since it's a crash bug.

On 2009-09-26 02:18:05 +0000, Sam Lantinga wrote:

Ryan, can you look at this? Thanks!

On 2009-10-03 02:05:43 +0000, Sam Lantinga wrote:

This might be fixed with the last checkin, which fixed memory corruption problems.

Can you retest with current subversion?

You'll probably need to edit configure.in to re-enable darwin native MIDI which doesn't build on Mac OS X 10.5+

On 2009-10-10 23:50:18 +0000, Sam Lantinga wrote:

The Mac OS X midi support needs to be completely rewritten for CoreAudio, which will hopefully take care of this issue.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2006-02-06 14:32:19 +0000, Bill Kendrick wrote:

Differences between OSes, versions of OSes, and audio hardware has meant that the chunk size we programmers pick are occasionally not suitable for some users (e.g., they get staticy or stuttering sound... or much more sound latency than necessary).

It would be nice if there were an environment variable that SDL_mixer could check for which allowed users to specify the best value for their system (without every SDL-based program having to provide some config. or command-line method for setting it).

In otherwords, similar to how we have SDL_VIDEODRIVER and SDL_AUDIODRIVER, we could have SDL_MIXERCHUNKSIZE. Mix_OpenAudio() could than accept a 'special' value which tells it to use the user's preferred chunk size (or some default), just as SDL_Init() uses the user's preferred video driver (or some default).

Thanks! :)

On 2006-05-09 04:56:15 +0000, Sam Lantinga wrote:

In the SDL subversion code today:
If SDL_OpenAudio() is passed zero for the desired format
fields, the following environment variables will be used
to fill them in:
SDL_AUDIO_FREQUENCY
SDL_AUDIO_FORMAT
SDL_AUDIO_CHANNELS
SDL_AUDIO_SAMPLES
If an environment variable is not specified, it will be set
to a reasonable default value.

Since SDL_mixer passes it's parameters straight through to SDL, all you have to do is specify zero for the appropriate parameter. You should probably make sure you're linking with a new enough version of SDL at runtime though. :) See SDL/test/testver.c for an example of how to check the runtime version of SDL.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: Mac OS X (All), PowerPC

Comments on the original bug report:

On 2006-01-03 12:13:10 +0000, Ryan C. Gordon wrote:

Date: Sun, 13 Nov 2005 15:20:42 +0100 (CET)
From: "Torsten Giebl" [email protected]
To: [email protected]
Subject: [SDL] SDL_mixer problem on Mac OSX

Hello !

When using the latest SDL_mixer CVS version on Mac OSX
i get no sound output, whether playing a MP3 file or a
MOD file. SDL_mixer 1.2.6 works without any problems.

On windows the latest SDL_mixer CVS verion works without problems.

System:

Latest Mac OSX Tiger version
Latest stable XCode and Dev. Tools
Latest SDL CVS version and helper Libs.

loopwave from SDL CVS works.

So there are any changes from SDL_mixer 1.2.6 to latest SDL_mixer
CVS that made that no sound is played.

CU

On 2006-01-03 12:13:44 +0000, Ryan C. Gordon wrote:

This may or may not be a dupe of Bug # 19.

--ryan.

On 2006-01-19 06:28:23 +0000, Ryan C. Gordon wrote:

Tossing the SDL_mixer bugs to Sam (all three of which might be the same bug in practice)...if you don't want these, toss them back to me.

--ryan.

On 2006-01-27 11:23:04 +0000, Ryan C. Gordon wrote:

Setting Sam as "QA Contact" on all bugs (even resolved ones) so he'll definitely be in the loop to any further discussion here about SDL.

--ryan.

On 2006-01-31 15:45:01 +0000, Eric wing wrote:

Yes, I think this is a dup with respect to Mikmod.

MP3 seems to be a different "problem" entirely. I looked over the current Xcode projects and I think the reason for the MP3 failure is the fact that we don't compile the support in with the proper flags. MP3 seems to dependent on SMPEG. But unlike some of the other dependencies, we don't have any static libraries or code of SMPEG included in the OS X bundle. That means we would need to dynamically link to it, but I'm not sure if we want to incur that dependency, especially since SMPEG seems to be somewhat in a state of neglect.

I'm not sure why 1.2.6 had MP3 support or how it got it and why it disappeared now. Since I've been the primary mucker of the Project Builder/Xcode build systems after Darrell Walisser, It seems like this would have been something I would have to explicitly done to remove, but I have no recollection of this.

I might take a crack at trying to update SMPEG for the current Xcode and Universal Binaries, but it's all time permitting.

On 2006-04-30 23:26:25 +0000, Sam Lantinga wrote:

This is fixed in the latest SDL_mixer in subversion, and the latest smpeg in CVS.
svn://libsdl.org/trunk/SDL_mixer
http://www.icculus.org/smpeg/

Thanks!

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 1.2.8
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2008-02-25 09:31:22 +0000, Pacho Ramos wrote:

From http://qa.mandriva.com/show_bug.cgi?id=37235 (also some references to https://bugzilla.redhat.com/show_bug.cgi?id=343911 )

Playing xmoto some cracks in the sound are noticed, using SDL_AUDIODRIVER=esd for SDL apps/games "fixes" this problem. Easiest way to notice is with the start screen background music, but also easily noticed while playing.

Other people has noticed the same issue when when pulseaudio is trying to resample and the system isn't powerful enough and playing chromium

The problem with the exact workaround can be heard while playing wesnoth also.

Thanks a lot

On 2008-07-18 23:52:56 +0000, Jeremy Visser wrote:

This issue is caused by the buffering issues mentioned in bug # 572. Marking as a duplicate (even though this bug came first, # 572 contains the patch).

*** This bug has been marked as a duplicate of bug 572 ***

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: Mac OS X 10.4 (PPC), PowerPC

Comments on the original bug report:

On 2007-03-06 10:18:40 +0000, Tim Wojtulewicz wrote:

I'm not sure if this is a problem in SDL or in SDL_Mixer, but I noticed it when building mixer. The software builds ok (minus a minor header file change due to SDL_byteorder.h deletion), but when it goes to link I get the following:

ld: Undefined symbols:
_CloseComponent
_DisposePtr
_NewPtrClear
_OpenDefaultComponent
/usr/bin/libtool: internal link edit command failed
make: *** [build/libSDL_mixer.la] Error 1

All of those symbols are defined in the CoreServices framework. Adding -Wl,-framework,CoreServices to the Makefile after it includes the QuickTime framework fixes the error.

On 2007-07-03 03:44:38 +0000, Ryan C. Gordon wrote:

The SDL_byteorder.h issue is fixed in svn revision # 3129.

The missing CoreServices symbols are fixed in svn revision # 3130.

Thanks!

--ryan.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2006-01-31 09:18:34 +0000, Sam Lantinga wrote:

Date: Mon, 07 Mar 2005 23:41:22 +0100
From: Andreas Hartmetz [email protected]
Subject: [SDL] "unexpected behaviour" in Mix_OpenAudio

Hi list!

I am having problems with doom-legacy for SDL. The music plays nicely
but the sfx are playing much too fast/high-pitched: sampling rate
mismatch...
When I looked into the source to find the cause of it, I found something
that might introduce the error but at least hides bugs in SDL-using
programs/games:

in Mix_OpenAudio:

/* Open the mixer with a certain desired audio format */
int Mix_OpenAudio(int frequency, Uint16 format, int nchannels, int
chunksize)
{
int i;
SDL_AudioSpec desired;

    /* If the mixer is already opened, increment open count */
    if ( audio_opened ) {
        ++audio_opened;
        return(0);
    }

(....)

if a Mixer has already been opened with paramter set A and I try to open
another one with parameter set B, Mix_OpenAudio will happily say "you
already opened audio with parameter set B, go ahead", which is wrong.

Regards, Andreas

On 2006-04-30 23:35:20 +0000, Sam Lantinga wrote:

This is fixed in subversion, thanks!

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Thats the sound of Super Mario War I hear. (problem.ogg, application/ogg, 2006-07-06 13:50:32 +0000, 53562 bytes)

Reported in version: unspecified
Reported for operating system, platform: Windows (XP), x86

Comments on the original bug report:

On 2006-07-06 13:33:39 +0000, Michael Schaffer wrote:

When playing Super Mario War - using SDL_Mixer 1.2.6, there are sound artifacts when using a Creative Soundblaster Audigy LS (SE) sound card (with the sound latest drivers). These artifacts are also present with the Frozen Bubbles game, which leads us to believe this is an SDL_Mixer issue.

On 2006-07-06 13:50:32 +0000, Markus wrote:

Created attachment 145
Thats the sound of Super Mario War I hear.

Help plz

On 2006-07-06 13:53:53 +0000, Markus wrote:

Comment on attachment 145
Thats the sound of Super Mario War I hear.

I suppose its actually not a problem of my soundcard itself because it worked fine months ago. According to that assumption it has to be a software problem.

On 2006-07-06 16:57:32 +0000, Markus wrote:

Comment on attachment 145
Thats the sound of Super Mario War I hear.

I also reinstalled all my audio drivers (at least all I was able to find), still I wasnt able to solve the problem.

On 2006-07-06 17:17:43 +0000, Sam Lantinga wrote:

Try grabbing SDL 1.2.10 and 1.2.11 and see if either one works better:
http://www.libsdl.org/release/SDL-1.2.10-win32.zip
http://www.libsdl.org/release/SDL-1.2.11-win32.zip

On 2006-07-07 11:27:01 +0000, Markus wrote:

(In reply to comment # 4)

Try grabbing SDL 1.2.10 and 1.2.11 and see if either one works better:
http://www.libsdl.org/release/SDL-1.2.10-win32.zip
http://www.libsdl.org/release/SDL-1.2.11-win32.zip

1.2.11 solves the problem, though it wont help in cases like frozen bubble becaues i cant replace the sdl.dll can i?

On 2006-07-07 13:39:33 +0000, Markus wrote:

I found out that by replacing the sdl.dll in the windows/system32 directory I am able to solve the problem. There will be only difficulties when people do integrate the sdl.dll into their games.

On 2006-07-08 01:23:45 +0000, Sam Lantinga wrote:

(In reply to comment # 5)

(In reply to comment # 4)

Try grabbing SDL 1.2.10 and 1.2.11 and see if either one works better:
http://www.libsdl.org/release/SDL-1.2.10-win32.zip
http://www.libsdl.org/release/SDL-1.2.11-win32.zip

1.2.11 solves the problem, though it wont help in cases like frozen bubble
becaues i cant replace the sdl.dll can i?

Yes, you can. SDL 1.2 is binary backwards compatible. Glad to hear it's fixed!

On 2006-07-08 04:27:10 +0000, Markus wrote:

Will sdl.dll games in the future require sdl replacement or will their sdl's be fixed so that I and everyone else wont have problems like that?