dnewhous wrote on 2021-03-17, 17:51:Wengier wrote on 2021-03-17, 17:42:Set mididevice=fluidsynth
Where?
Set it in the [midi] section of the config file (dosbox-x.conf). You can also do so via DOSBox-X’s built in graphical Configuration Tool.
Dosbox-x' config file
Similar to the setting in the first post, although you don't set the FluidSynth setting via the midiconfig option as mentioned there.
Anyone get this to work with soundfonts with standard DOSBox 0.74.x in windows?
Once I drop the fluidsynth.diff file into the DOSBox directory many games have improved music with just default values without changing anything in the config file but I can't seem to get DOSBox to read any soundfonts with it as the original post explains he was able to under linux.
The diff file does nothing on its own the perceived improvement is a placebo effect.
You need to use the diff file to patch the source code and then you need to compile Dosbox.
Dominus wrote on 2021-05-11, 06:07:The diff file does nothing on its own the perceived improvement is a placebo effect.
You need to use the diff file to patch the source code and then you need to compile Dosbox.
You're partically right. Upon looking into this further the difference in sound was caused by changing the games sound setup from SB to Sound Canvas.
Is there a download of a patched SVN LFN branch compiled for windows some where that you are aware of?
Either that of an ECE fork with LFN support?
Why not use different versions for different uses?
Want to play with fluidsynth, start the ECE.
Need LFN support, start a version with that.
Dominus wrote on 2021-05-13, 06:10:Why not use different versions for different uses?
Want to play with fluidsynth, start the ECE.
Need LFN support, start a version with that.
Because I would like to have fluidsynth and OGG/MP3 file playback as well as LFN support at the same time which DOSBox-X has.
The problem is that in trying to make that fork a jack of all trades they have also broken game compatibility adding in a thousand features for all DOS programs rather then just focusing on games.
Avenger wrote on 2021-05-13, 23:44:Dominus wrote on 2021-05-13, 06:10:Why not use different versions for different uses?
Want to play with fluidsynth, start the ECE.
Need LFN support, start a version with that.Because I would like to have fluidsynth and OGG/MP3 file playback as well as LFN support at the same time which DOSBox-X has.
The problem is that in trying to make that fork a jack of all trades they have also broken game compatibility adding in a thousand features for all DOS programs rather then just focusing on games.
It has already been confirmed that the so-called “incompatibility” is caused by a mismatch of the Sound Blaster IRQ (5 vs 7), as setting that correctly would immediately fix the issue for the mentioned game in DOSBox-X. While it is true that DOS gaming is indeed not the sole focus of DOSBox-X, this certainly does not mean that it has broken compatibility with DOS games in general. In many or most cases it may just be caused by minor setting issue(s) like SB IRQ mismatch.
Thanks for the clarification in this thread!
Wengier wrote on 2021-05-21, 12:11:Avenger wrote on 2021-05-13, 23:44:Dominus wrote on 2021-05-13, 06:10:Why not use different versions for different uses?
Want to play with fluidsynth, start the ECE.
Need LFN support, start a version with that.Because I would like to have fluidsynth and OGG/MP3 file playback as well as LFN support at the same time which DOSBox-X has.
The problem is that in trying to make that fork a jack of all trades they have also broken game compatibility adding in a thousand features for all DOS programs rather then just focusing on games.
It has already been confirmed that the so-called “incompatibility” is caused by a mismatch of the Sound Blaster IRQ (5 vs 7), as setting that correctly would immediately fix the issue for the mentioned game in DOSBox-X. While it is true that DOS gaming is indeed not the sole focus of DOSBox-X, this certainly does not mean that it has broken compatibility with DOS games in general. In many or most cases it may just be caused by minor setting issue(s) like SB IRQ mismatch.
This is a half truth. The problem lies in that DOSBox-X sets a default IRQ in the config file for unknown reasons so even if the game's music setup menu confirms that the card has been found and tests okay, once the game is booted on many occasions there is still no music. Then you have other settings in the config file that do the opposite of what they actually claim to which adds further confusion when combing through a list of over a hundred settings.
I get wanting to defend the fork you work on but if you're going to do so be honest about it. The guy who runs the github for the project even confirmed that the code severely needs a cleanup. As I've said before, there are many nice additional features but in adding most of the others that are entirely useless to games, you've also added more work to configure games to run properly as opposed to vanilla DOSBox which is not expected from anyone making the switch.
Avenger wrote on 2021-05-25, 12:20:Wengier wrote on 2021-05-21, 12:11:Avenger wrote on 2021-05-13, 23:44:Because I would like to have fluidsynth and OGG/MP3 file playback as well as LFN support at the same time which DOSBox-X has.
The problem is that in trying to make that fork a jack of all trades they have also broken game compatibility adding in a thousand features for all DOS programs rather then just focusing on games.
It has already been confirmed that the so-called “incompatibility” is caused by a mismatch of the Sound Blaster IRQ (5 vs 7), as setting that correctly would immediately fix the issue for the mentioned game in DOSBox-X. While it is true that DOS gaming is indeed not the sole focus of DOSBox-X, this certainly does not mean that it has broken compatibility with DOS games in general. In many or most cases it may just be caused by minor setting issue(s) like SB IRQ mismatch.
This is a half truth. The problem lies in that DOSBox-X sets a default IRQ in the config file for unknown reasons so even if the game's music setup menu confirms that the card has been found and tests okay, once the game is booted on many occasions there is still no music. Then you have other settings in the config file that do the opposite of what they actually claim to which adds further confusion when combing through a list of over a hundred settings.
I get wanting to defend the fork you work on but if you're going to do so be honest about it. The guy who runs the github for the project even confirmed that the code severely needs a cleanup. As I've said before, there are many nice additional features but in adding most of the others that are entirely useless to games, you've also added more work to configure games to run properly as opposed to vanilla DOSBox which is not expected from anyone making the switch.
It is generally agreed that if there is a IRQ mismatch then things may break at any time. They may work sometimes, but something is definitely wrong with such a setup and can misfunction at any time (including in real DOS). So why not set up the SB IRQ correctly in this case then? DOSBox-X uses IRQ 7 as the default IRQ even for SB16 only because it tried to follow the default IRQ of vanilla DOSBox for compatibility purposes with DOS games, otherwise it will definitely use IRQ 5 instead of IRQ 7 for SB16, as IRQ 5 is the real default IRQ on actual SB16 sound cards.
Well, perhaps I was indeed "defending" the fork, but I was defending it only because what YOU said was half-truth, and I have already been honest about it of course. Very simple, just set the correct IRQ in the game setup (or config file), and that's it. Why is it so hard to do this? The maintainer as you said did mention that the code did a cleanup, but he was primarily talking about something else (such as separation of PC-98 and non-PC98 related code to make the code even cleaner) and it has nothing to do with the SB IRQ stuff. The IRQ will continue to remain so solely for the purpose of DOSBox compatibility whether the code is cleaned up or not. Nothing will be changed regarding this.
Wengier wrote on 2021-05-26, 02:20:Avenger wrote on 2021-05-25, 12:20:Wengier wrote on 2021-05-21, 12:11:It has already been confirmed that the so-called “incompatibility” is caused by a mismatch of the Sound Blaster IRQ (5 vs 7), as setting that correctly would immediately fix the issue for the mentioned game in DOSBox-X. While it is true that DOS gaming is indeed not the sole focus of DOSBox-X, this certainly does not mean that it has broken compatibility with DOS games in general. In many or most cases it may just be caused by minor setting issue(s) like SB IRQ mismatch.
This is a half truth. The problem lies in that DOSBox-X sets a default IRQ in the config file for unknown reasons so even if the game's music setup menu confirms that the card has been found and tests okay, once the game is booted on many occasions there is still no music. Then you have other settings in the config file that do the opposite of what they actually claim to which adds further confusion when combing through a list of over a hundred settings.
I get wanting to defend the fork you work on but if you're going to do so be honest about it. The guy who runs the github for the project even confirmed that the code severely needs a cleanup. As I've said before, there are many nice additional features but in adding most of the others that are entirely useless to games, you've also added more work to configure games to run properly as opposed to vanilla DOSBox which is not expected from anyone making the switch.
It is generally agreed that if there is a IRQ mismatch then things may break at any time. They may work sometimes, but something is definitely wrong with such a setup and can misfunction at any time (including in real DOS). So why not set up the SB IRQ correctly in this case then? DOSBox-X uses IRQ 7 as the default IRQ even for SB16 only because it tried to follow the default IRQ of vanilla DOSBox for compatibility purposes with DOS games, otherwise it will definitely use IRQ 5 instead of IRQ 7 for SB16, as IRQ 5 is the real default IRQ on actual SB16 sound cards.
Well, perhaps I was indeed "defending" the fork, but I was defending it only because what YOU said was half-truth, and I have already been honest about it of course. Very simple, just set the correct IRQ in the game setup (or config file), and that's it. Why is it so hard to do this? The maintainer as you said did mention that the code did a cleanup, but he was primarily talking about something else (such as separation of PC-98 and non-PC98 related code to make the code even cleaner) and it has nothing to do with the SB IRQ stuff. The IRQ will continue to remain so solely for the purpose of DOSBox compatibility whether the code is cleaned up or not. Nothing will be changed regarding this.
Nothing I've said was outside my experience. I don't really concern myself with what other people "generally agree" to either. An additional setting may not be a big deal to you but in forcing an unnecessary default it's one more step and possible hurdle that needs to be overcome for the end result. I literally had to jump through hoops including installing a game again that was already previously installed a second time under vanilla DOSBox first because otherwise it would not boot with DOSBox-X. Then you have to set swap file locations in the config, then change IRQ settings in the config and for what reason exactly? None of this is required in vanilla DOSBox. As I said previously elsewhere, all that should be necessary is renaming the executable to "dosbox.exe" and swapping it with the vanilla verison in the same directory but that would be too simple and user freindly it seems. Instead fussing about combing through over a hundred settings hoping that the change actually does what's listed is the actual reality and this is if you can pin point what the problem is to begin with.
The additional features are "nice to haves" but if some one already has their games running perfect under vanilla DOSBox or another fork, the hassle of switching isn't worth it. Again, my experience but if you're familiar with the underworkings of DOSBox-X such as you are I can see why you'd have a different opinion.
Well, it may be possible to add a special "compatibility mode" to force the same setting/handling of vanilla DOSBox as maximum as possible for easier transitions specifically for users like you, but this will require some work and time of course...
