On 24 Jan 2000, Marcus Sundberg wrote:

> teunis <[EMAIL PROTECTED]> writes:
> > On 24 Jan 2000, Marcus Sundberg wrote:
> > > Huh?
> > > Either you've found a severe bug in LibGII or you are not using
> > > it properly. Exactly what are you doing that causes a "delay" ?
> > 
> > Same polling code as per public ggiplay.
> > while (ggiEventPoll(vis, emKeyboard|emPointer, &start)>0)
> >   {
> >     x = ggiEventsQueued(vis, emKeyboard | emPointer);
> >     while (x)
> >        {
> >        gii_event event;
> >        ggiEventRead(vis, &event, emKeyboard | emPointer);
> >        /* do stuff */
> >        };
> >   };
> I don't see you re-setting start anywhere in the loop, so delaying
> for undefined amounts of time is indeed expected behaviour of the
> above code. I assume you at least have set start to { 0, 0 }
> initially?

I just pulled the bit out of the code that was causing the problem.

The -full- loop (more or less) is:

for (all frames...)
        update current should-frame-time as well -> ie when the frame
           should be played/displayed;
        read an audio frame; post to audio queue;
        read a video frame if not running too slow; post to video queue
        [that event-loop above]

The full loop is about 350 lines long....  it's not worth posting.
I can disable both audio and video frames.  And did in testing.
The final clue for the prob came with enabled audio, disabled
video-display (though activate GGI -> I usually leave it disabled unless
it's needed), and enabled events.  So no videoprocessing was occuring.
Audio processing (read audio frame) is:
        [obtain audio frame from queue]
        read audioframe from Quicktime into temp buffer [preallocated]
        transform temp buffer into internal audio format->audio frame
        post audio frame into queue.

More or less video frames are handled the same way but like I said I
disabled that.
The original test code was also of the form:
        read audioframe from Quicktime into temp buffer [preallocated]
        transform temp buffer into internal audio format -> preallocated buffer
        write buffer to /dev/dsp

This turned problematical as things were too slow, so I moved to

I hope this explanation helps.  AFAIK the problem is -not- in my
multithreaded queues -> it's in GGI.  Testing was simple; I disabled GGI's
eventhandling and everything worked.
PS: I take the current time & date at a number of points for monitoring
performance.  The total loop time minus events is ~400 milliseconds.  The
addition of events made it about 650-700 milliseconds.  at 15fps, I have
about 660-ish milliseconds to post a frame or I fall behind.  (or at least
that's according to the program's calculations)
I might be off by a factor of 10 or so, but all numbers hold true
relatively.  Effectively the GGI event code was taking me over the

Incidentally, I don't know how delays are supposed to be handled in a
multithreaded app -> nanosleep/udelay all inserted unwanted artifacts.

G'day, eh? :)
        - Teunis

Reply via email to