[Freeciv-Dev] Re: cygwin audio

[swamp-dog@xxxxxxxxxxxx (Guy Harrison)]

On Mon, 17 Jun 2002 20:50:30 +0200, Andreas Kemnade
<akemnade@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:

>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.

I envisage waveOut() being quite hungry for a quick response.
Nevertheless, it may be the only remaining option if mixing is to be
supported. DirectX 3 seems have vanished off the face of the earth. I'm
not sure DX is a good route in any case.

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

I'll try locate some mixer sourcecode tomorrow. If I can locate
something GPL'ish even better.

> > 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.

Ah, right! ... ... Drat, that links against M$ runtime so I can't use it
for CygWin/X. Such is life.

> > 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.

Agreed, especially as the multithread one failed on me. ;-)

>What about sending the filenames though windows message system?
>The audio thread wouldn't need a dummy window for that.

I reckon that's exactly what I'll do now.


-- 
swamp-dog@xxxxxxxxxxxx