Please take the time to read this, if you''re into coding timers, cos I''m really totally stuck. I recently got into Windows coding, after 10 years of pure DOS. I''m having a hard time getting this mod player to work. Under DOS, it used to have an interrupt function called 100 times a second. Under Windows i used the timeSetEvent(...) function and noticed some huge latency. Obviously a modplayer can''t use that :-( Then I got into these thread thingies. CreateThread makes me a nice thread, and with SetThreadPriority i can set the priority to higher or even realtime. This clogs up the cpu though, and it stil doesn''t play sound smoothly. Here''s the code in my thread function: do { QueryPerformanceCounter((LARGE_INTEGER *) &time); //** Checks timer to see if a millisec has passed **// if (millisec) { //** Plays notes, if any should be played yet **// } Sleep(0); // relinquishes remainder of timeslice to OS } while (1); So, what am I doing wrong here? Should I set priorities differently? I have DirectSound at DSSCL_PRIORITY and the thread at THREAD_PRIORITY_HIGHEST. Or should I take a wholly different approach? Thanks in advance

Hi
Well, maybe you could compute the deltatime instead, I mean, don''t check for millisecs but try to move your thread as fast as possible and then compute the timepassed since you last played a note and put your audio data in place corespondingly, be a couple of millisecs ahead. You don''t need to be realtime, just almost.
did that make any sense at all ?
just an idea, have never done it myself

Well the problem is i have to check every millisecond or near, so mods with weird beats per minute like 166 (which don''t translate to exactly one note every so many millisec) also play correctly. If I could check every tenth of a sec or something I''m sure it would play smoother.

This is how I would try to do it.

read the next 100 or so millisecs from the mod file or wherever you get your data from. put it in the soundbuffer.
next loop:
check and see how much time has passed
(lets say 48 ms)
100ms - 48ms = 52ms
read from where you last where in the indata. write 52ms of data to the audiobuffer right after where you added the last data, now you are still 100ms ahead.
next loop:
AND SO IT GOES ON FOR A WHILE, I just don''t have the time to write every iteration that might occur in 1min of music, but I think you got the idea.

Please tell me if this is completely stupid?

Under windows, you''re going to have to change your MO a bit.

You''re talking about your playback function, not the sound mixing function, right? Under DOS if you set the system timer for 100hz, it would call your interrupt every 1/100th of a second, but under Windows as you noticed, your timer is not very exact, and you might be delayed before your function gets called.

To work under windows, you''ll have to take a different tack. The best solution I can think of is to have your timer function, when called, add the mixed music to your mix buffer from wherever it left off the last time, to a spot in time that''s about 1.5-2x times the current timer frequency.

So, lets say your player does something like:

TimerInterrupt() // set to the BPM of the song {
if (mixbuffer is not full)
mix the next timerFreq*2 millisecs of audio directly to a sound buffer
continue playing sound buffer, looping the play location in a "ping-pong" as needed.
}


This introduces a latency the amount of buffersize/playrate, but that''s an unavoidable artifact of sound under windows.



- Remnant
- (Steve Schmitt)