Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dosbox + fluidsynth #2051

Closed
fogobogo opened this issue Jul 20, 2017 · 5 comments
Closed

dosbox + fluidsynth #2051

fogobogo opened this issue Jul 20, 2017 · 5 comments

Comments

@fogobogo
Copy link

fogobogo commented Jul 20, 2017

This is mainly for documentation purposes since Retropie currently doesn't maintain a dosbox fork.

This patch for dosbox is derived from an earlier one here: https://sourceforge.net/p/dosbox/patches/107/

Rationale:

The Raspberry Pi has somewhat sorry audio capabilities. Theres no support for dmix, there is no line in or mic and it all goes off via pulse wave modulation on top.
Playing multiple sound sources at once via alsa is almost impossible without a software mixer or more dedicated hardware.
Typically pulseaudio is used to provide software mixing but it introduces a fair amount of lag ( >100ms from the feel of it. ) and is quite resource intense.

What this patch does is adding fluidsynth as a dependency to dosbox and uses dosbox's internal mixing to provide midi output. It does so by adding it's own channel to the dosbox mixer.

This eliminates the need to have pulseaudio (as a software mixing daemon) and fluidsynth (as a midi software synthesizer daemon) both running and greatly reduces overhead.

Basically it allows midi + soundblaster output at the same time with just alsa

The patch is quite dirty and could need some work but is functional with a bit of fuzzing. I tested it on the current svn version (r4025 as of time of writing).

dosbox.conf must be changed to make use of it:

[midi]

mpu401=intelligent
mididevice=synth
midiconfig=/path/to/soundfont/example.sf2

NOTE:
There is also a samplerate setting but it seems to have little to no effect. The default seems to be using whatever dosbox is set to. Usemidisamplerate=44100 for example.

It also seems a bit picky about the kind of soundfont it accepts. Someone probably should try different ones.

dosbox-fsynth.txt

@fogobogo
Copy link
Author

Addenum:
There is another more recent fluidsynth patch (http://www.vogons.org/viewtopic.php?f=32&t=27831&start=20) for dosbox but this one doesn't integrate with dosbox's mixer.
In consequence you don't have to run the fluidsynth daemon anymore but still need pulseaudio for the mixing with poor results.

@psyke83
Copy link
Member

psyke83 commented Nov 15, 2017

I can confirm that dmix is not functioning properly on the Pi with the latest kernel, but you shouldn't need it - the sound driver is capable of performing hardware mixing on up to 8 substreams. I'm not too familiar with dosbox but I'll take a look at it and see if this can be rectified without the fluidsynth patch; maybe one or both have a flaw in which it tries to output only on one substream.

@psyke83
Copy link
Member

psyke83 commented Nov 16, 2017

Can you try updating your Retropie-Setup script and then update DOSbox? The scriptmodule will set configuration to use the TiMidity/FluidSynth ALSA MIDI port on Pi (and other targets when timidity-daemon is installed), and the DOSbox launch script now spawns a timidity instance on the Pi.

To test, I downloaded the DOOM shareware release, and set the default configuration with (IIRC) "General MIDI" support. DOOM now plays the MIDI soundtrack and sound effects together (and timidity uses ~15% CPU when MIDI playback is active). PulseAudio or ALSA dmix is not required for this solution - as I said, the Pi's sound driver does hardware mixing.

I opted for TiMidity, as FluidSynth seems to have distorted instruments with the default configuration. You can change the sound fonts via /etc/timidity/timidity.conf by switching to the "/etc/timidity/fluidr3_gm.cfg" config (which needs the fluid-soundfont-gm package). If the launch script detects an ALSA MIDI client named "FluidSynth" or "TiMidity", the launch script won't spawn its own TiMidity instance, so you can use your own FluidSynth daemon if you want.

This may not be as good as the FluidSynth patch, but I would urge that you submit such changes upstream.

@fogobogo
Copy link
Author

Sorry for the late reply.

I have in fact not tested it (yet) to be honest as I'm using archlinux on the rpi3. Just wanted to note that the patch was in fact already submitted upstream and turned down as can be seen here link hence I put it here for any interested party.

I admit fluidsynth seems to have some issues with certain soundfonts otherwise a far lighter library than timidity though.
It also seems that the mixing problem has been mostly rectified as I can actually play 2 sound sources at the same time (again?).

However if anyone in the future still cares heres a slightly cleaned up version of that patch which changes the configuration naming a bit though.

mpu401=intelligent
mididevice=fsynth
midiconfig=/path/to/soundfont/soundfont.sf2

synthsamplerate=44100

dosbox-SVN-fsynth-patch.txt

Thanks a lot anyway and good work.

@psyke83
Copy link
Member

psyke83 commented Dec 23, 2017

If you don't mind, I'll close this issue to keep the issue tracker tidy, since the issue is more or less resolved. It's not likely that we're going to start maintaining our own fork of dosbox, and we already have the timidity workaround in place (not ideal, I know, but better than nothing). Thanks.

@psyke83 psyke83 closed this as completed Dec 23, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants