[crossfire] Sound information, was Re: Using openal for client audio?

[Mark Wedel]

Alex Schultz wrote:
> Nicolas Weeger wrote:
>>>   Thoughts/comments?
>>>     
>> Sounds fine by me.
>> Though I'd first redo the sound system for the server :)
> Agreed. OpenAL sounds like a fine choice for client sound support, but
> personally I think the server and protocol infrastructure and should be
> redone first, but of course, whatever order people get things done in
> works as I'm sure the OpenAL code could be ported easily enough to
> whatever changes happen in the rest of the sound infrastructure.

  IMO, there are really 3 pieces of this:

1) How sounds are specified in objects
2) How that information is communicated to the client
3) How the client uses that information.

  Each builds upon the previous point to some extent - the server can't really 
know how to send sound data to the client until it knows how it will have sound 
data.  Likewise, hard to write a good implementation on the client unless you 
know how it will get the data.

  I think this has been discussed before, but doesn't look like it is recorded 
on the wiki:
http://wiki.metalforge.net/doku.php/dev_todo:fix_sound

  For objects (which then includes archetypes), my thought is there would be 
something like a linked list of sound attributes.  This would contain:

- What event to play the sound on (object moves, object is applied, object is 
destroyed, etc).  This could be extended later, as only the server cares about 
this - it basically determines when the server sends sound information to the 
client.  However, having a full list earlier makes things easier.

- What sound to play (in the object, this is free form text - for archetypes, it 
may be desirable to do something like the images, which we assign a number to 
each sound file and thus can send information by number instead of name. 
However, since it is probably desirable to specify sound names in maps, which 
may not be standard sound files, it probably means that that table must be 
dynamically updatable (no entry for this file, lets add a new one), and likewise 
client must be able to deal with a larger table.

- Attributes of the sound.  This could be things like is the sound continuous 
(so a fountain) or single use, like say a door being destroyed.  It is perhaps 
this is redundant with event (there could be pseudo event, like event_always to 
denote always play this sound).  Other attributes could be volume - may want to 
use the same sound file, but use different volumes.

In terms of sound file availability, I don't really like the idea of this media 
provided by the server itself.  What I'd instead suggest is that when a client 
connects to the server, the server can tell it the location of its media file, 
as well as current version.  Client can see if it has downloaded that, and if 
not, go and download it.  I'd suggest it should use http as a protocol for this 
- for one, http access is extremely common - if you can run a server, almost 
certainly you can have a place to put up files available by http.  Second is 
that if/when the new metaserver stuff is done, that would probably also use http 
logic (for similar reasons), so that code/library could be re-used.