Re: [freesci-develop] Glutton OS X sound support & wrapper for FreeSCI, was: Concerning C416: No sound on Mac OS X

[Christoph Reichenbach]

Hi,

[SDL issues]
> That is more or less correct -- SDL is an extremely low-level API -- it
> fundamentally provides little more than a raw framebuffer and a
> optimized blitting functions.  For example, somethingl ike a line draw 
> that X accellerates at the hardware level we have to draw pixel by pixel 
> then blit over.  :)

Ah, OK. Thanks for the clarification! :-)

> We could probably re-work the SDL driver to be more efficient, but the 
> GFX driver model really doesn't map well to the "just give me a bitmap 
> to display" model that SDL is based around.

Actually, I'd be surprised if lines were the biggest issue; I suppose
either manual crossblitting or our three-layer approach to buffering are
the problem here. (We need "manual" crossblitting to properly work with
Sierra's Z buffer model).

[...]
> >   Of course, SDL is much more popular and stable these days than it
> > was when we started working on FreeSCI. It still doesn't seem to have
> > any support for sound other than PCM, but it is definitely the most
> > worthwhile target for an initial implementation of a PCM driver.
> 
> And of course, since SDL is so portable, it makes new ports almost 
> trivially easy.  It's a nice least-common-denominator.. and a 
> platform-specific driver can always be written to take advantage of the 
> non-portable additional functionality that the platform offers.

Definitely true.

> Though since this was about OSX initially... why couldn't we use the 
> Xlib driver?  recent releases of OSX include a native X server..
> 
> > I will try to see whether I can fix the Glutton PCM sound infrastructure
> > during fall break so that you guys can work with that. Of course,
> > Glutton is nowhere as stable as the main branch, doesn't have savegames
> > etc., so a public release for non-glutton would be better.
> 
> "fix" as in architechural stuff, or as in "something's broken"?  

Sort of in between ;-)
Almost everything's there, except for something which bridges MIDI playing
to PCM feeds, a concrete implementation of such a bridge for some MIDI
player (PCM, Tandy, Adlib...) and a PCM driver. There are a few rought
edges to be ironed out, though: The PCM driver must be able to provide
a timing mechanism, and this must be the preferred mechanism for the rest
of the sound subsystem to hook up to (for obvious reasons).
  That's about it. It would also be nice to make use of configuration
information within the sound subsystem again, so that we don't have to
re-compile every time we want to test a different component 8-)

-- Christoph