[Freeciv-Dev] Re: cygwin audio

[Per I Mathisen <per@xxxxxxxxxxx>]

On Mon, 17 Jun 2002, Guy Harrison wrote:
> 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.

This is bad. Both Esound and SDL_mixer code allows up to a certain maximum
number of sounds to run in parallell.

> First, a general issue. How is the Freeciv "virtual soundcard" supposed
> to behave? Obviously from the code it can initialise & terminate plus
> play & stop sounds. What else - suppose it got handed a series of
> lengthy sounds in a particular turn that wouldn't be completed by the
> end of that turn?

End of turn is irrelevant to the sound code. It should ignore it. When a
sound is given to the sound code, it should play it, period. Only in the
case of repeating sound should you have a way to abort it, but you may
also implement this by choosing to not continue repeating it (as opposed
to aborting immediately: esound code aborts while SDL_mixer just stops
repeating, both approaches are acceptable).

But it must also be able to play several sounds at once. Note that the
number of sounds passed to it could get very high indeed (eg unit being
transported across the map by train), so you should add a maximum of
simultaneous sounds to avoid DoS'ing the system.

> My concern is now clear. This trivial fix is going to block the main
> thread for the duration "sounds-queued-this-turn -1".

Sound should _never_ block the main thread.

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

I believe SDL_mixer uses one thread per sound channel also. But it avoids
the overhead of creating/destroying threads by allocating them in advance.
The number of pre-allocated threads becomes the maximum of simultaneous
sounds. See client/audio_sdl.c for how I used this.

IMHO, dynamically creating/destroying a thread for each sound will waste
too many CPU cycles to be feasible.

Yours,
Per

"It is difficult to catch a black cat in a dark room.
Especially if there is no cat there." - Confucius