If a Squeak Process is idle, then it won't do anything.  Waiting on a
semaphore or a delay is definately noticed by the system.  And believe
it or not, increasing SoundPlayer's process even further is unlikely
to make it faster; the priority is only used when processes are competing,
and there aren't too many active processes at that high of a level.

Something to watch out for is the size of the operations that primitives
are performing.  For example, the MPEG plugin has primitives which decode
an entire frame at one go.  When such a primitive is called, Squeak can't do
anything, including updating the Sound buffer.


-Lex



Karl Ramberg <karl.ramberg at chello.se> wrote:
> Hi, I'm hacking on the MPEGPlayer and 
> the _big_ issue is speed. 
> I have three processes that 
> handles audio and video. The first audio process is 
> feeding a buffer and spend most it's time 
> in wait (3000 milliseconds). 
> The second audio process is SoundPlayer.
> And the video process is reading into a form and 
> synching to real-time. 
> My questions are
> 
> 1 How do I let the system know that a process
> have some cycles to spear ? 
> 
> 2 The SoundPlayer process runs at userInterruptPriority (5)
>   Is there anything to gain by increasing this to priority 6 or 7 ?
>   Is there anything for the video process to gain from running 
> at 6 or 7 ? ( Latest released MPEGPlayer code runs at priority 4)
> 
> 3 I'm trying to understand semaphores. Are there any Cliff's Notes
> on semaphores out there ? If not, have I understood correctly if I
> think of semaphores as a flag to start/resume another process that 
> is idle ?
> 
> Thanks for the patients,
> 	Karl