[wdmaudiodev] Re: MIDI Capture Timestamping

If cubase and the others use the MME midiInXXX functions, then they don't
have access to a DirectMusic master clock but still receive timestamps when
a note is triggered...  It makes sense to me! :)

The question is: which clock do they use, and why is it different than the
DirectMusic master clock.

Mat

-----Original Message-----
From: e.j.van.der.poll@xxxxxxxxx [mailto:e.j.van.der.poll@xxxxxxxxx] 
Sent: Friday, August 08, 2003 6:55 PM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Re: MIDI Capture Timestamping


This doesn't make much sense to me. Sorry, no offence. It all seems to be
not in line with the idea of having a masterclock. The whole idea of a
masterclock is that all time related events should be linked to this
masterclock. For example the timestamps my MIDI driver gives at input data
are not derived from KeQueryPerformanceCounter() but by calling the
masterclock. In the same way Cubase or Sonar should get their internal
timing from calling the masterclock. If they don't work that way then there
must be a good reason for that (for example that it doesn't work properly).
It might be that the default system masterclock gets it's timing from
calling KeQueryPerformanceCounter() but then it doesn't make sense that it
does something different when called in user-mode. If that is the case than
the whole DirectMusic masterclock concept is flawed.
I am surprised that Cubase and Sonar use timeGetTime to reference their
internal timing as it is not very precise. QueryPerformanceCounter would be
a better choice it seems. I believe this function gets it's timing from the
timestampcounter that every pentium processor has built in. It is increased
every tick of the processor clock. Maybe this causes problems with
processors that vary their clock speed?


Evert






----- Original Message -----
From: "Stephan Kappertz" <stephan@xxxxxxxxxx>
To: <wdmaudiodev@xxxxxxxxxxxxx>
Sent: Wednesday, August 06, 2003 3:31 PM
Subject: [wdmaudiodev] Re: MIDI Capture Timestamping


> Apparently the problem is that the user mode call timeGetTime() and the
> kernel mode call KeQueryPerformanceCounter() do not increment with the
same
> rate on some systems.
>
> DirectMusic MIDI Timestamps are usually calculated using
> KeQueryPerformanceCounter() while Cubase & Co use timeGetTime() for their
> internal timing. Thus the MIDI message time stamp is drifting on those
> systems.
>
> As a side note: Cubase supports using ASIO driver time stamps to calculate
> its clock. Since the ASIO dll runs in user mode, it's up to the driver to
> use one or the other time stamping method.
>
> If ASIO uses timeGetTime and MIDI uses KeQueryPerformanceCounter, the MIDI
> time stamps will drift as well.
>
>     Stephan
>
>
> ----- Original Message -----
> From: "Mathieu Routhier" <MRouthier@xxxxxxxxxxxxx>
> To: <wdmaudiodev@xxxxxxxxxxxxx>
> Sent: Wednesday, August 06, 2003 3:01 PM
> Subject: [wdmaudiodev] Re: MIDI Capture Timestamping
>
>
> > I should have given this address in the first place:
> > http://forum.cubase.net/forum/Forum2/HTML/038028.html
> >
> > It describes the problems that people have seen with sonar and cubase.
It
> > does not refer to DirectMusic drivers; this is mostly a musician's
forum.
> I
> > am not sure about this but I guess legacy midi drivers are also
affected.
> >
> > You must be right when you say it is possible to use a different master
> > clock.  Can you explain how to do this?  It's probably done by
connecting
> > things in the filter graph.  Is it?
> >
> > Mat
> >
> > -----Original Message-----
> > From: Evert van der Poll [mailto:e.j.van.der.poll@xxxxxxxxx]
> > Sent: Tuesday, August 05, 2003 5:46 PM
> > To: wdmaudiodev@xxxxxxxxxxxxx
> > Subject: [wdmaudiodev] Re: MIDI Capture Timestamping
> >
> > Hi,
> >
> > I'm currently developing a DirectMusic driver for a MIDI device and I
got
> a
> > little confused by your answers. It was my understanding that it was
> > possible for an application to provide it's own masterclock, which would
> > then be used by all active DirectMusic devices. This can be very useful,
> for
> > instance if you want to link everything to the samplerate of an audio
> > device.
> > I am curious about the problem you described with Sonar and Cubase. I
have
> > noticed some strange things with the timestamping of input messages
> myself.
> > My driver sends the incoming MIDI data as unprocessed bytes. Somewhere
in
> > the internals of the DirectMusic API these loose bytes are made into
full
> > MIDI messages. These I can then receive by calling
> IDirectMusicPort::Read().
> > But the timestamp I get with that function is not the timestamp that the
> > driver gave the incoming MIDI bytes. I would suspect that the full MIDI
> > message would get the timestamp of either the first or the last byte of
> > which it consists. But apparently that is not the case.
> > You mention that the applications (Cubase or Sonar) can be configured to
> > ignore timestamps? How is that done?
> >
> > Evert
> >
> >
> >
> >
> > ----- Original Message -----
> > From: "Mathieu Routhier" <MRouthier@xxxxxxxxxxxxx>
> > To: <wdmaudiodev@xxxxxxxxxxxxx>
> > Sent: Tuesday, August 05, 2003 11:00 PM
> > Subject: [wdmaudiodev] Re: MIDI Capture Timestamping
> >
> >
> > > The master clock is provided to you as a reference clock.  When the
note
> > > comes in from your hardware, the time stamp should be relative to this
> > clock
> > > depending on how you want it time-stamped (how long before or after
the
> > > current time, if that applies).  Why do you need to use another clock?
> > >
> > > Btw, lately, we had to debug our midi input port timestamps because of
a
> > > problem we noticed with sonar: there seems to be an increasing skew
> > between
> > > the application clock and the midi timestamps.  The longer the
> application
> > > was opened, the longer it took for a note to be processed by the
> > > application.  Restarting the application reset the skew.  When the
> > > application was configured to ignore the timestamps, the problem
> > > disappeared.  We finally found out that the problem was in the
> > application's
> > > way to handle the timestamps.  Apparently Cubase has the same problem.
> > >
> > > I suppose some of you already dealt with this (or at least heard about
> > this
> > > issue).  I was wondering if there was something you'd like to add to
the
> > > discussion.
> > >
> > > Mat
> > >
> > > -----Original Message-----
> > > From: BlazeAudio Developer [mailto:developer@xxxxxxxxxxxxxx]
> > > Sent: Tuesday, August 05, 2003 3:09 PM
> > > To: wdmaudiodev@xxxxxxxxxxxxx
> > > Subject: [wdmaudiodev] MIDI Capture Timestamping
> > >
> > > Can anybody tell what the ullPresTime100Ns in DMUS_KERNEL_EVENT is
> > supposed
> > > to be?
> > >
> > > It's in 100 ns units - but is it the absolute system time or is it
> > relative
> > > to some other event.
> > >
> > > We have a MIDI capture driver(portclass miniport) where we cannot just
> use
> > > the MasterClock object provided in IMiniPortDMus::NewStream call.
> > >
> > > Thanks.
> > > Devendra.
> > > ******************
> > >
> > > WDMAUDIODEV addresses:
> > > Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
> > > Subscribe:
mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
> > > Unsubscribe:
> mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
> > > Moderator:    mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx
> > >
> > > URL to WDMAUDIODEV page:
> > > http://www.wdmaudiodev.de/
> > >
> > >
> >
> > ******************
> >
> > WDMAUDIODEV addresses:
> > Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
> > Subscribe:    mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
> > Unsubscribe:
mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
> > Moderator:    mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx
> >
> > URL to WDMAUDIODEV page:
> > http://www.wdmaudiodev.de/
> > ******************
> >
> > WDMAUDIODEV addresses:
> > Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
> > Subscribe:    mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
> > Unsubscribe:
mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
> > Moderator:    mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx
> >
> > URL to WDMAUDIODEV page:
> > http://www.wdmaudiodev.de/
> >
>
> ******************
>
> WDMAUDIODEV addresses:
> Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
> Subscribe:    mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
> Unsubscribe:  mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
> Moderator:    mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx
>
> URL to WDMAUDIODEV page:
> http://www.wdmaudiodev.de/
>
>


******************

WDMAUDIODEV addresses:
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
Subscribe:    mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
Unsubscribe:  mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
Moderator:    mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx

URL to WDMAUDIODEV page:
http://www.wdmaudiodev.de/
******************

WDMAUDIODEV addresses:
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
Subscribe:    mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
Unsubscribe:  mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
Moderator:    mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx

URL to WDMAUDIODEV page:
http://www.wdmaudiodev.de/

Other related posts: