Re: [freesci-develop] Concerning C416: No sound on Mac OS X

[Christoph Reichenbach]

Hi,

[...]
> Basically in config.c the default pcmout_driver gets set by 
> pcmouf_find_driver(NULL) which returns the SDL one, about 5 lines down 
> the default sound server driver is defaulted by 
> sound_server_find_driver(NULL).
> 
> The first pcmout driver is pcmout_driver_sdl, the first sound server 
> driver is sound_server_unix. The SDL audio init inside the unix sound 
> server fails.

Good job debugging this! Do you have any ideas as to what the reason
for this is? Are there some special resources only allocated for
the initial process, but not to forked-off processes?

> The easiest way is just to start the FreeSCI with sound support is "-S 
> sdl".
> I tried this (with -Madlibemu) and I am enjoying now Space Quest 3 with 
> sound. FreeSCI rocks!
> 
> The readme mentions that the SDL sound driver is the default driver:
> >- sound_server:  FreeSCI has different ways to handle the concurrent 
> processing of sound output. They are:
> >  * sdl: A threaded SDL sound server
>  > * unix: A forked-off sound server
> >  Generally, the sdl sound server (default) should provide better 
> performance, if available.

Yep, that's a bug in the docs. I'm not sure about performance here;
does anyone have concrete numbers on that? In any case, we can default
to the SDL one on OS X. Are there any preprocessor macros or easy
runtime checks to check for it? (The function we use for picking a
sound server is a function precisely so that it can be customised
for individual platforms. (At least I hope it's a function; I didn't
bother to check-- almost everything else is, though).)

> Would it be possible to correct the default sound server driver in 
> sound.c, so move the sound_server_sdl above the sound_server_unix?

If it really performs better in general, that makes sense. I believe
that using a platform-specific handler would be more robust, though.

> In the freesci 0.3.4a release I noticed a lot of DREAMCAST comments, in 
> the latest cvs snapshot I do not see these anymore in sound.c, is it 
> the goal to move the ifdefs out of the sound.c and so on or is this 
> just an archiving/merging issue?

I'm not sure what you mean there.

> Also, I noticed that the latest overnight builds were breaking on 
> mkdir, is there a fix for this already planned or can anyone submit a 
> fix to the build system?

I wasn't aware of that. There has been very little development going
on lately, so there's not really a need for any more recent builds
anyway. When development picks up again, it may be worth bugging Claudio
(or whoever maintains that thing) about this.

Thanks for investigating these issues!

-- Christoph