http://bugs.winehq.org/show_bug.cgi?id=9358
--- Comment #14 from Maarten Lankhorst m.b.lankhorst@gmail.com 2008-06-04 13:17:02 --- My explanation follows here, without a fix.
Imagine the hardware sound buffer like this:
[----XoooooX-----------------------] ^----------- read pointer up to write pointer.
DirectSound mixes every time the hardware (or dmix) read pointer advances, unfortunately the read pointer advances in blocks (roughly) up to the next write pointer.
The amount of time between read and write pointer is the maximum resolution applications can use. In case of alsa it is 2x or 3x the period size. This is roughly between 40 and 60 milliseconds in most cases. This means that famitracker won't be able to read smaller then those sizes, unless I 'fake' the position of the read/write pointer to artificially move with even smaller intervals by making the reserved area 1 period longer and then fake moving depending on how much time expired. I'm a bit hesitant to do this, but if it's still a problem with v2.6.24 I might take a look into it.
--Maarten