[gmpi] Re: Topic 6: Time representation
- From: "Vincent Burel" <vincent.burel@xxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Sun, 11 May 2003 09:18:36 +0200
----- Original Message -----
From: "Silver Blade" <lists@xxxxxxxxxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Saturday, May 10, 2003 8:09 PM
Subject: [gmpi] Re: Topic 6: Time representation
> > > There is a fairly easy way to combat this clock drift, and that is to
> base
> > > timings on the buffer-switches, rather than just by programming the
> > > multimedia timers.
> >
> > yes i know this way. but the purpose here is to work with big audio
buffer
> ,
> > so means not many buffer switch per second, so means no enough precision
> to
> > timestamp incoming event with a clock based on the audio stream...
That's
> > why i asked ! how to timestamp Event coming from whatever inside or
> outside
> > the PC in this case with usual O/S.
>
> You do understand what latency is caused by, don't you?
:-) you're kidding !?
> I think you're misunderstanding what we're talking about here. I assume
the
> "big audio buffer" you mention is the timeline of the host application.
> Plugins don't need to know about every event, unless they want to. The
host
> application is responsible for working with buffers, getting timing right,
> etc.
i misunderstand nothing. i talk about the last idea to timestamp incoming
Event (e.g : MIDI) in a buffer to describe to the plug-in what's happening
during an audioframe. Because some of us here consider that the
Audiobuffersize can be big (> 512 samples). So if we imagine that the HOST
is managing a 8000 samples buffers. if the HOST recieve MIDI data during
this time , it has to store it into a file of timestamped Event to provide
them to the plug-in (each event with a time attached on ). Then the plug-in
will be able to keep the precision of the Event Times into the next buffer
and then will be able to react strictly (into its 8000 sample buffer)
according this event file.
In the opposite, i say thta i'm not agree with this method , because first
it's more complicated to program for the host and for the plugger (the
processing function will have to change is behavior different times within
an audio frame) than to consider the buffer size as an atomic time unit .
Because the bufferSize on Host audio software become smaller and smaller,
and because on non real time operating system , it's not possible to
timestamp incoming event with a good precision when a big buffer audio
stream is playing.
> I didn't realise it was a joke???
when there is this symbol ":-)" it's usually a joke (often cynical)
Vincent Burel
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
