[gmpi] Re: Topic 6: Time representation
- From: "Vincent Burel" <vincent.burel@xxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Sun, 11 May 2003 17:25:51 +0200
----- Original Message -----
From: "Silver Blade" <lists@xxxxxxxxxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Sunday, May 11, 2003 12:40 PM
Subject: [gmpi] Re: Topic 6: Time representation
> > 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
.
>
> I don't see a problem here either... The host will have to account for
> buffer size differences no matter what (the user might want to modify
buffer
> settings, or use a different driver which has a different buffer size.)
>
> All plugins need to worry about is processing a signal, and maybe a few
> other small informative parameters. It's passed a buffer which could be of
> any size, processes it, and gives an output of the same buffer size
> (presumably.) If the buffer size changes, the plugin just needs to know
what
> the new size is so it knows how much data it needs to process.
well, if you don't see problem, congratulation ! personnaly i feel that too
much complicated. And you should know in software stuff, the more it's
complicated , the less it works. :-)
> 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.
>
> This is what I meant when I mentioned latency caused by buffer sizes.
>
> If you base your MIDI timings on the current time (by the calculating
> buffer-switch interval multiplied by how many buffer-switches there have
> been), you'd be able to start the timer from there, so it'd be very close
to
> sample-accurate timing. A buffer which lasts for 10 ms is very quick to
> play, so even if there is some clock drift on the part of the PIT, it
won't
> be noticeable within a 10 ms time frame.
well, i've nomore time to enter in big explanation, so i propose you to make
the test yourself.
program a audio stream with 500ms buffer size, containing a processing wich
uses 80% of your CPU. And try to timestamp your mousemove (mouse can now
provide at least 50 event per second) to change for example a simple GAIN in
your algorithm. If you get the same reaction type with a 500ms buffer than
with a 20 ms buffer... i will be obliged to ask you how you did it ! :-)
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:
