[gmpi] Re: Topic 6: Time representation
- From: "Silver Blade" <lists@xxxxxxxxxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Sun, 11 May 2003 21:40:57 +0100
> ----- Original Message -----
> From: "Mike Berry" <mberry@xxxxxxxxx>
> To: <gmpi@xxxxxxxxxxxxx>
> Sent: Sunday, May 11, 2003 8:09 PM
> Subject: [gmpi] Re: Topic 6: Time representation
>
>
> > Looking at your code, which does indeed do what you say, I see that you
> > are doing something which few hosts would actually do on Windows. That
> > is, you are simulating all of the processing happening on the driver
> > thread at TIME_CRITICAL. This is actually a very unstable design, as
> > your program shows.
>
> i would not say unstable , but restricting. with 20ms buffer all works
> better under Windows ! :-)
Yes, and the reason it doesn't work as well with other buffer sizes is
because it's unstable, perhaps?
> > The more common way to do this is to simply do a buffer copy on the
> > TIME_CRITICAL thread. After all, with 500 ms latency, whats a little
> > more or less.
>
> this is not the recommandation of the AudioBoard Manufacturers. They
usually
> recommand to process right now when receiving event from the audiodriver.
> (because this event is already an event and not an interrupt). So it makes
> no sens to copy the buffer and Set an other event to start an other thread
> to process this buffer.
A recommendation is a guideline, not a rule. I might recommend that you stop
trying to tell everyone else that what they're saying is wrong, but that
doesn't mean that you have to, for example.
When a buffer is given to a callback mechanism, the buffer needs to be
processed by the next buffer switch. "Now" is a good time to do it, but we
can do it any time between now and when the next buffer switch is about to
occur.
> i've also tried this method , cutting big buffer into small ones in order
to
> spread the processing in the time , is very hard to synchronize, in fact
you
> lose time and reliability... this is not the good way in my opinion.
Reliability can only be affected by the programmer. If you program reliably,
your program will be reliable.
> >(whether or
> > not that is the case). Others may disagree with you (certainly they
> > occasionally disagree with me), but this does not make them stupid,
> > lazy, or any of the other invectives which you seem to cast about
freely.
>
> Ok, All that i'm talking about has been programmed, tested and often
> measured. So i can try to explain my desagreement , to explain why, and
> finally if you still don't understand my point of view, i can try to give
> you the key to check some points, and invite you to make some
> experimentation and test. But if you even don't want to do that ! what can
i
> do !? .except saying a small word ?. :-)
But there's a problem... It's not particularly relevant to GMPI!
-SB
----------------------------------------------------------------------
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:
