From: Jim Peters (jim_at_uazu.net)
Date: 2002-01-23 21:44:29
Jim Meissner wrote:
> A message to the over enthusiastic software group.
>
> FIRST THINGS FIRST.
>
> Before you guys get too fancy, first you need to build something
> that WORKS.
I agree with Jim. If other people want to go and create some fancy
app by designing screens and copying other people's apps, then fair
enough. But I know that I'm not going to know what kind of
biofeedback I want to do until I have my brain hooked up to the
program. At that point I'll have ideas, and the code will come from
that. Probably I'll have rough prototypes working before anything is
ever polished into something with a user interface.
Actually, I had this idea that if I keep on coding, whilst other
people talk, then eventually it will all be done my way, because
working code speaks !
> From: sleeper75se
>
> 1. Data input, signal processing, protocol management and such
> 2. User interface (operator)
> 3. Feedback interface (patient/user)
This is my interpretation of this:
Thread one is waiting on the serial port, and processes data into bins
as soon as it arrives.
Thread two waits in the user event loop, checking the data in the
processed bins every now and again, updating the display.
Thread three waits on the sound-card output, always ready to feed it
more data, and bases this output on the processed bins.
Thread three has highest priority, then thread one, then thread two
last. If something goes wrong and the serial data stops coming in,
thread one blocks, but thread two continues to work, and so does
thread three.
> If the timing is critical (as with the Roshi), some feedback
> functions can be moved into thread 1.
I think this will only come clear once we know what kind of feedback
will be happening. We've a choice of locking it to the input data
clock (at 128Hz or 256Hz, thread one), or locking it to the sound-card
output clock (thread three).
If you can wait on more than one stream at once, you could perhaps put
thread one and three together. However, I know that some sound-card
drivers on Linux always block and don't support a select() call, so
you need a separate process to keep the sound card happy in this case.
I've no idea how all this works on Windows.
> If a scripting language is added later on, that is a fourth thread,
> because it would act as a second operator.
>
> What do you think?
If we're writing data to disk, then this needs to be buffered in
memory so that blocking disk writes don't interfere with the input
processing. With a working select() call, disk writes could be done
in thread one, or if that is no good, they could be put in thread two,
or maybe in a thread of their own. (I've coded this kind of thing
before on UNIX, so no problem there).
This is one area that might cause versions for different OS's to
diverge, as I have no idea how reliable threading is on Windows, or
whether it is adequately covered in these cross-platform libraries
we're considering.
Jim
-- Jim Peters (_)/=\~/_(_) Uazú (_) /=\ ~/_ (_) jim@ (_) /=\ ~/_ (_) www. uazu.net (_) ____ /=\ ____ ~/_ ____ (_) uazu.net
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:37 BST