I’ve got the following configuration:
– FModCe 3.72 (preview)
– Yakumo Delta (200MHz, about 20MB RAM free)
– SD-Card (Cytronix, quite slow)
With this, I sometimes get problems. FMod seems to be grabbing almost all of the CPU – sometimes my applications updates the song position only every 20-30 seconds, sometimes it won’t even respond to closing or switching off the device. If I do an FSOUND_Close() (given it’s still possible), the system revives, but even the Close itself lasts up to ~ 15 seconds – or hangs the system finally.
The memory usage seems to remain constant – at least that’s what IcBar or Wisbar Advance’s memory monitor shows me.
The playback isn’t interrupted.
The problem occurs far more often when I use my player in the car, where it’s attached to a GPS mouse (though no nav. system is running) and power.
Another user wrote me he gets similar problems when he’s using a MicroDrive.
Is it possible FModCe spawns new threads, increases its priority or s.th. like that when it gets problems continuing a stream? Or may it be that other informations (serial data from my GPS mouse or whatever from the MicroDrive) are disturbing FMod’s routines?
- Mort asked 13 years ago
Sorry to bother you again…
The problem returned again. It happens after a long track (e.g. an audio book) is played from a MicroDrive (another one this time, and this one isn’t known for problems). One of the Stream_Stop, Stream_Close or Close seems to hang up. When my device hung because of ActiveSync+GPS-Signals, it’s been the FSOUND_Close, I guess it’s the same here. Letting FModCe keep running just moved the hang up to some later, seemingly random time.
Increasing the buffer size seems to downsize the problem, but it doesn’t vanish completely.
I think there’s something going wrong if there’s a buffer underrun. Since hard disks need some access time, there’s probably quite a high risk of it. I only wonder why the playback seems to be without problems and only afterwards closing FMod will cause hang ups.
Maybe you could offer a debug version, where it’s possible to get an assertion message instead of just a hanging system?
OK, “some” debugging and testing later…
I’ve found some things which aren’t your responsibility – ActiveSync trying to make something of the data from the GPS mouse, FindFile handle wasn’t closed sometimes, and such…
In many cases, this seems to have been it.
But still there remain some problems. At some moment in time the songs just aren’t played. Sometimes it just does seemingly nothing, sometimes it sounds like the start of an old vinyl (repeaded crackling). There’s no error return code in any case. My beta testers and me can’t find any regularity. It doesn’t seem to be attached to the song. There are just few “rules”: It doesn’t happen at the first song (maybe coincidence?), it occurs far later when there’s less CPU usage (lower mix rate, mono mixer, …), and with one user, it only occurs when he’s playing songs from his MicroDrive (even with very low sound quality – only later than with good quality).
Maybe there’s something wrong in the way I use FMod? My player does the following (simplyfied, x are user selectable data):
– FSOUND_Init(x, 4, FSOUND_INIT_GLOBALFOCUS)
– FSOUND_Stream_Open( x, x, 0, 0 ); (mode is FSOUND_HW2D, optionally combined with FSOUND_MPEGHALFRATE)
– FSOUND_Stream_PlayEx(FSOUND_FREE, stream, NULL, TRUE)
– FSOUND_Stream_SetVolume( channel, x )
– FSOUND_Stream_GetNumTagFields(…) + some FSOUND_Stream_GetTagField(…)s (for the most common ID3 tags)
– FSOUND_Stream_GetLengthMs( stream )
– FSOUND_Stream_SetPaused( stream, FALSE );
– several FSOUND_Stream_GetTime( stream ) in a timer
– end callback sets a flag (to avoid problems with multithreading)
– if the flag is set in the timer loop:
– FSOUND_Stream_Stop( stream )
– FSOUND_Stream_Close( stream )
Starting the playback in paused mode and then “continuing” after some ms is for setting the channel volume without having too loud first milliseconds and to give FMod some time to fill the buffer (maybe it’s not necessary with the newer versions, but I got “stutter” without it formerly).
“Resetting” (Close/Init) the FMod library was implementet for the following reasons:
– No more problems with buggy iPAQs after turning off and on in stopped mode
– Some devices had a low noise when FMod was opened while nothing was played (I guess opening the sound device alone causes this…)
– I hoped it might help, if there’s something wrong with closing streams or memory allocation (well, doesn’t seem like it…)
[quote="brett":27g3w2dj]well one thing i can see is that your mixer setting is being ignored because you’re supposed to set it before calling fsound_init not after.[/quote:27g3w2dj]
Oops, didn’t see that… I’ll change it.
[quote="brett":27g3w2dj]did you try the zip i mentioned?[/quote:27g3w2dj]
Yes. Usualy the version from WCE\ARM, the user with the microdrive problems also tried the one from WCE4\ARMV4 (which I think is the WM2003 version).
btw: What’s the difference between those two DLLs? The one in wce\arm seems to work quite fine on WM2003 devices, too.
[quote="brett":27g3w2dj]It sounds like the file access isnt working properly, which if coming from a microdrive (i dont even know what that is except by guessing it is some pcmcia type harddisk or flashcard or something) then it sounds likely.[/quote:27g3w2dj]
A microdrive is a harddisk in CF media format (don’t how how they manage to get a disk and heads into such a thin media, but they do…).
And by now it seems VERY likely. The user’s done some research and found there are several problems with his drive in PPCs, although the manufactorer even listed his device in a compatibility list.
Well, thanks for your help anyway.
- Anonymous answered 13 years ago
Please login first to submit.