Hi Christoph,
> commands: emitted from the main program (kSound() kernel function,
> global init/shutdown code, debug code, using sound.c
> and soundserver.c API)
> song data: Sent to the sound system by means similar to commands
> sound cues/status updates: emitted from sound server
> (process/thread/(signal/message) handler)
OK.
> The approach you're suggesting would actually allow usage of the resource
> manager (by locking the song/unlocking it when a different song is
> activated); that's pretty much the only point where pointers would come
> into play.
> Songs should be locked before their pointers are sent, and only be
> unlocked if a 'SOUND_UNLOCK_SONG' (or whatever) message sent from the
> sound server to the main thread.
OK, I'll also read up on how the resource manager works.
> Using 17ms would make the timer be off by about 2%, whereas 16ms would
> cause it to be off by ~4%, so 17ms is preferrable.
> Note that I'm not absolutely certain whether this deviation will be
> acceptable (after 50s, we're off by one second), but it's worth trying.
> Re-programming the timer to just wait 16ms every third WM_TIMER message
> would be best in theory, but might sound a bit unusual for trained ears
> (not sure about that).
To see if we can get the best performance, I'll compare using the Windows
timer I mentioned with the QueryPerformanceCounter() function in a separate
thread. The latter gives a resolution of 3579545 counts per second on my
machine, which is a lot better than 1000!
[snip]
> > else if (&msg.message == UWM_SOUND_COMMAND_SET_VOLUME)
> > {
> > master_volume = &msg.wParam * 100 / 15; /* scale to % */
> > midi_volume(master_volume);
>
> I'd vote against distinguishing messages on this level; let's just pass on
> every message to a snd_process_message() function after converting it to
> a FreeSCI 'sound command' or 'sound event' or whatever.
That sounds OK, but how will we know if it's a sound command or event
without comparing it with each possible message? Are you suggesting only two
basic messages (apart from timers) with the command stored in wParam and
data in lParam? Will that be too restrictive and will we be able to carry
enough data through?
> That sounds very useable; but how do we get messages sent to this thread
> will be processed by the thread itself instead of by its parent?
PostMessage() works properly for doing this. In the code I detailed in the
previous e-mail, there is no need for a callback function which is what
caused the code to run in the wrong thread. Because there is no queue when
using SendMessage(), its messages were being missed by the message loop and
falling through to the callback. With PostMessage(), however, every message
is caught.
> Other than that, this model appears to be sound; combining it with the
> UNIX model should be reasonably simple with the approach outlined last
> wednesday, if we split up sound server functionality appropriately.
That's excellent.
> Commands and data (complete song blocks, plus meta-information) are sent
> from the main thread, in the sound API. While internals might change, I
> see no need to alter the concept itself.
>
> Cues and song status information are sent from the process_timer_event()
> function to the main thread. If we use PostMessage(), we can process the
> messages at the points we're doing this already. This means that the
> sound API (and therefore the kernel usage) would not be affected unless we
> want to do a few cleanups (seems to be reasonably OK IMHO, though).
Good, OK.
Alex.
