SDL_gui revival?

Michael_Toennies · October 28, 2002, 7:48am

I have found a bug in the SDL_mixer, using Mix_FadeOutMusic().

I use in Daimonin small ambient infinitive loop sounds for different
maps - if you change a map, the new ambient sound is loaded and the
old one fades out.

Used with Mix_HookMusicFinished() and the callback function, all works
fine - the callback init after the fadeout the new music.

The bug happens when you have small music files (i use ogg files) and a
large fade out value - i use 4000 ms for a smooth fade.

If the sound file is finished playing (and then looped again from the
sdl_mixer engine) BEFORE the 4000ms from the fade command are done, the
sound file is looped and played and the Mix_FadeOutMusic() will fail.
Means, the callback command will never be called.

This is really bad, because the Mix_FadeOutMusic() means “fade out and end”.

I assume that the callback is called when fadeout is done OR the file has
ended.
This is a really important point, because you will need ALOT of control and
extra
code when fadeout can fail without warnings.

I compiled the cvs version too, the bug is still in.

Compiling the cvs, i noticed that the VisualC files are outdated.
In SDL_mixer project part the files load_ogg.c and load_ogg.h are not
included
and the link will break with a unresolved symbol error.

Also, i got 2 warnings in load.ogg.c about implicit conversion from _int64
to
int in line 46 and 108 - it seems these are file length values, so perhaps
with
REALLY long files the player will break - i gave it only a quick look, so
perhaps its uncritical.

BTW, i had changed from smpeg to sdl_mixer/ogg for my background music.
Having
native support of a heavy compression file format in the mixer is a major
step
for SDL and i am very impressed about the easy interface.

SMPEG is now more as 15 month not updated, the last release 0.4.4 is broken
(loop don’t work, you need to use 0.4.3 when you want loop a mp3) and the
interface is ugly and imcomplete.

Perhaps it is time to include a native mp3 play in the mixer too?

Pete_Shinners · October 28, 2002, 8:41am

Michael Toennies wrote:

SMPEG is now more as 15 month not updated, the last release 0.4.4 is broken
(loop don’t work, you need to use 0.4.3 when you want loop a mp3) and the
interface is ugly and imcomplete.

not sure if it matters, but i’ve noticed the CVS repository for SMPEG on
icculus.org gets occasional updates.

http://icculus.org/smpeg/

many files haven’t been touched in 2-3 years, but it appears there was an
update to gcc-3.2 about four weeks ago.
http://cvs.icculus.org/horde/chora/co.php/CHANGES?rt=smpeg&r=1.130

i’m not sure if there are any plans for a new release, it’s certainly been
awhile, but i’m not sure who the official maintainer would be?

icculus · October 28, 2002, 9:28am

I assume that the callback is called when fadeout is done OR the file
has ended. This is a really important point, because you will need
ALOT of control and extra code when fadeout can fail without warnings.

I will take a look at this.

SMPEG is now more as 15 month not updated, the last release 0.4.4 is broken
(loop don’t work, you need to use 0.4.3 when you want loop a mp3) and the
interface is ugly and imcomplete.

I accept patches for SMPEG. The lokigames.com fork is dead. The
icculus.org fork is just there for maintainance patches at this moment,
since there isn’t anyone to do active development on it. My backburnered
TODO list for SMPEG is really more like non-trivial maintainance patches
than enhancements, too.

Patches and development volunteers are welcome.

Perhaps it is time to include a native mp3 play in the mixer too?

It will be. The SDL_mixer rewrite will use SDL_sound for decoding, which
gives you either decoding externally through SMPEG or internally (that is,
the source is part of SDL_sound) through a variant of mpglib (which was
originally part of mpg123). Both have merits and flaws for this task.

–ryan.

icculus · October 28, 2002, 9:29am

i’m not sure if there are any plans for a new release, it’s certainly been
awhile, but i’m not sure who the official maintainer would be?

I’m not a maintainer so much as a life-support system.

Anyone who wants to do some SMPEG development; please drop me a line.

–ryan.

icculus · October 30, 2002, 4:15am

If the sound file is finished playing (and then looped again from the
sdl_mixer engine) BEFORE the 4000ms from the fade command are done,
the sound file is looped and played and the Mix_FadeOutMusic() will
fail. Means, the callback command will never be called. This is really
bad, because the Mix_FadeOutMusic() means “fade out and end”.

I have just committed a possible fix to CVS for this; can you please try
it and see if it fixes your problem?

–ryan.

Michael_Toennies · October 30, 2002, 10:39am

If the sound file is finished playing (and then looped again from the
sdl_mixer engine) BEFORE the 4000ms from the fade command are done,
the sound file is looped and played and the Mix_FadeOutMusic() will
fail. Means, the callback command will never be called. This is really
bad, because the Mix_FadeOutMusic() means “fade out and end”.

I have just committed a possible fix to CVS for this; can you please try
it and see if it fixes your problem?

Yes, it seems to fix it. Now the fade triggers even the sound file loop
before
the fade has timed.

Thx!
michtoen

icculus · October 30, 2002, 12:36pm

Yes, it seems to fix it. Now the fade triggers even the sound file
loop before the fade has timed.

Cool.

–ryan.

Tyler_Montbriand · October 30, 2002, 7:58pm

Roy Wood wrote:

Alexander Pipelka wrote:

Maybe a better approach would be to help with existing projects ?

Reinventing the wheel may be fun but isn’t very productive.

What Alexander is hinting at is the fact that there is a nice SDL-based
GUI already. Take a look at ParaGUI:
 http://www.paragui.org/
Alexander is the creator/maintainer of ParaGUI, hence the modesty.

-Roy

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Problem with SDL_Gui is it requires iostream… won’t run under WinCE, for
starters.

David_Ergo · March 3, 2005, 9:08am

I have found two bugs in SDL_mixer v.1.2.6 in 5.1 surround mode :

LFE channel saturated------------------------
The LFE channel gets saturated, because it’s erroneously multiplied by
255 in SetPosition() function.
To correct this, edit effect_position.c, at line 1551, replace
args->lfe_f = 255.0f;
by
args->lfe_f = 1.0f;
Actually under Windows, it’s the rear right channel that gets saturated
because of the bug number 2 here under.
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.
I’ll try to make a patch for this.

David Ergo
Alterface s.a.

David_Ergo · March 11, 2005, 6:57am

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.)

DavidOn Thu, 2005-03-03 at 10:08, David Ergo wrote:

I have found two bugs in SDL_mixer v.1.2.6 in 5.1 surround mode :

LFE channel saturated

The LFE channel gets saturated, because it’s erroneously multiplied by
255 in SetPosition() function.
To correct this, edit effect_position.c, at line 1551, replace
args->lfe_f = 255.0f;
by
args->lfe_f = 1.0f;
Actually under Windows, it’s the rear right channel that gets saturated
because of the bug number 2 here under.

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.
I’ll try to make a patch for this.

David Ergo
Alterface s.a.

-------------- next part --------------
A non-text attachment was scrubbed…
Name: SDL_mixer-1.2.6-effect_position.patch.gz
Type: application/x-gzip
Size: 2461 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20050311/37858445/attachment.bin

Greg_Lee · March 12, 2005, 2:42am

It’s great news that the 5.1 Windows interface works, now. Thanks
for fixing it.

David Ergo wrote:

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”.

Is that #ifdef in the Windows audio driver, so that it gets the channel
order right for all SDL output? Including midi?

Greg

David_Ergo · March 14, 2005, 10:52am

Greg Lee wrote:

It’s great news that the 5.1 Windows interface works, now. Thanks
for fixing it.

Is that #ifdef in the Windows audio driver, so that it gets the channel
order right for all SDL output? Including midi?

No the patch is for SDL_mixer, not the Windows audio driver.
SDL doesn’t handle audio channels in a particular way, only SDL_mixer does.
I never used midi and I even don’t know if 5.1 is supported in midi…

David

Greg_Lee · March 14, 2005, 1:28pm

David Ergo wrote:

Greg Lee wrote:

It’s great news that the 5.1 Windows interface works, now. Thanks
for fixing it.

Is that #ifdef in the Windows audio driver, so that it gets the channel
order right for all SDL output? Including midi?

No the patch is for SDL_mixer, not the Windows audio driver.
SDL doesn’t handle audio channels in a particular way, only SDL_mixer
does.

No, both SDL and SDL_mixer know about 5.1 and 4.0 sound, and the
Alsa interpretation of 5.1 channel order is built in to SDL as well as
SDL_mixer.

I never used midi and I even don’t know if 5.1 is supported in midi…

It is. And it is also supported for .ogg, .mp3, .wav, and mod files
(though the
.mp3 and mod support is faked by copying channels). And all the support
assumes Alsa channel order (except for 6 channel .ogg and .wav files which
are played in 5.1).

Greg