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.
> 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);
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? :)
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*