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?
*sigh*.
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;
gettimeofday(&start,NULL);
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
multithreading.
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
deadline.
Incidentally, I don't know how delays are supposed to be handled in a
multithreaded app -> nanosleep/udelay all inserted unwanted artifacts.
*sigh*
G'day, eh? :)
- Teunis
