Hi,
I'd build scummvm 0.10.0 for my WinCE/MIPS machine. (PMP)
It works fine for most of games, but the 'Full Throttle'(FT) and 'Monkey3'(COMI) has a problem.
Both games play sound pretty well, except the sound played by IMuseDigital::startSound functions does not working.
The sound played by above functions seems doest not working. The other sounds are working well.
Because of this problem, the games doesn't work.
The infinite loop occurs at following code. (IMuseDigital::startSound functions)
while (track->used) {
// The designated track is not yet available. So, we call flushTracks()
// to get it processed (and thus made ready for us). Since the actual
// processing is done by another thread, we also call parseEvents to
// give it some time (and to avoid busy waiting/looping).
flushTracks();
#ifndef __PLAYSTATION2__
_vm->parseEvents();
#endif
}
At PC version of scummvm, both games works fine.
I tried to track down this bug during last 5 days, but I can't figure out what is problem.
If I skip above loop try to avoid infinite loop, the following errors occured.
IMuseDigital::startSound() Can't start sound - no free slots
Assertion failed trackId != -1 (..\..\..\engines\scumm\imuse_digi\dimuse_track.cpp, 61)
I need help to solve this problem and wish to find out soon.
Many thanks in advance and regards.
Development Env: Visual Studio 2005/Standard CE SDK 5.0
Windows CE 5.0 / RMI Alchemy Au1200 (MIPS) / 800x480x32 LCD
Lib: Using SDL, libmpeg2.lib, zlib.lib, libflac.lib, libmad.lib, libTremor.lib
(Ported by myself)
Need Help with WinCE Sound Problem (FT/COMI)
Moderator: ScummVM Team
First of all, thanks for your attention
Regarding SDL, I ported SDL 1.2.11 % 1.2.12 for WinCE/MIPS.
1.2.11 using windib for Video and 1.2.12 uses DirectX of wince (Customized source based on DirectX for win98/2000)
WinCE does not support DirectInput, so I use windib_event instead of DirectInput.
And for the sound, both SDL use windows midi (windib).
The problem mentioned above is happens with both SDL.
Could be a mistake of SDL porting.
Something I can't understand is why some of sounds are working good and only sound thru the particular function does not working.
BTW, I don't think this is a issue, but I'm Korean...So the games (FT/COMI) and WinCE Device & development tool is Korean Version. I don't think this cause any problem.
Regarding SDL, I ported SDL 1.2.11 % 1.2.12 for WinCE/MIPS.
1.2.11 using windib for Video and 1.2.12 uses DirectX of wince (Customized source based on DirectX for win98/2000)
WinCE does not support DirectInput, so I use windib_event instead of DirectInput.
And for the sound, both SDL use windows midi (windib).
The problem mentioned above is happens with both SDL.
Could be a mistake of SDL porting.
Something I can't understand is why some of sounds are working good and only sound thru the particular function does not working.
BTW, I don't think this is a issue, but I'm Korean...So the games (FT/COMI) and WinCE Device & development tool is Korean Version. I don't think this cause any problem.
Yes, it seems quite likely it's SDL's fault and unfortunately I cannot comment on what might be going wrong, except my general-feeling-post above.cybercop wrote: Could be a mistake of SDL porting.
Highly unlikely.cybercop wrote: BTW, I don't think this is a issue, but I'm Korean...So the games (FT/COMI) and WinCE Device & development tool is Korean Version. I don't think this cause any problem.
FYI, I upload 2 video clips of scummvm running on WinCE device.
First one is a 'Monkey3'(COMI) with problem and second one is a 'Broken Sword 1' without problem.
http://cafe.naver.com/s43user/38887
(Should be no problem to see the article, but if you can't see...let me know.)
The same SDL used for DOSBOX 0.71 and GnGeo(NEOGEO Emulator) on same machine. So far no trouble with sound.
I'm still don't know where to dig...
First one is a 'Monkey3'(COMI) with problem and second one is a 'Broken Sword 1' without problem.
http://cafe.naver.com/s43user/38887
(Should be no problem to see the article, but if you can't see...let me know.)
The same SDL used for DOSBOX 0.71 and GnGeo(NEOGEO Emulator) on same machine. So far no trouble with sound.
I'm still don't know where to dig...
Hi,
I found the reason of the problem. (at last )
As knakos mentioned above, it was timer & SDL problem.
I'm not sure how the ARM version of SDL is working.
(I guess a bit cutomized version.)
Anyway the bug(?) is as followed.
wince-sdl.cpp Original code from 0.10.0
void OSystem_WINCE3::initBackend()
{
// Instantiate our own sound mixer
// mixer init is postponed until a game engine is selected.
if (_mixer == 0) {
_mixer = new Audio::Mixer();
}
//#### Added ####
//Normal SDL need SDL_INIT_TIMER before SDL_SetTimer
uint32 sdlFlags = SDL_INIT_TIMER;
if (SDL_Init(sdlFlags) == -1) {
error("Could not initialize SDL: %s", SDL_GetError());
}
//#### Added ####
// Create the timer. CE SDL does not support multiple timers (SDL_AddTimer).
// We work around this by using the SetTimer function, since we only use
// one timer in scummvm (for the time being)
_timer = _int_timer = new DefaultTimerManager();
_timerID = NULL; // OSystem_SDL will call removetimer with this, it's ok
SDL_SetTimer(10, &timer_handler_wrapper);
// Chain init
OSystem_SDL::initBackend();
...
The wince-sdl try to set timer without pre-init process.
That's why the timer was NOT created, and furthermore
It doesn't report any error in case fail to set timer.
So, the whole timer call-back of scummvm doest not working and the IMuseDigital::timer_handler() function can't takes
control.
After add few lines (marked #### added ####), the problem is solved.
I'm not used to use bug tracking system in SourceForge and don't know this could be problem in general build.
So, I decide put this post on here.
It would be great to apply this little change to WinCE port of scummvm.
Regards,
cybercop
I found the reason of the problem. (at last )
As knakos mentioned above, it was timer & SDL problem.
I'm not sure how the ARM version of SDL is working.
(I guess a bit cutomized version.)
Anyway the bug(?) is as followed.
wince-sdl.cpp Original code from 0.10.0
void OSystem_WINCE3::initBackend()
{
// Instantiate our own sound mixer
// mixer init is postponed until a game engine is selected.
if (_mixer == 0) {
_mixer = new Audio::Mixer();
}
//#### Added ####
//Normal SDL need SDL_INIT_TIMER before SDL_SetTimer
uint32 sdlFlags = SDL_INIT_TIMER;
if (SDL_Init(sdlFlags) == -1) {
error("Could not initialize SDL: %s", SDL_GetError());
}
//#### Added ####
// Create the timer. CE SDL does not support multiple timers (SDL_AddTimer).
// We work around this by using the SetTimer function, since we only use
// one timer in scummvm (for the time being)
_timer = _int_timer = new DefaultTimerManager();
_timerID = NULL; // OSystem_SDL will call removetimer with this, it's ok
SDL_SetTimer(10, &timer_handler_wrapper);
// Chain init
OSystem_SDL::initBackend();
...
The wince-sdl try to set timer without pre-init process.
That's why the timer was NOT created, and furthermore
It doesn't report any error in case fail to set timer.
So, the whole timer call-back of scummvm doest not working and the IMuseDigital::timer_handler() function can't takes
control.
After add few lines (marked #### added ####), the problem is solved.
I'm not used to use bug tracking system in SourceForge and don't know this could be problem in general build.
So, I decide put this post on here.
It would be great to apply this little change to WinCE port of scummvm.
Regards,
cybercop
SDL_Init(SDL_INIT_TIMER) is called from the base class method (OSystem_SDL::initBackend() call at the end of OSystemWINCE3::initBackend). But, you are correct, init should be done before calling SDL_SetTimer.
Obviously, since you get consistent behavior of no audio and since I get a consistent behavior of full audio, this is not an issue of a race condition. Rather SDL 1.2.6 which we're using has a more "relaxed" requirement for SetTimer than the newer versions of SDL. I will correct the semantics of this in the SVN as you report.
Thanks,
Kostas
Obviously, since you get consistent behavior of no audio and since I get a consistent behavior of full audio, this is not an issue of a race condition. Rather SDL 1.2.6 which we're using has a more "relaxed" requirement for SetTimer than the newer versions of SDL. I will correct the semantics of this in the SVN as you report.
Thanks,
Kostas