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

[Matt]

I just finished a 3 day FreeSCI and SDL debugging state. I now know why 
by default OS X users do not have sound (independent of the ADLIBEMU 
flag).

I noticed that the SDL_Init on the audio was failing. Checking SDL it 
looked like SDL was calling some older, with limitations, sound 
functions (we call them 'Carbon' as they work as well as on OS 9, the 
old Mac platform generation, as on OS X, the NextStep platform).  I 
started to think that the sound issue was due to using these Carbon 
functions until I got the sample SDL sound utility to work.

Checking step by step why the SDL audio init function failed during the 
FreeSCI initialization (by just initializing SDL audio during several 
stages of the initialization) showed me that FreeSCI was not using the 
SDL sound server but the unix sound server.

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.

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.

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?

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?

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?

Thanks

Matt

ps
I would not mind submitting the above SDL sound server change, I just 
want to make sure everyone would be ok with this.