On Fri, Sep 20, 2002 at 06:30:03PM -0400, Stuffed Crust wrote:
> 1) The vm<->soundsserver API does not need to change. This means I can
> shoehorn my new soundserver into the fray alongside the others.
I have a relatively-well-behaved threaded soundserver ready to replace
the existing SDL soundserver, as soon as CVS is up and running again. It
has a few problems, but nothing major. I think I've covered all the
bases, including save/restore.
The threaded soundserver uses the resource manager directly for song
data, and does not make its own copy in order to minimize RAM usage.
The problem comes on save/restore -- we need to save the entire song to
disk for compatibility reasons, but upon restore, we have to use the
one we loaded off disk, as we no longer have the resource number and
whatnot to load it ourselves.
So instead of extending song_t to include the resource number, I instead
keep track of whether or not the song_t has "shared" data. If it is, I
don't free() it when we destroy the song. This means on a restore we
effectively waste memory, (waste, not leak!) but we can fix this down
the road if necessary.
Personally, I'd prefer to extend the soundserver API to include the
ability to "pull" song data in. This way we don't need to save the
entire songlib to disk, and the soundserver can fetch the song data from
the resource manager on a restore.
> This is partially due to revelations in how SCI01+ explicitly polls
> for updates, but mostly due to the "it's not necessary to gut
> everything because the actual API is better than I thought and it's
> only the implementations that suck."
The new soundserver still provides a "get_next_event()" call. This can
either be polled by the VM (sci0, as we do now) or by an explicit
kDoSound() call (sci01+). Right now, we have a choice to make: For
SCI0 games, should we write to the heap directly and get rid of the
polling that happens all over the VM? (note this isn't all that
practical in the fork()ed soundserver..)
I have several things on my to-do list:
0) Clean up the quirks in the threaded soundserver. Mainly along the
lines of rece conditions and that sort of thing. I need to walk
through the main loop step-by-step. :)
1) Abstract out all threading calls into sci_thread_* wrappers. This
way we can use native threading across the board instead of, say, SDL
for the soundserver and pthreads for the pcmout drivers. I'll tackle
this as soon as the new soundserevr is checked into CVS.
2) Experiment with a pcmout-timer-driven adlibemu driver. This will
minimuze cpu load *and* give us accurate timings with music. In
fact, it's the ideal way of doing it. It'll only work for pure pcm,
ie adlibemu. Unfortunately, it really requires song iterators to do
it right, which leads me to..
3) We gotta take the plunge and finish song iterators. For SCI01+, if
nothing else..
4) Make pcm mono output a runtime option. This halves the cpu
utilization, as we only have one adlibemu running instead of two for
stereo support.
I'm especially happy now that ALSA natively supports my usbmidi widget.
I'd forgotten how good the MT-32 sounded compared to the Adlib.
- Pizza
--
Solomon Peachy pizza@f*cktheusers.org
I'm not broke, but I'm badly bent. ICQ #1318344
Patience comes to those who wait. Melbourne, FL
Quidquid latine dictum sit, altum viditur
-- Attached file included as plaintext by Listar --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE9jU/IPuLgii2759ARAuioAKDfRmvxghcO5qX+cOAsPMfAy+5I5QCgnu84
6/8i3DpgrwzVFrb8TZGqvcY=
=M2Pp
-----END PGP SIGNATURE-----
