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

[Christoph Reichenbach]

Hi,

[...]
> To summarize, its probably not the forked-off process itself, but a 
> missing memory allocation/setup or so that is needed for Mac functions 
> to work in a thread/forked-off process.

OK, thanks for the explanation!

[...]

> If the preference is to ifdef the fix for OS X, then thats fine for me. 
> What I was thinking was that if the SDL sound output is chosen, it 
> would be better to use the SDL sound server too by default.

The SDL sound server has a theoretical "bug by design", though, which
hasn't bitten anyone yet: In theory, it's possible for FreeSCI's resource
manager to reclaim the memory associated with a song behind the back
of the sound server (this could be fixed without too much effort, but no
one has bothered to do so yet). This is why I try not to use it-- the
only place where SDL works really well for us ATM is PCM output.

[...]
> For the ifdef-fix would the preference be to change the 'config.c' 
> where the default sound server gets set or 'sound.c' where the sound 
> servers get listed?

sound_server_find_driver(), in 'sound.c', would be the "correct" place,
as it is supposed to implement platform strategies for picking the
right driver. 'config.l' should not implement any platform-specific stuff.
'config.c' must never be touched, as it is generated from config.l (using
lex).

> >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
> There are already plenty of ifdefs in sound.c, in the 0.3.4a code there 
> were some DREAMCAST ifdefs inside config.c but they are gone in the 
> latest tip (version mentions 0.3.4c).

I'm not sure about this. Walter?

> >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
>
> The code compiled fine on my machine however the latest daily logs on 
> sci.hellabs.org show a compiler error in 'tools.c', the same bug seems 
> to appear in the last couple of builds, maybe the build log just does 
> not get refreshed.

Looks like this is only for the Win32 build. I'll ask Claudio.


-- Christoph