FMOD Ex prevent inclusion into Debian and Ubuntu about opentesarena HOT 17 CLOSED

I didn't know that FMOD Ex had those restrictions with Debian and Ubuntu. So it's still compatible with those two distributions, but it's just complicated to install? I'm not an expert on Linux, sorry.

The audio code here is limited to just one C++ class I believe, so it wouldn't be too big of a change to make. I've never used OpenAL-Soft, but since I've only been using FMOD for a couple months, I don't see why not. It would need to support MIDI music and 3D-positional Ogg or WAV sounds at a minimum though.

from opentesarena.

You'll never get OpenTESArena into Debian/Ubuntu and possibly other Linuxes... you'll likely have to ship your own version to run on all of them or support multiple distros. By you, I mean the brave soul who will maintain these. Not that it is all doom and gloom mind you, it is still doable, just more work for the project as you'll likely not get much help from downstream (distro).

As for MIDI support, you can use my WildMIDI and/or fluidsynth. That is what XLEngine uses (DaggerXL fame). He also uses OpenAL-Soft by the way, to tie it all in.

https://github.com/Mindwerks/wildmidi
http://xlengine.com/forums/viewtopic.php?t=1113
http://xlengine.com/xl-engine-midi-playback/

from opentesarena.

At first I thought FMOD Ex was the right way to go for having sound for all the desired operating systems, but now that looks like a mistake. I think I will start learning OpenAL-Soft then. And about MIDI, I'd say either one of those you suggested looks like a good choice. But why would the XLEngine developer decide to implement both? I'd like to go the simple path first if I could.

I'm not well-informed about using different sound fonts either. It looks like General MIDI is what DOSBox uses for Arena on Windows, but I don't know the details for Linux. I also don't know about loading specific sound fonts in the program itself. Windows just picks one automatically from what I've experienced.

from opentesarena.

FMOD is great for simplicity, it does a lot of footwork for you. It makes perfect sense for closed source projects. It can be used on FOSS projects as well, but it handicaps you due to it being closed source. It is still your choice! I just worry about getting it accepted into downstream distros... because... well, that is what I do for OpenMW (and other projects as a developer and downstream cheerleader). :)

Lucius implemented WildMIDI because it supported HMI MIDI which daggerfall uses. WildMIDI would then convert it internally into GM MIDI. WildMIDI currently only support GUS patches and not sf2 (soundfonts). If someone wanted SF2 he would then use WildMIDI to convert HMI to GM MIDI, then fluidsynth to render the GM MIDI. It was easy for him to just implement both and let the end-user choose whether to use GUS or SF2 for MIDI rendering to OpenAL... sounds like a lot of work, but the end result is below 1% CPU usage at the expense of disk-space due to the GUS/SF2 files.

Here are some options:

1. Do what lucius did to support both GUS/SF2. (openal-soft)
2. Pick either Fluidsynth or WildMIDI. (openal-soft)
3. Stick with FMOD.

I'm biased towards WildMIDI because I'm one of the developers as well. ;) SF2 support will come eventually.

Note: WildMIDI and Fluidsynth are softsynths... they work by playing back WAV samples and do not generate tones on their own. They trade CPU usage for disk space. That being said, WildMIDI does have plans to simulate/emulate an OPL3 (SB16) chip in the future so that it sounds more like what is used in DosBox... thereby making WildMIDI more than just a softsynth.

from opentesarena.

It would need to support MIDI music and 3D-positional Ogg or WAV sounds at a minimum though.

OpenAL Soft doesn't directly handle audio file formats. The formats you use and how you decode them are completely up to you, and all OpenAL needs to deal with are the decoded PCM samples. So it would actually be entirely possible to load the original sounds directly into OpenAL without having to convert them to ogg or flac files. Though of course the option to use ogg or flac or whatever else is still there if you want it (libsndfile is a really good portable library for decoding a large variety of audio formats; its only downside is it doesn't support MP3, due to patent issues).

MIDI is a bit weird since it's not really a sound format. But the same principle applies: you can do whatever you want to generate PCM samples from it (e.g. with WildMIDI, FluidSynth, a software OPL/FM synth renderer, whatever), and OpenAL Soft will happily play it for you.

from opentesarena.

Doing what Lucius did sounds like the best choice in the long run.

psi29a mentioned in issue #10 about using libogg. I think I should use that since having .mp3 support is not a high priority if I can have .ogg for Linux and Windows. My current plan is to use .ogg for game sounds and speech in cinematics.

I think I'm starting to get the gist of it. So WildMIDI and FluidSynth are fed .mid files with a GUS patch or soundfont, and they put decoded PCM samples into OpenAL-Soft buffers which are played as sound. And OpenAL-Soft also plays PCM samples from libogg.

I don't actually need to read in the sounds from the Arena files. I used WinArena to extract them, and Audacity to convert the .wav outputs into .ogg files. This is so they are easier to work with for everyone.

from opentesarena.

I think I should use that since having .mp3 support is not a high priority if I can have .ogg for Linux and Windows. My current plan is to use .ogg for game sounds and speech in cinematics.

Yeah, I wouldn't worry about mp3 if you don't need to. Don't forget though that Ogg Vorbis is a lossy format (better than mp3 at the same bitrate, but still not lossless). Ogg Speex is actually an alternative that's better suited to voice recordings, though it's also lossy. Ogg Opus is a more modern audio codec, though I don't know too much about it. For lossless, Ogg FLAC is the way to go, although the files will be bigger than the others.

BTW, libogg is only a low-level interface for handling ogg container files. It needs to be used with libvorbis to decode vorbis audio (ogg is just a container format that holds other data formats, similar to .avi which can use a variety of audio and video formats, though it's usually used in conjunction with the vorbis audio data, hence the name Ogg Vorbis). So you use libogg to get packets of vorbis data from the ogg container, then use libvorbis to get PCM samples from the vorbis data. Alternatively, libvorbisfile (part of the official vorbis package) will do that messy stuff for you, getting the decoded audio out of an ogg vorbis file without jumping through a bunch of hoops. libsndfile is functionally similar, just not restricted to ogg vorbis alone.

I think I'm starting to get the gist of it. So WildMIDI and FluidSynth are fed .mid files with a GUS patch or soundfont, and they put decoded PCM samples into OpenAL-Soft buffers which are played as sound.

More that WildMIDI and FluidSynth give back PCM samples that you can feed into OpenAL Soft buffers. Given the length of MIDI songs, they would typically be streamed by getting only a relatively small amount of samples to play at a time, getting more samples over time while cycling through OpenAL Soft buffers during playback.

I don't actually need to read in the sounds from the Arena files. I used WinArena to extract them, and Audacity to convert the .wav outputs into .ogg files. This is so they are easier to work with for everyone.

I think it'd be easier for users if they can just use the data files from Arena directly, rather than having to get an archive of pre-converted data (which is actually legally dubious; Arena may be released for free, but that doesn't mean you have permission to distribute converted/modified copies). Especially considering Bethesda only released the floppy disk version for free, while the CD version has some extra stuff with it (I think it has more video and voice work). Any conversion can be done internally by the engine when loading it. Mods would be able to use more modern formats, but it seems easier to me for the base Arena data to be used directly from Arena itself.

from opentesarena.

I was afraid I wouldn't be able to distribute the extracted files. That throws a wrench in the works because now I'm obligated to implement various decompression functions like in WinArena. But I would rather not be legally dubious.

I had been wondering why other projects still use the original data files.

libvorbisfile sounds like a better idea than libogg now. I don't think I'll need the extra capability of libsndfile at this point, unless... I'll be reading Arena's original files, which, in this case, I probably will be, so there should be no need for Ogg support then, unless people would like to add their own sound files at some point, like you mentioned with mods.

I just commented out all the FMOD code and removed the dependencies from the project, so that's out of the way now.

from opentesarena.

If you want, I can try implementing FluidSynth and OpenAL Soft support. I can also try implementing a virtual filesystem to more easily read the individual resources from Arena's data files.

from opentesarena.

That sounds like an excellent idea! My objective now with the original files is to read them into the program somehow (using your suggestion) and eventually turn the textures into SDL_Surfaces. Whatever method is used to bring the audio into a playable format is outside my expertise. WinArena does some cleaning up of the sound so it has fewer artifacts, though, so maybe that should be done here at some point, too?

SDL_Surface is a comfortable format for me to use since they can be easily drawn onto the screen as well as converted to float4 color buffers for the OpenCL kernel.

I have the FluidSynth source downloaded, but I'm not sure what to do with it. I've never used CMake before, you see. Am I suppose to compile it with Visual Studio?

from opentesarena.

Whatever method is used to bring the audio into a playable format is outside my expertise. WinArena does some cleaning up of the sound so it has fewer artifacts, though, so maybe that should be done here at some point, too?

A cursory glance at Arena's game files seems to show the sound files are in Creative's VOC format. I'm not sure what kind of "cleaning up" WinArena does though, is there any information about that? It should be possible to replicate it if needed, once I know what it does. Incidentally, libsndfile supports VOC, so I can use that to decode the files. Otherwise, I'll have to write a loader for it.

SDL_Surface is a comfortable format for me to use since they can be easily drawn onto the screen as well as converted to float4 color buffers for the OpenCL kernel.

Sounds reasonable.

I have the FluidSynth source downloaded, but I'm not sure what to do with it. I've never used CMake before, you see. Am I suppose to compile it with Visual Studio?

Unfortunately FluidSynth is a rather big pain to get built on Windows, due to its reliance on glib (there's been a bit of movement on their part to fix this, but it's not done yet). If you can, I'd try to find a prebuilt DLL with the necessary header and lib files.

from opentesarena.

One of the comments at the top of WinArena's "SoundDriver.cpp" file says that:

This program will load the raw audio data, and do some resampling and filtering to convert it to 44,100 Hz, 16-bit mono. Real-time mixing will allow multiple sounds to be played simultaneously.

That is the cleaning up I was referring to.

from opentesarena.

Ah. Yeah, OpenAL will handle the resampling and stuff automatically during mixing.

from opentesarena.

I've been reading through what the FluidSynth developers have been doing here. The latest post is from Monday. It sounds like they are in the process of getting it compatible with Windows, like you said earlier.

Edit: I found the pre-compiled .lib and .dll here. It's FluidSynth version 1.1.3.

from opentesarena.

Thank you @kcat for being awesome! :)

Just a heads up, wildmidi releases are here:
https://github.com/Mindwerks/wildmidi/releases

Libs available for linux,osx and windows, you can download either 32 or 64 bit, includes msvc support.

from opentesarena.

I just got the latest WildMIDI release from there, thanks. Would I be using wildmidi_lib.h and wildmidi_dynamic.lib for development, and libWildMidi.dll and wildmidi_dynamic.dll at runtime?

from opentesarena.

Have a look at the readme, the base directory is for mingw and the msvc directory is for... well, you guessed it. There is a readme there as well.

You'll need MSVCR80.dll eitherway.

You'll need to import wildmidi_lib.h and then link against wildmidi_dynamic.dll using wildmidi_dynamic.lib in msvc.

from opentesarena.