On 24 Jan 2000, Marcus Sundberg wrote:

> teunis <[EMAIL PROTECTED]> writes:
> > Okay, I've found a problem with libGII...
> > 
> > It's adding delays to that quicktime-player (and soon mpeg too! :) that
> > I'm playing with...  Resulting in blank spots in the audio and the
> > occasional dropped video frame.
> 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 */

Anyways, behind the seens I have a bunch of other stuff going on too.
Several threads monitoring different queues for data.  When I disabled the
event testing the gaps in my sound-playing dissappeared.  I've now moved
the event-reading to a seperate thread and use a socketpair to pass
translated events along and this works beautifully without delays.

There's definitely a problem.  I'm running under fbdev (I -do- have a USB
joystick attached+enabled if that affects anything) under linux-2.3.39 and
a 3dfx/Banshee card [+fbdev driver which only can handle 640x480 *sigh*]

I'm running with typically a 15fps motion-jpeg encoded quicktime - and
this is farely CPU-intensive to decode.  The GII/input stuff pushes it
over the mark and I end up losing a lot of frames as it takes
approximately 15% longer than it should to decode and post frames into the

> > Any ideas for how to solve this one?   The thing's multithreaded enough...
> > I suppose I could add an I/O thread but I'm not sure how generic it should
> > be made.
> > 
> > Can GII eventstacks be made to communicate cross-thread?  (without
> > crashing or locking up that is... :)
> Sure, just call giiMTInit() and you should be able to to retrieve
> and enqueue events from multiple threads simultaneously.
> Joining/opening/closing inputs from several threads simultaneously
> will still not a good idea though, but that is hardly a problem.

I've decided to just handle I/O from one thread (and may eventually move
this into a seperate process so I can choose different I/O modules :)

G'day, eh? :)
        - Teunis

PS:  Anyone here know how to handle 'sleeping' for <1 second delays on a
multithreaded app?  Currently I'm using pthread_cond_timedwait with a
condition that never gets signalled as nanosleep, usleep, and everything
else I've tried seems to put the entire program to sleep *sigh*

Reply via email to