On Sat, Dec 01, 2001 at 06:42:15PM -0800, Matt wrote:
> On another side note, I noticed the TODO still lists PCM support as a
> requirement. I can throw together a driver for win32 to do this very
> quickly -- the API is as easy to use as the one for MIDI. I'll just need a
> UNIX example driver to work from so I know what API the driver should
> export.
</delurk>
I do have the framework for a PCM subsystem, but it kinda hit a brick
wall a while back when it came time to actually make it do anything.
(I realized it would have taken far more work than I had time)
Anyone want a patch to poke around in? I don't think I should ckeck it
in this close to an otherwise stable release, but then again it's not
like it affects anything at this moment.
My plan was to use SDL, taking advantage of the nifty SDL_mixer library
to do the gritty stuff, like, um, sample rate adjusting and mixing. This
in effect would require SDL for PCM output, which I don't see as an
inherently bad thing, given that it'll eliminate the need for
OSS/Alsa/Win32 PCM output drivers anyway, though of course, those could
be created if desired.
Basically, what we need to do is to create a callback to fill the
output buffers. Those buffers need to be filled in realtime by the
operational layer, using soundserver pcm events and/or opl3_emi and/or
Timidity++.. I haven't touched this aspect of the PCM layer at all.
I also had issues with the initial SCI01 sound resource spec; I wanted
to build an interpreter for 'em..
Blargh.
- Pizza
--
Solomon Peachy pizzaATfucktheusers.org
I ain't broke, but I'm badly bent. ICQ# 1318344
Patience comes to those who wait.
...It's not "Beanbag Love", it's a "Transanimate Relationship"...
-- 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
iD8DBQE8CkClysXuytMhc5ERAkaDAJ9IqQu++Ilk9dQosmALYsG5HF3fnQCeOPE+
as3E+/tPWumh1RU+lBVkzcU=
=YARi
-----END PGP SIGNATURE-----
