[freesci-develop] Sound timing

[Christoph Reichenbach]

Hi,

let's raise everyone's favourite topic once again ;-)

I did some tests on my laptop yesterday; these indicate that the benefit of
de-coupling sound playing from cue delivery (as forcefully introduced into
Glutton) has the potential to improve sound timing considerably (except,
of course, on Alpha machines, users of which were blissfully unaware of how
bad the situation was until they tried some other hardware).

  Another thing some of you may have considered "obvious" which I hadn't
thought of is that sound/cue synchronity should be guaranteed by
gettimeofday() returning the same result across processes/threads, so
syncing between output and cues should not be an issue.

Therefore, my suggestion would be to introduce some kind of "timer mechanism",
which essentially takes a closure and executes that in regular intervals
(I used setitimer with SIGALRM, which is known to have extremely bad
real-time behaviour; other implementations could be _clone() (Linux),
rfork() (BSD), pthreads (everyone else), Int8 (DOS) etc; separate processes
would require shared memory segments or song iterator serialization (not
implemented yet) for this to work).
  The closure could then gettimeofday() to estimate how bad the scheduling
is and adjust write-ahead accordingly, polling a song iterator passed to
it and passing the results to the MIDI output layer (essentially replacing
the sound server). Since Glutton's current sound layer does all the
complicated song handling stuff in the main process/thread, setting a
new song would be as simple as setting a pointer to a new song iterator
(if I'm not mistaken, pointer writes are atomic on all machines that
support sound output, but feel free to correct me-- there are alternatives,
like using two song iterator pointers, and specifying which one is in use
by means of variables which we can write to atomically. Of course this
doesn't resolve the problem of pre-emption "real" threads may have with
a context switch occuring in between "if (song_iterator != NULL)" and
"song_iterator->next(song_iterator, &buf, &result);").

So I'd like to ask those of you involved with some kind of port or sound
driver the following:
(a) Does your platform support some kind of timer mechanism as described
above?
(b) Does your MIDI output layer have a notion of "wait n before executing
next operation"? 

As discussed in proposals from earlier this year, it would also be nice to
have support for song players which play ahead for a very long amount of
time (vfork(); exec("playmid"); kind of stuff). This could be added gradually;
of course, fading out would require mixer controls (or some sort of control
over IPC), and looping would usually require re-starting the process, which
would be likely to be audible to listeners.

Sorry for the unrefinedness of this mail. I hope next week's mails will
be better. Anyway, any thoughts on this?

-- Christoph