|
Originally Posted by Vanamonde
|
|
No it happens all the time, with WMP, Betaplayer and GS Player.
|
Sure, it's a quite stable situation on every single device.
But whether the error occurs or not on a device is a lottery game. It depends on how fast the system wakes up and when the resumed program tries to access the sound device or storage card. There are a lot of influencing factors here: the device's performance, the drivers, modifications to the system (WM is licensed as open source to the manufacturers, which leads to several compatibility problems, too. Esp. iPaqs are a pain in the *** with those modifications...), shutdown time in the program, ...
|
Quote:
|
|
Plus they have no problem initialising the sound hardware because the portion of sound file left in the cache plays back perfectly it's only when the program tries to read the rest of the file off the SD card that it craps out.
|
The SD access shouldn't be the problem. Most programs handle this quite fine, and simply try to continue with the next track (for programmers, there's no big difference between end of file and read errors).
I don't know exactly what's going wrong in these cases, since I don't have the WM code (nor wan't to debug it if I had...

).
Maybe it's got something to do with the storage card driver. But a bug in some older iPaqs seems to point at the sound driver: After power on, the sound continued a few milliseconds, and then the sound driver hung up. I.e., no sound at all in all applications until a soft reset...
|
Quote:
|
|
Also people have reported that IPAQs don't suffer from this problem, if true it cannot be an o/s bug but a hardware bug in Axims.
|
It's more of a combination... It's Axim's "fault" the driver initialization causes troubles when the sound driver (or storage card?) is accessed while this initialization happens. But it's Microsoft's fault these possible conflicts can happen at all. Maybe HP/Compaq even programmed a patch for this WM problem to fix the troubles they once had once and for all...