Home All Groups Group Topic Archive Search About

MMTimer, DirectSound, and For..Next

Author
21 Mar 2006 5:30 AM
FrankAm
I am writing a Wav file based DrumMachine program. I used DirectSound
to play the Wav files, and I use the TimeSetEvent function in winmm.dll
for my timer routine. I am having a couple off issues that need to be
ironed out and I am at a loss. Here is the deal...

The timer works perfectly. I tested it by creating a label, storing the
time that I start playback, storing the time that I stop playback, and
subtracting the number of milliseconds that the timer should have fired
in this timeframe. The result is written to the label... No matter how
long I run the timer, it was only off by 1 or 2 milliseconds over the
life of the timer, which could simply be due to how long the code takes
to intitialize the timer the first time. No problem there.

Issue number 1...

I record my song (90 BPM) in realtime into another (professional)
application (sonar) at 90 BPM and my program drifts over time. Other
pro applications sync perfectly using the same procedure. I KNOW for a
fact that my BPM calculation is correct... So, ???

Issue number 2... (They are probably related)

The user can program up to 24 drums to fire simultaneously. In testing,
when I do this, you can hear that the drums are not firing at exactly
the same time. This is probably due to the fact that I am using a For
Next loop in my procedure. It literally goes through all 24 "drums" to
see if each one is "on" and calls another proceedure that loads then
plays the wav file if necessary.

Is it possible that the For/Next is taking too long to excecute and is
somehow affecting my timer?

Is there any way to NOT have to load the wav into the DSbuffer before
playing it, perhaps this is where the delay is?

Does it make sence to have 24 DSbuffers instead of one?

Is there another way to test this to find out where the delay is coming
from?

Any ideas will be greatly appreciated.

Frank

Author
21 Mar 2006 5:35 AM
Robin
FrankAm wrote:
> I record my song (90 BPM) in realtime into another (professional)
> application (sonar) at 90 BPM and my program drifts over time. Other
> pro applications sync perfectly using the same procedure. I KNOW for a
> fact that my BPM calculation is correct... So, ???
>

Problem found, you are expecting a drummer to keep in time :-)

Q. How do you know there is a drummer at the door?
A. The knocking speeds up.


--
Robin.

"He who treats the database as a flat-file repository of data is doomed
to burn in Hell. It's true, I asked." - Dratz
Author
21 Mar 2006 5:43 AM
FrankAm
I know I cannot keep perfect time, this is why I need a drum machine
program, I thought computers were supposed to be perfect? ;-)

Actually, my program sounds great being a little "off", very human. But
this is no good when the beats need to be shared with other programs.
Author
21 Mar 2006 6:00 AM
Robin
FrankAm wrote:
> I know I cannot keep perfect time, this is why I need a drum machine
> program, I thought computers were supposed to be perfect? ;-)
>
> Actually, my program sounds great being a little "off", very human. But
> this is no good when the beats need to be shared with other programs.


I am afraid my wise crack might be the most useful thing I post on this
thread, but I will give it a go (FTR, I'm a Bass player.)

Timers in windows are not spot on, they are 'round about'.  The problem
with using this for sound is that the ear, unlike the eye, is very
precise and picks up on irregularities in an unforgiving manor.

Where the eye will 'trick' you and adjust to things, the ear will make a
slight problem stand out like dogs teeth.  (as you would well know).

Timers are effected by cpu usage etc.  I guess one sound is taking up
cycles slowing down the start of the next one.  I guess you might be
able to get this really close, but AFAIK using timers you will forever
be at the mercy of this.

--
Robin.

"He who treats the database as a flat-file repository of data is doomed
to burn in Hell. It's true, I asked." - Dratz
Author
21 Mar 2006 7:57 PM
FrankAm
I agree, but...

How is it that Sonar, or a host of other pro applications can deliver
PERFECT time running under windows?

Also, in testing my timer IS indeed accurate, the problem must be
something I am doing in my routine. This is why I posed the question,
does the loading of the wav into the buffer (24 times in a loop) and
subsequent playing of the file slow the timer down, and my test is not
catching this fact?
Author
22 Mar 2006 8:09 AM
J French
On 21 Mar 2006 11:57:40 -0800, "FrankAm" <frankamend***@sbcglobal.net>
wrote:

>I agree, but...
>
>How is it that Sonar, or a host of other pro applications can deliver
>PERFECT time running under windows?
>
>Also, in testing my timer IS indeed accurate, the problem must be
>something I am doing in my routine. This is why I posed the question,
>does the loading of the wav into the buffer (24 times in a loop) and
>subsequent playing of the file slow the timer down, and my test is not
>catching this fact?

<quote>
The timeSetEvent function starts a specified timer event. The
multimedia timer runs in its own thread. After the event is activated,
it calls the specified callback function or sets or pulses the
specified event object.
</quote>

In other words the CallBack is coming from another Thread, and VB6
does not support multiple threads (normally) at all safely.

Other languages support multiple threads and those Applications
probably use SetThreadPriority.
Author
21 Mar 2006 9:21 AM
Schmidt
"FrankAm" <frankamend***@sbcglobal.net> schrieb im Newsbeitrag
news:1142919038.804347.279120@j33g2000cwa.googlegroups.com...

> Does it make sence to have 24 DSbuffers instead of one?
Definitely yes (as long as your Ram is large enough).

You should also try to work on an absolute time-base.
Get your StartTime - then enter the Loop and set
your MMTimer-Interval to 5msec or below.
Look inside each Timer-Event for the actual Time-Delta
((CurTime-StartTime) Mod YourRealInterval) and decide
from this values, when to play your SoundBuffers.

Olaf

AddThis Social Bookmark Button