Mod Archive Forums

Music Production => MilkyTracker => Tracking => MilkyTracker Bug Reports => Topic started by: starknight on April 21, 2008, 11:01:45

Title: [workaround only] Windows Mobile 6 bug ?
Post by: starknight on April 21, 2008, 11:01:45
Hi,

I'v tried the latest version on my HTC TyTN II smartphone (WM6, Italian ROM) and it works well until I quit... then it completely hangs my phone and I have to hard-reset it. In a few words after pressing the "Exit" button I can still see Milky Tracker interface but it becomes completely unresponsive, hardware buttons do nothing too and every background funcion (I.E. receiving phone calls) stop working at all. And hardware reset is the only solution.

This is the first version I've tested on my TyTN II, don't know if the problem was present in previous versions.
Title: Re: Windows Mobile 6 bug ?
Post by: pailes on April 21, 2008, 11:18:56
Afaik setting the buffer size too low can cause a freeze with certain WM devices. The default buffer size should be fairly safe though.
Title: Re: Windows Mobile 6 bug ?
Post by: starknight on April 21, 2008, 11:32:46
I'm using the default settings.
I've never changed the buffer size.

I'll try a larger size but it is strange since TyTN II has 128Mb of total RAM and I have 64Mb free for apps.
Title: Re: Windows Mobile 6 bug ?
Post by: pailes on April 21, 2008, 12:41:51
RAM is definitely not the reason. But since I've never tested with WM6 everything could be responsible.
Title: Re: Windows Mobile 6 bug ?
Post by: starknight on April 21, 2008, 20:28:20
If I configure MT to display the taskbar, screen coordinates on its interface are shifted of some pixel... touching the place where the taskbar should be I can launch a task manager. If I gracefully kill MT's process my smartphone hangs again... but if I kill it immediately (brute kill) the process quits without freezing my smartphone.

So I presume it is a bug related to resource allocation. When MT's process frees allocated resources something goes wrong (at least on WM6 units).

Unfortunately I'm not a WM developer and without a debug option I can not help you in any way  :(
Title: Re: Windows Mobile 6 bug ?
Post by: Deltafire on April 21, 2008, 21:47:27
Just been browsing the archives, there was a similar problem with some PocketPC devices, I'm not sure what the fix was or whether the problem just dissapeared with later releases. It seemed to be a problem with the audio driver not shutting down correctly, possibly due to a memory corruption bug somewhere.  All I can suggest is you try different audio configurations, try changing the mixer rate and "Force 2^n sizes" if it isn't already enabled.
Title: Re: Windows Mobile 6 bug ?
Post by: pailes on April 22, 2008, 08:43:05
It seemed to be a problem with the audio driver not shutting down correctly, possibly due to a memory corruption bug somewhere.

I once had a device for which this bug appeared. It seemed that setting the buffer size of the audio buffer too low caused the waveOut cleanup code to loop infinitely because the internal audio driver did never set the buffer done flag. Skipping the cleanup code wasn't an appropriate fix because the device kept hooked and further audio device allocation failed.
Title: Re: Windows Mobile 6 bug ?
Post by: pailes on April 22, 2008, 08:44:54
Unfortunately I'm not a WM developer and without a debug option I can not help you in any way  :(

Well you could try to compile the sources but it takes a while to setup a windows mobile development environment.
Title: Re: Windows Mobile 6 bug ?
Post by: starknight on April 24, 2008, 09:07:58
Ok, the problem is now clear.

I tried to increase audio buffer from the "Config" panel inside MT. It lets me change every setting (buffer size, sample rate, device name...) but as soon as i click on "Apply" or "Ok" my device freezes. I can not change anything that is related to the audio settings.

It is with no doubt a software bug connected to the way MT handles the audio device. I don't think my device is buggy because I have a lot of programs such as video players, MP3 players, games and emulators... they all handle audio perfectly synced with images and none of them has ever fronzen my TyTN II. I suppose there is another way to handle audio on WM devices. Sorry, can't help you in this  :-\

I hope one day you'll be able to fix this bug... I consider MT a very good and usefull tracker but now it is useless to me  :(
Title: Re: Windows Mobile 6 bug ?
Post by: pailes on April 24, 2008, 09:40:14
You can try one more thing, you can either edit the buffer size with a hex editor in the config file (it's not hard to find, you just need to keep the size of the string intact, it's not a pure text file) or you can setup a larger buffer size on the desktop and copy the .cfg file over and try that. Maybe the default size is already causing the freeze because it's to small or whatever. It might be worth a try.
Title: Re: Windows Mobile 6 bug ?
Post by: starknight on April 24, 2008, 10:47:10
Ok, using the Windows XP version I created a "milkytracker.cfg" file with a buffer of 371ms (16.3K).

Then I used it with the Windows CE version. It worked fine, no more freezes. Then I started lowering it of small amounts each time. It works with values up to 220ms (9.7K). Any value under 220ms starts freezing the device again.

Such a solution could be acceptable if you only want to listen to some tracks... but it is not accetable if you try to compose something. Hearing a note with a 220ms delay is not that good  :(

Don't know how other apps sorted out this problem but I am sure they do not use such a large buffer (audio is always synced with images in players or with character's actions in games).
Title: Re: Windows Mobile 6 bug ?
Post by: pailes on April 24, 2008, 11:26:12
Well if anyone knows more about the problem and how it could be possible to cope with it I'm always interested. But I could imagine that with games and video players you can find suitable workarounds which would still work even with larger buffers.

Anyways I'm neither a windows mobile expert nor an expert when it comes to the crappy Windows waveOut API ;)