Linux does squawk!

Lex Spoon lex at cc.gatech.edu
Tue Feb 17 07:36:15 UTC 1998


Christopher Oliver wrote:
> > The old synchronous code is left in as an ifdef option.  The
> > synchronous code is simpler and more stable, and does not require
> > pthreads.
> 
> Ach!  At the moment, I am avoiding threads since there seem to be
> more than a few differences between the various threads libraries
> out there.  I'm trying to implement the whole API regardless of
> the lack of true need for insertSamplesFromLeadTime() at the mom-
> ent.

Yeah, for IO under Linux you have to either block, poll, or use
threads.  The only asynchrounous IO I know of is for sockets, and it's
tricky to use anyway.  Blocking is not a useful alternative.  With
threads, you get guaranteed near-optimal performance.

With polling, you can still get practically optimal behavior, *if* you
choose the polling interval well--it's one more knob to tune.  You
never know for sure if some change (software or hardware) down the
line will make what is currently an excellent choice of polling
interval to be a very poor one.  It would really suck if it got to the
point that users have to manually adjust that setting before they can
even play the sound demos.  (okay, it's a stretch, but it's possible!)


I don't see that the standardization of threads libraries is a problem
here.  LinuxThreads is as standard as anything is in Linux, and the
pthreads API which it uses is a global POSIX standard.  If any
Unix-like OS follows any thread standard, it is likely to follow
pthreads.  Furthermore, the background threads needed here make very
modest requirements on the threads package: there is nothing like
thread priorities or inter-process synchronization required.  Granted,
I'm not a threads guru or anything though....

By the way, on the implementation of a polling version, I think you
may as well poll from within the image as from within periodic signal
handlers.  In fact how the standard image already handles synchronous
sound playing by in-image polling.  

To contrast, polling from an interrupt handler has two bad points.
First, you are dealing with signals, which have plenty of OS-specific
behavior in themselves.  Second, you lose the ability to modify the
polling loop from within a running Squeak image.


I personally think the threads approach is better than the polling
approach--your performance is guaranteed to be pretty close to optimal
even without any knob tuning.  However I also don't think that either
approach is all that bad.  (I wonder why polling isn't supported in
the image for SoundRecorder?  Is this a case of focusing on more
important things?)


In any case, I think all us Linux users would love *something* being
put into the standard Squeak distribution.  There are at least three
versions of Linux sound code floating around now.  At least one of
them provides 99% functionality today, and at least two of them have
provided 99% of the *playing* functionality since September '97.
*nudge* *nudge* :) We can draw straws or flip coins or whatever, but
having some common ground to start from would be quite nice.

Then, we could all spend our time making new improvements, instead of
starting from scratch where others have done so so many times.  Even
if whatever gets stuck in there turns out to really suck, the patches
will start flowing in to make it better.  And if it really sucks
we can have long flame wars on what it should be replaced with :)



Lex Spoon
lex at cc.gatech.edu
http://www.cc.gatech.edu/~lex/






> 
> > Second, simultaneous reading and writing is not supported.  This is
> > possible on some cards, but not all.
> 
> I personally think that placing much elbow grease behind major feat-
> ures that fragment the users into haves and have-nots sort of goes
> against the spirit of freely distributable software.


Amen!





More information about the Squeak-dev mailing list