Re: [Plib-users] slScheduler: Too many pending callback

[Steve B. <sjb...@ai...>]

> Steve Baker wrote:
> > This is *very* strange...I've never heard anything like this before.
> > 
> > * Does the mod_demo program actually play music?
> 
> Yes, loud and clear.
 
Oh - weirder and weirder.

> > * Do the other programs make any sounds at all before they die?
> 
> Ok, they don't actually die. "sl/example" runs until I hit ctrl-c, and
> outputs hundreds of this error, but no sound is played.

This is *bizarre*.

> FlightGear plays
> the engine sound, but nothing else happens (no graphics is shown after
> the splash screen), disabling sound makes it run as usual. TORCS plays
> something, but also locks up, giving lots of errors.
 
Even weirder.

> > * What window manager do you run?  Does it have it's own sound
> >   manager like 'Enlightenment's  'ESD'?
> 
> When you mention it...I use KDE, and I remember reading in the glTron
> FAQ that there could be some kind of problem with KDE and glTron's
sound
> - but I get sound in glTron.
 
No - I don't think KDE poses a problem.  I've been using KDE on my
laptop for about 6 months and I installed it on my main home machine
a couple of weeks ago - they both play sound OK.

I thought the problem with glTron (and with just about every other
program that's not specifically written for it) is the 'Enlightenment'
package.  It tries to be very clever and mix together the audio
coming from every program that's currently running before shipping
it off to your sound card.  The program that does this is 'ESD' -
the Enlightenment Sound Daemon.

The problem with ESD is that it opens '/dev/dsp0' and refuses to
give it back.  Programs that know how to send their audio to ESD
work OK - but programs that need to work WITHOUT ESD (which is
to say every program on the planet except those that come with
the Enlightenment bundle) find that they can't open /dev/dsp0.
(Or worse, they can open it - but it simply blocks all writes
to the sound card indefinitely).

So, there are workarounds that all basically entail shutting
down ESD for the duration.

I believe that it's possible to run ESD without the E desktop,
so I suppose it's *possible* that it somehow got installed
along with KDE - but if that's the case, it's not done that
way from the SuSE Linux install that I use.

Besides, if that were the problem, you wouldn't get any
sound at all from any SL programs...yet mod_demo works
and FGFS produces *some* sounds.

> > * Were there any other messages on startup?  Any warnings from
> >   the compiler?
> 
> I will try recompiling sl and see if there were any warnings.

Yep.

What's odd is that both KDE and your sound card are very common.
I can't understand why I'm not swamped with this kind of complaint.

> > I'm utterly mystified.
> 
> Lets blame KDE for now... ;-)
 
Nice though that would be - I have to say "No". 
 
I think the next place to look would be to stuff some 'fprintf(stderr's
into the SL source file 'src/sl/slScheduler.cxx'.  Re-make it
and don't forget to do a 'make install'. Re-make the example
program too.

*  At the top of slScheduler::addCallBack print the value of
   'notWorking()' and the value of 'num_pending_callbacks'.

*  Another at the top of slScheduler::realUpdate (printing
   those same values)

*  At the top of slScheduler::flushCallBacks (same info)

*  Inside the 'while' loop of slScheduler::flushCallBacks
   (print just the value of 'num_pending_callbacks')

Have each printf say which function it's in so we can identify
it - then run sl/example for a few seconds - at least up to
the first error message, then email me the output.

If everything is working, we should see a steady stream of
calls to realUpdate with a matching call to flushCallBacks
each time. num_pending_callbacks should be zero.

Every now and again, there should be one or two addCallBack
calls - which would increment num_pending_callbacks each
time (never getting bigger than a dozen or so - and certainly
not getting close to 32 - which is the magic limit).

On the immediately following call to flushCallBacks, we
should see the inner while loop run - counting down the
num_pending_callbacks to zero...then back to a long string
of realUpdate/flushCallBack outputs in a row again.

This is *so* weird.


-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)