Notice: Trying to access array offset on value of type bool in /srv/http/osirion/tracker/scripts/details.php on line 222 FS#33 : Soundtrack support


  • Status New
  • Percent Complete
  • Task Type Planned Feature
  • Category src
  • Assigned To
    Stijn Buys
  • Operating System All
  • Severity Medium
  • Priority Very Low
  • Reported Version Development
  • Due in Version 0.4.0
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Project::OSiRiON
Opened by Stijn Buys - 2011-03-14
Last edited by Stijn Buys - 2013-12-03

FS#33 - Soundtrack support

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.

Michael Rodenhurst commented on 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

Michael Rodenhurst commented on 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

Stijn Buys commented on 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.


Available keyboard shortcuts


Task Details

Task Editing