News . About . Screenshots . Downloads . Forum . Wiki . Tracker . GitLab

FS#33 - Soundtrack support

Attached to Project: Project::OSiRiON
Opened by Stijn Buys (Ingar) - Monday, 14 March 2011, 17:36 GMT
Last edited by Stijn Buys (Ingar) - Tuesday, 03 December 2013, 20:57 GMT
Task Type Planned Feature
Category src
Status New
Assigned To Stijn Buys (Ingar)
Operating System All
Severity Medium
Priority Normal
Reported Version Development
Due in Version 0.4.0
Due Date Undecided
Percent Complete 0%
Votes 0
Private No


Add client support for playing background music.It should be possible to define a number of audio tracks per zone,
for the intro, and make provisions for 'battle music'. Investigate support for FLAC, OGG and MP3 audio formats.
This task depends upon

Comment by Michael Rodenhurst (Thorn) - Sunday, 15 May 2011, 00:31 GMT
MP3 is not feasible.
To distribute a binary containing an MP3 decoder a license must be purchased from Fraunhofer and Thomson
Comment by Michael Rodenhurst (Thorn) - Friday, 26 August 2011, 20:15 GMT
-'Framework' side
Each "music=music/file.ogg" line in the zone.ini is added to a list and played randomly. Each zone can also define battlemusic= lines. (Not sure if this makes sense, would battle music be different in tsu khan systems than lindblade systems?)

-Engine side
-File streaming - Two methods to do this: The file loaders can be altered to only buffer a section of the file (perhaps another argument in the static load function for buffer size. 0 would return the full file as PCM).

The other way is to have the file readers and stream readers seperate, which would mean more files in src/audio, such as having an oggstream.h aswell as the already existing oggfile.h, but this interface would probably be cleaner.

In and interface is required that will use alQueueBuffers to queue the next 'sample' of the stream to be played.

I think that's everything required? :D

Comment by Stijn Buys (Ingar) - Friday, 26 August 2011, 20:30 GMT
The file loaders should be implemented as a derived class (or on top off) the streamers,
the file reader would just 'play' the entire stream and store it for use. Two files,
but shared code, which is good.

A seperate class would be required to handle the actual streaming and act as a layer
between the streamers and OpenAL.

The trickiest part is getting the 'music=' lines from the server, where the ini file resides, to the client.
I will have to break the network protocol, and there's the fast and easy way (add some stuff to transmit music definitions)
or the more elaborate way where we add protocol messages to handle generic zone parameters. This would help in avoiding to
break network compatiility again in the future.