ptitSeb
Serial Porter
How is the API change to go from Fluidsyth ->BASS+BASSMIDI ? Not too many thing to change in sound code?
Yep. I'll setup brighter default settings.
Release DooM 64 EX
- Thread starter ptitSeb
- Start date
M-HT
Very Active Member
Things are done differently, but it should be too difficult. (I didn't work much with fluidsynth or bassmidi, so take it with a grain of salt).
For comparison, here are my simple test programs for playing midi file.
Fluidsynth:
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include "fluidsynth.h"
int main(int argc, char *argv[])
{
fluid_settings_t* settings;
fluid_synth_t* synth;
fluid_player_t* player;
fluid_audio_driver_t* adriver;
settings = new_fluid_settings();
/* Set the synthesizer settings, if necessary */
fluid_settings_setstr(settings, "synth.sample-rate", "22050");
fluid_settings_setstr(settings, "synth.polyphony", "64");
synth = new_fluid_synth(settings);
player = new_fluid_player(synth);
fluid_settings_setstr(settings, "audio.driver", "alsa");
adriver = new_fluid_audio_driver(settings, synth);
fluid_synth_sfload(synth, "GeneralUser GS FluidSynth v1.44.sf2", 1);
fluid_player_add(player, "sequence-00.mid");
/* play the midi files, if any */
fluid_player_play(player);
/* wait for playback termination */
fluid_player_join(player);
/* cleanup */
delete_fluid_audio_driver(adriver);
delete_fluid_player(player);
delete_fluid_synth(synth);
delete_fluid_settings(settings);
return 0;
}
#include <stdio.h>
#include <unistd.h>
#include "fluidsynth.h"
int main(int argc, char *argv[])
{
fluid_settings_t* settings;
fluid_synth_t* synth;
fluid_player_t* player;
fluid_audio_driver_t* adriver;
settings = new_fluid_settings();
/* Set the synthesizer settings, if necessary */
fluid_settings_setstr(settings, "synth.sample-rate", "22050");
fluid_settings_setstr(settings, "synth.polyphony", "64");
synth = new_fluid_synth(settings);
player = new_fluid_player(synth);
fluid_settings_setstr(settings, "audio.driver", "alsa");
adriver = new_fluid_audio_driver(settings, synth);
fluid_synth_sfload(synth, "GeneralUser GS FluidSynth v1.44.sf2", 1);
fluid_player_add(player, "sequence-00.mid");
/* play the midi files, if any */
fluid_player_play(player);
/* wait for playback termination */
fluid_player_join(player);
/* cleanup */
delete_fluid_audio_driver(adriver);
delete_fluid_player(player);
delete_fluid_synth(synth);
delete_fluid_settings(settings);
return 0;
}
Code:
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include "bass.h"
#include "bassmidi.h"
int main(int argc, char *argv[])
{
HSOUNDFONT sfont;
HSTREAM midi;
BASS_Init(1, 22050, 0, 0, NULL));
atexit((void (*)(void)) &BASS_Free);
sfont = BASS_MIDI_FontInit("GeneralUser GS SoftSynth v1.44.sf2", 0);
{
BASS_MIDI_FONT fonts[1];
fonts[0].font=sfont;
fonts[0].preset=-1; // all presets
fonts[0].bank=0; // default banks
BASS_MIDI_StreamSetFonts(0, fonts, 1);
}
midi = BASS_MIDI_StreamCreateFile(0, "sequence-00.mid", 0, 0, BASS_STREAM_AUTOFREE, 0);
BASS_ChannelPlay(midi, 1);
while (BASS_ChannelIsActive(midi) == BASS_ACTIVE_PLAYING) {
sleep(1);
}
return 0;
}ptitSeb
Serial Porter
BASSMIDI:
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include "bass.h"
#include "bassmidi.h"
int main(int argc, char *argv[])
{
HSOUNDFONT sfont;
HSTREAM midi;
BASS_Init(1, 22050, 0, 0, NULL));
atexit((void (*)(void)) &BASS_Free);
sfont = BASS_MIDI_FontInit("GeneralUser GS SoftSynth v1.44.sf2", 0);
{
BASS_MIDI_FONT fonts[1];
fonts[0].font=sfont;
fonts[0].preset=-1; // all presets
fonts[0].bank=0; // default banks
BASS_MIDI_StreamSetFonts(0, fonts, 1);
}
midi = BASS_MIDI_StreamCreateFile(0, "sequence-00.mid", 0, 0, BASS_STREAM_AUTOFREE, 0);
BASS_ChannelPlay(midi, 1);
while (BASS_ChannelIsActive(midi) == BASS_ACTIVE_PLAYING) {
sleep(1);
}
return 0;
}
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include "bass.h"
#include "bassmidi.h"
int main(int argc, char *argv[])
{
HSOUNDFONT sfont;
HSTREAM midi;
BASS_Init(1, 22050, 0, 0, NULL));
atexit((void (*)(void)) &BASS_Free);
sfont = BASS_MIDI_FontInit("GeneralUser GS SoftSynth v1.44.sf2", 0);
{
BASS_MIDI_FONT fonts[1];
fonts[0].font=sfont;
fonts[0].preset=-1; // all presets
fonts[0].bank=0; // default banks
BASS_MIDI_StreamSetFonts(0, fonts, 1);
}
midi = BASS_MIDI_StreamCreateFile(0, "sequence-00.mid", 0, 0, BASS_STREAM_AUTOFREE, 0);
BASS_ChannelPlay(midi, 1);
while (BASS_ChannelIsActive(midi) == BASS_ACTIVE_PLAYING) {
sleep(1);
}
return 0;
}
Oh, thanks for the samples
!Will look at that.
ZXDunny
Deep avatar
- Joined
- Oct 12, 2010
- Messages
- 2,585
Another vote for BASS here - I use it for PandaBAS's sound handler and it's great. It does however have some bugs in it under ARM - small samples on the Pandora tend to get the first few Ms clipped before being brought up to full volume. I've reported it, but as the Pandora is the only ARM platform affected, it's likely the Pandora at fault rather than BASS... that's not to say that it's not still annoying though.
Would be nice to see it used in other ports too, for a small performance boost.
D.
Would be nice to see it used in other ports too, for a small performance boost.
D.
milkshake
Advanced Member
Yes
Magic Sam
Forever Homebrew
Hi,
- Bug report #1: while in game, if you go into the options menu (to save your progress for example) then back in game, it'll be much more brighter than before. You have to go back into the options menu, then back again in game to restore the usual darkness of DooM 64 (on a Rebirth Pandora, Super Zaxxon 1.60, default drivers)
- Bug report #2: when you exit the game, dark squares remain visible on parts of your desktop (XFCE)
- Sound gets laggy when using the machinegun.
- Could someone send a feature request upstream, to be able to skip the intro with a new option in config.cfg ?
Cheers, Magic Sam
- Bug report #1: while in game, if you go into the options menu (to save your progress for example) then back in game, it'll be much more brighter than before. You have to go back into the options menu, then back again in game to restore the usual darkness of DooM 64 (on a Rebirth Pandora, Super Zaxxon 1.60, default drivers)
- Bug report #2: when you exit the game, dark squares remain visible on parts of your desktop (XFCE)
- Sound gets laggy when using the machinegun.
- Could someone send a feature request upstream, to be able to skip the intro with a new option in config.cfg ?
Cheers, Magic Sam
ptitSeb
Serial Porter
Hi,
#1 I have seen that yesterday. Quite a strange bug, I'll try to fix it (I think it's an upstream bug)...
#2 Yes, I have seen, but I have considered it to be minor (I think the destruction of the EGL Context is not perfect and I should take a deeper look there).
Sound with Machinegun is OK on a Gigahertz, so I didn't notice. I'll look at switching to BASS (but that will take some time).
Ah yes, why not a "No Intro" option yes. I'll take a look.
Magic Sam
Forever Homebrew
Regarding the softsynth, you could also have a look at TiMidity++ and WildMIDI. Both projects are licensed under GPL / LGPL.
EDIT: WildMIDI compiles like a charm on the Pandora
EDIT: WildMIDI compiles like a charm on the Pandora
Last edited by a moderator:
M-HT
Very Active Member
I took a look at Kex Engine sourcecode and switching from Fluidsynth to BASSMIDI is more work than I thought (but not impossible, I think). That's because the engine isn't giving Fluidsynth a midi file to play(convert), but it's parsing the midi file and giving individual midi events to Fluidsynth at appropriate times.
Last edited by a moderator:
wow ... never really played Doom64 before. I don't think it's the best version, it is by far the creepiest version though!
It looks and feels like a cross between Duke Nukem 3D and Quake.
Unfortunately it entirely lacks the "Doom-feeling". Probably some good music instead of creepy background noise would have helped here. So far I find it rather unpleasant to be in the game ... the port is good though, I especially like the feature of just pointing it to the .rom file and everything is done for you.
Anyway, since it is available as a port an brings all the benefits of easily customizing the controls and saving where you want and so on I will try to finish it. Not using headphones though, unlike Doom I&II totally not worth it
On the first level I saved the game, and suddenly everything looked like you're wearing Night Vision Goggles in Doom I&II. In the last room of the first level, the one with the door to the exit room, there is a column in the room. A Demon is standing to the left and another one to the right, behind the column when you enter the room (playing default difficulty-level). While I had the brightness-bug, a light was circling around that column.
Later I decided to load that save game again. The brightness was now correct, but there is no longer a light circling around that column. It is just static pointing about where the second demon is waiting.
I don' know if the light is circling when you reach there without triggering the bug?
Anyway, maybe this helps to pin down the problem ...
It looks and feels like a cross between Duke Nukem 3D and Quake.
Unfortunately it entirely lacks the "Doom-feeling". Probably some good music instead of creepy background noise would have helped here. So far I find it rather unpleasant to be in the game ... the port is good though, I especially like the feature of just pointing it to the .rom file and everything is done for you.
Anyway, since it is available as a port an brings all the benefits of easily customizing the controls and saving where you want and so on I will try to finish it. Not using headphones though, unlike Doom I&II totally not worth it
I encountered the same bug, but something else must be wrong here:
On the first level I saved the game, and suddenly everything looked like you're wearing Night Vision Goggles in Doom I&II. In the last room of the first level, the one with the door to the exit room, there is a column in the room. A Demon is standing to the left and another one to the right, behind the column when you enter the room (playing default difficulty-level). While I had the brightness-bug, a light was circling around that column.
Later I decided to load that save game again. The brightness was now correct, but there is no longer a light circling around that column. It is just static pointing about where the second demon is waiting.
I don' know if the light is circling when you reach there without triggering the bug?
Anyway, maybe this helps to pin down the problem ...
ptitSeb
Serial Porter
Yes, that will surely render things more difficult.
Also, is BASS really that efficient? By default in the engine, Fluidsynth is configured with 80 midi channels and a total of 256 channel polyphony (quite a lot !). In the intro, I tried to lower the number of midi channel but get "out of channels" warning, and I must keep max polyphonie at 128 also to avoid (most) out of channels warning. So that's a lot of voices at the same time (and fluidsynth eat something like 50~60% cpu at this moment on my gigahertz). Do you think BASS can do better (cpu wise) ?
Thanks for the report (yes, that "music" is really creepy, and I miss the DooM II music !). Will look at this brightness buf this WE I think...wow ... never really played Doom64 before. I don't think it's the best version, it is by far the creepiest version though!
It looks and feels like a cross between Duke Nukem 3D and Quake.
Unfortunately it entirely lacks the "Doom-feeling". Probably some good music instead of creepy background noise would have helped here. So far I find it rather unpleasant to be in the game ... the port is good though, I especially like the feature of just pointing it to the .rom file and everything is done for you.
Anyway, since it is available as a port an brings all the benefits of easily customizing the controls and saving where you want and so on I will try to finish it. Not using headphones though, unlike Doom I&II totally not worth it
I encountered the same bug, but something else must be wrong here:
On the first level I saved the game, and suddenly everything looked like you're wearing Night Vision Goggles in Doom I&II. In the last room of the first level, the one with the door to the exit room, there is a column in the room. A Demon is standing to the left and another one to the right, behind the column when you enter the room (playing default difficulty-level). While I had the brightness-bug, a light was circling around that column.
Later I decided to load that save game again. The brightness was now correct, but there is no longer a light circling around that column. It is just static pointing about where the second demon is waiting.
I don' know if the light is circling when you reach there without triggering the bug?
Anyway, maybe this helps to pin down the problem ...
Magic Sam
Forever Homebrew
Hi,
Just to say I'm enjoying this game a lot OK, that's quite a departure from "traditional" DooM, but I don't think it's an issue here. Midway has done a hell of a good job IMHO: the music is really creepy, the graphics are gorgeous, the levels are very well designed, etc...
That's amazing what one can do with that good old DooM engine !
Cheers, Magic Sam
Just to say I'm enjoying this game a lot
OK, that's quite a departure from "traditional" DooM, but I don't think it's an issue here. Midway has done a hell of a good job IMHO: the music is really creepy, the graphics are gorgeous, the levels are very well designed, etc...That's amazing what one can do with that good old DooM engine !
Cheers, Magic Sam
M-HT
Very Active Member
I tried playing one midi file with one soundfont using Fluidsynth and using BASSMIDI (on original CC Pandora at 600 MHz).With Fluidsynth the music was stuttering - 100% CPU utilization, load average was higher than 1.
With BASSMIDI the music was OK - CPU utilization was around 15% if I remember correctly.
This was when using frequency 22050.
I think the main difference in speed is because Fluidsynth uses floats and BASSMIDI uses fixed point ints (on ARM).
You can test it yourself using the test programs in post #22.
Last edited by a moderator:
ptitSeb
Serial Porter
Oh, impresssive difference ! Fuildsynth use float yes. Ok, will do some testing with your code this W.E. (or before) and I'll report my results here.
Hi, this is MP2E, one of the two Lead Maintainers of Doom64 EX. The project's homepage can be found here if you'd like to keep up with recent developments or post on our forums. Kex is currently looking to take over the world! Kaiser and I are planning to release binaries for Win32, Win64, Linux x86 and x64, Raspberry Pi, Mac OS X, Mac OS 9, and now probably the OpenPandora port! Android is planned sometime in the future as well, as soon as I start to get over my Java-phobia
Doom64 is an incredibly dark game, and since EX strives to emulate the original you may need to turn gamma and brightness up. I know I do Kaiser and I have considered switching the sound system time and time again, as we *really* despise FluidSynth(to the point of considering writing an in-house solution) but Kaiser was skeptical of all of the alternatives I showed him because of the particular way that D64 handles midi events.
I'm sure you've noticed, but *EVERYTHING* is a MIDI in D64, including things like monster sounds! A midi "file" isn't typically played, per se, a set of MIDI events are streamed to fluidsynth. Any code is appreciated to help us get around this roadblock.
Unfortunately, if you port it to BASSMIDI I will not be able to accept that contribution as, that code is inherently incompatible with our codebase. Kex, and therefore my branch "kexplus" are available under the GPLv2 which does not allow for linking of components unless they are under a more permissive license than the GPLv2 itself. Since BASSMIDI is non-commercial, it takes away one of the rights the GPL guarantees and is therefore incompatible. I'm sorry, I cannot do anything about this because our code is derived from the Doom engine, and all copyright holders(including everyone involved at ID Software) would need to be notified AND give Kaiser and I permission to add a clause to allow non-free linking.
Please use something that is BSD, GPLv2, zlib, or some other similarly permissive license and I will work with you to ensure your work is incorporated upstream
Doom64 is an incredibly dark game, and since EX strives to emulate the original you may need to turn gamma and brightness up. I know I do
Kaiser and I have considered switching the sound system time and time again, as we *really* despise FluidSynth(to the point of considering writing an in-house solution) but Kaiser was skeptical of all of the alternatives I showed him because of the particular way that D64 handles midi events.I'm sure you've noticed, but *EVERYTHING* is a MIDI in D64, including things like monster sounds! A midi "file" isn't typically played, per se, a set of MIDI events are streamed to fluidsynth. Any code is appreciated to help us get around this roadblock.
Unfortunately, if you port it to BASSMIDI I will not be able to accept that contribution as, that code is inherently incompatible with our codebase. Kex, and therefore my branch "kexplus" are available under the GPLv2 which does not allow for linking of components unless they are under a more permissive license than the GPLv2 itself. Since BASSMIDI is non-commercial, it takes away one of the rights the GPL guarantees and is therefore incompatible. I'm sorry, I cannot do anything about this because our code is derived from the Doom engine, and all copyright holders(including everyone involved at ID Software) would need to be notified AND give Kaiser and I permission to add a clause to allow non-free linking.
Please use something that is BSD, GPLv2, zlib, or some other similarly permissive license and I will work with you to ensure your work is incorporated upstream
M-HT
Very Active Member
As I see it you need a softsynth which uses soundfonts to play midi. I'm only aware of Fluidsynth, BASSMIDI and maybe Timidity++, so you don't have many options.
Maybe you could play multiple midi streams simultaneously. Both Fluidsynth and BASSMIDI support this.
I admit I didn't check the licence of Kex before suggesting BASSMIDI, but you could use BASSMIDI with your codebase if you use it as a plugin.Unfortunately, if you port it to BASSMIDI I will not be able to accept that contribution as, that code is inherently incompatible with our codebase. Kex, and therefore my branch "kexplus" are available under the GPLv2 which does not allow for linking of components unless they are under a more permissive license than the GPLv2 itself. Since BASSMIDI is non-commercial, it takes away one of the rights the GPL guarantees and is therefore incompatible. I'm sorry, I cannot do anything about this because our code is derived from the Doom engine, and all copyright holders(including everyone involved at ID Software) would need to be notified AND give Kaiser and I permission to add a clause to allow non-free linking.
Please use something that is BSD, GPLv2, zlib, or some other similarly permissive license and I will work with you to ensure your work is incorporated upstream
BTW do you know how the midi playing was handled on N64? Did the game also use a softsynth or was it sending midi events to the OS / MIDI hardware ?
ZXDunny
Deep avatar
- Joined
- Oct 12, 2010
- Messages
- 2,585
Good luck getting it to run at any kind of framerate on the Raspberry PI then - floating point performance there is even worse than on the Pandora. Running the Pandora port is quite flakey at 800Mhz on my CC pandora framerate-wise, and a non-FP sound lib would really help.Hi, this is MP2E, one of the two Lead Maintainers of Doom64 EX. The project's homepage can be found here if you'd like to keep up with recent developments or post on our forums. Kex is currently looking to take over the world! Kaiser and I are planning to release binaries for Win32, Win64, Linux x86 and x64, Raspberry Pi, Mac OS X, Mac OS 9, and now probably the OpenPandora port! Android is planned sometime in the future as well, as soon as I start to get over my Java-phobia
[...]
Unfortunately, if you port it to BASSMIDI I will not be able to accept that contribution as, that code is inherently incompatible with our codebase. Kex, and therefore my branch "kexplus" are available under the GPLv2 which does not allow for linking of components unless they are under a more permissive license than the GPLv2 itself. Since BASSMIDI is non-commercial, it takes away one of the rights the GPL guarantees and is therefore incompatible. I'm sorry, I cannot do anything about this because our code is derived from the Doom engine, and all copyright holders(including everyone involved at ID Software) would need to be notified AND give Kaiser and I permission to add a clause to allow non-free linking.
Please use something that is BSD, GPLv2, zlib, or some other similarly permissive license and I will work with you to ensure your work is incorporated upstream
D.
Yep, everything! I believe it is because of the way that the N64's DSP for sound processing works, everything is handled as an "event" that was very similar to MIDI, except with MOD style samples provded by the cartridge.
Those are all we know of, as well. The issue is converting it into a monolithic file because the midi events we are using are custom in a few instances, so a vanilla MIDI wouldn't work completely. Perhaps with some review we could write a format derived from MIDI that can handle these special events.
I wouldn't mind BASSMIDI support as an optional backend, I just don't want to *depend* on it since it's a bit trickier to destribute. If it is the only practical way to get sound to run on the OpenPandora at decent speeds, then I am all for either distributing them in 2 seperate packages or perhaps a disclaimer could pop up(similar to RetroArch) and prompt the user to delete BASSMIDI, if they want.
Such a shame that all of the MIDI libraries available have some inherent problem, though.
TL;DR BASSMIDI is fine as long as fluidsynth code can coexist with it, I'd rather see a polished port than a crippled port because of silly idealisms. I'm a practical open source advocate, not a zealot.
Last edited by a moderator:
