[Freeciv-Dev] Re: cygwin audio

[Andreas Kemnade <akemnade@xxxxxxxxxxxxxxxxxxxxxxxx>]

Guy Harrison writes:

 > Sure, except it raised a larger problem hence no patch atm. I have
 > attached my audio_winmm.c which attempts to address both issues. The C++
 > comments within it serve only to supplement this post and will be
 > removed when I get round to figuring out how to format it correctly.
 > 
 > sndPlaySound() aborts the current sound in favour of the newest one
 > received. Result is that the end user hears only the last sound of a
 > given series, possibly with some seeming pops, crackles and partial
 > sounds as the preceeding sounds commence then are aborted. I'll come
 > back to this particular issue later. Needless to say, this doesn't just
 > affect the CygWin/XFree version, it affects the CygWin/WinAPI native
 > compilation also.

 > There's one possible fix for NT. An audio thread. It can be implemented
 > in one of two ways. Either have one dedicated thread or one transient
 > thread for each sound played. I've chosen the latter and while everybody
 > shudders I'll explain why not the former...
What about using waveOut()? AFAIK it is able run asynchron. It can
send messages to a window. So a hidden dummy window can be opened to
handle these stuff and no multithreading is needed.

The only issue is that playing several sounds in parallel is not
solved and waveOut() takes raw waveform data.


 > 
 > Theoretically, one thread makes sense. It can be initialised by
 > audio_plugin->init() and killed by audio_plugin->shutdown() but I
 > suspect communicating with it is going to require yet more windows code.
 > I don't believe CygWin has completely working pthread yet and unless I'm
 > mistaken I doubt the CygWin "-mno-cygwin" compilation could use it if it
 > had. I couldn't code it in any case - I'm a windoze programmer.
 > Secondly, it would have to be absolutely guaranteed that if civclient
 > died it could take out that thread with it. For those unfamiliar with
 > windows the reason is "last man standing"="main thread". We're only
 > talking about one *single* WinAPI call here and look how much trouble it
 > is causing.
Freeciv already uses multithreading in the server (with
beginthreadex()) to read a line from stdin non-blocking.

 > 
 > The latter solution can be kept entirely within audio_winmm.c and has no
 > impact on the unix version whatsoever which can only be good.
 > Additionally I think we can use this NT solution across the board thus
 > dispense with both the runtime OS version checking and
I also think an audio thread is the cleaner solution.
What about sending the filenames though windows message system?
The audio thread wouldn't need a dummy window for that.

Greetings
Andreas Kemnade