[Freeciv-Dev] Re: cygwin audio

[swamp-dog@xxxxxxxxxxxx (Guy Harrison)]

On Mon, 17 Jun 2002 13:12:34 +0200 (MEST), Per I Mathisen
<per@xxxxxxxxxxx> wrote:

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

Yes. I've learnt that the fundamental part of the windows sound system
is the waveOut "device" - a Win3.x feature no less, and everything else
sits on top of it. It would be more correct to think of it as a single
channel (can be mono or stereo) or stream. Whatever data arrives down
this channel is what the card plays. If multiple sound sources need
playing simultaneously then they all need merging before they get sent
to waveOut (yes software mixer). One can assume only a single waveOut
per soundcard even though many cards will successfully allow waveOpen to
succeed multiple times (and work). I got that info from old postings and
will need to investigate a bit more - DirectX may have killed that
feature.

DirectX is the only system capable of mixing multiple inputs
transparently. If someone has the DirectX 3 SDK I'll take a look but I
can't find it anywhere.

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

Understood.

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

I'm going to try and find some usable mixer sources. See what's
involved. The waveOut interface is pretty low-level, I can almost "see"
the interrupt service routine sat behind it!

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

Agreed.

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

It is now a moot point. I stressed it not too severely today and it
broke, playing all the sounds in the wrong order. There wasn't enough
code anyway. There's always got to be lots and lots of code or it won't
work. Everybody knows that ;-)


-- 
swamp-dog@xxxxxxxxxxxx