Proposals for changes in Exult Audio

Dragon-Baroque commented 3 years ago

I have a few changes to offer, mostly in the Audio support for Exult.

Fixes to the Timidity MIDI driver : Enhancement to the expected location and the parsing of the Configuration file ( all platforms ), Fix to the detection of Little Endian vs Big Endian ( Linux ),
Enhancement to the ALSA MIDI driver : If the default - alsa_port or 65:0 - fails to connect, try to detect a valid MIDI output port. Explanation : the port 65:0 come for MIDI synthesizer sound cards. Now, MIDI is provided by software synthesis, essentially by the three synthesizers natively supported by Exult : MT32Emu, Timidity, and FluidSynth. All three can register as ALSA servers at ports 128:0 and up, by time order of registration. My proposal, to avoid requesting the user to code an alsa_port in the configuration exult.cfg, is to ask ALSA to name the ALSA clients with available output MIDI and connect to the first that accepts.

I have a few questions :

Would you like to discuss / review the code of the above proposal ?
Is it acceptable to set the alsa_port in the exult.cfg to the detected MIDI server when the default port address failed - whether coming from exult.cfg or being 65:0, or is the setting of the alsa_port reserved to the human user ?
Similarly for the FluidSynth MIDI : A recent accepted patch uses the default FluidSynth SoundFont when none is declared in the fluidsynth_soundfont tag of the exult.cfg. It it acceptable to record it also in the fluidsynth_soundfont tag of the exult.cfg ?

I have also a pending change to the exult.cfg writer, which keeps each value tag in one like, reserving the indentation for nested tags : you now get :

 ...
 <audio>
  <disablepause>no</disablepause>
  <enabled>yes</enabled>
  <midi>
   <enabled>yes</enabled>
   <convert>gm</convert>
   <use_oggs>no</use_oggs>
   ...

All the changes are ready for review. Please tell me about an acceptable delivery format, I mean, one commit per item, or one commit for all of them...

Dragon-Baroque, March 1st, 2021

DominusExult commented 3 years ago

About exult.cfg I'm tentatively against autofilling alsa_port and fluidsynth soundfont location. I think we don't add these tags by default on linux (or other OS), right?

So the autodetection is a great idea, but once these tags are in the cfg, their value shouldn't be overwritten IMO.

sigh I stillstrongly dislike the xml style of the cfg anyway ;)

DominusExult commented 3 years ago

It would make sense if we were to poll the ports and print which "devices" Exult finds at the ports. Same as being done for Windows Midi ports and Coremidi on macOS. And THEN autoselect the first available one if 65:0 (or the alsa_port setting) is not available.

marzojr commented 3 years ago

I am actually tempted to maybe add it as a GUI option for it in Audio gump, with something similar for Windows midi drivers. And maybe something similar for OSX, but @DominusExult will have to let me know if this is needed. And with this GUI option being added, maybe it would be better to save the name of the chosen device (if it has one) instead of an ID/port -- so if the device ID/port changes, it can still be enabled (if it exists) by name.

The reasons:

you can install mt32emu MIDI driver in Linux as an ALSA device, or in Windows as a Windows MIDI device (and likely in OSX as a CoreMidi device or similar, but @DominusExult will have to correct me on that);
We currently require the user to supply both an ALSA device or a Windows MIDI device if you don't want the default; and the default is likely not going to be mt32emu driver;
Selecting by name when possible would allow adding/removing MIDI devices without having to fix the configuration option in Exult, as long as the device still exists.

The sequence for opening a MIDI device might be something like:

query all MIDI device names and IDs/ports;
search for device specified by new option, if it exists;
if not found, try getting the device with ID/port specified by the old option, if it exists;
if still not found, fetch the first entry in the list.

Dragon-Baroque commented 3 years ago

sigh I still strongly dislike the xml style of the cfg anyway ;)

Switch to YAML ? And please, not JSON ...

DominusExult commented 3 years ago

sigh I still strongly dislike the xml style of the cfg anyway ;)

Switch to YAML ? And please, not JSON ...

Actually I'm pretty much a fan of the ini format. When people from exult started Pentagram, we went with that for ease of use.

OTOH, the strong reason not to switch was always that we should have as much as possible accessible via the GUI so people do not have to edit the cfg as much.

I am actually tempted to maybe add it as a GUI option for it in Audio gump, with something similar for Windows midi drivers. And maybe something similar for OSX, but @DominusExult will have to let me know if this is needed. And with this GUI option being added, maybe it would be better to save the name of the chosen device (if it has one) instead of an ID/port -- so if the device ID/port changes, it can still be enabled (if it exists) by name.

Having this in the GUI for macOS and Linux would be great. DOSBox is already polling the CoreMidi devices' name so you can use either port number or name (quick view in the svn2git repo at https://github.com/svn2github/dosbox/commit/3fd4c512eaf6c372d4a189e03cd2509d17b4f579).

I'm not sure when macOS changed this but at some point the MIDI network port was always turned on and at port 0, so the first port found is always that one, so you will always need to set a different one if you want to use a physical device or a virtual one like Munt. <- another reason a GUI option would be great.

Looking at the logging, Exult could also need to print out which port it uses if the one in the cfg is not available (in the screenshot below I had entered the device name and I guess Exult used 0 but you never know :)) Correction: Exult does write a message that a port is not available and that it tries port 0, if the value is a number. But it will not write that if you enter a name (which it can't use). coremidi

marzojr commented 3 years ago

Regardless of cfg file format, @Dragon-Baroque any code you already have would be welcome.

DominusExult commented 3 years ago

Regardless of cfg file format, @Dragon-Baroque any code you already have would be welcome.

Yes, please disregard the cfg file format, I shouldn't have brought it up, it's just a distraction.

Dragon-Baroque commented 3 years ago

I too agree that having an explicit list of available MIDI ports for the user to choose from would be nice. I have two questions for you :

How to present it in the Audio Gump ? Is there some way to display a Combo or a ListBox ?
How to obtain the list from Alsa ( or CoreMidi or Windows ) ? As of now the chosen MIDI driver is invoked on its open service when the user clicks on OK and the Audio Gump closes. Should we add an listAvailable service in the MIDI drivers to populate the MIDI list ?

Also I have posted an updated MIDI detector code that works on a MIDI sound card I bought. Then the code not only detects correctly the Software MIDI Synthesizers but also the Hardware MIDI Synthesizer of the sound card. I have now this in the console :

Trying config specified Midi driver: `alsa'
ALSAMidiDriver: Can't subscribe to default MIDI port [65:0], looking for other MIDI ports
ALSAMidiDriver: ALSA client initialised on MIDI port [17:0] [ Emu10k1 WaveTable : Emu10k1 Port 0 ]
Success!
Midi Output: Enabled

Where 17:0 is the ClientID:PortID, and Emu10k1 WaveTable is the ClientName and Emu10k1 Port 0 the PortName.

Dragon-Baroque commented 3 years ago

Published in Dragon-Baroque/exult, Branch exult_audio.

DominusExult commented 2 years ago

As I messed with CoreAudio and SoundFonts, it would be really great if Exult were to parse the DATA folder for sf2 (and in the case of CoreAudio, additionally for dls) files and toggle them through a button. And if there is anything written in the <..._soundfont> tag first try if that is in the DATA folder and if not try whether it is a full path.

as for the questions above:

so far we could use just a button that enumerates the available ports/names and toggle through them (as we do with the MIDI drivers.
We do already list in stdout available ports/port names for Windows (WindowsMidiDriver.cpp:74) and CoreMidi (CoreMidiDriver.cpp:57). Can't see anything in the ALSA code.

Dragon-Baroque commented 2 years ago

... parse the DATA folder for sf2 ...

Can you alter the choice of SoundFonts in CoreMidi ? In Linux, you cannot in Alsa, only directly in FluidSynth.

And you should respect the default folders of FluidSynth, /usr/share/soundfonts.

We do already list in stdout available ports/port names for Windows (WindowsMidiDriver.cpp:74) and CoreMidi (CoreMidiDriver.cpp:57). Can't see anything in the ALSA code.

True. I can add this to the code in Dragon-Baroque/exult branch exult_audio.

So far we could use just a button that enumerates the available ports/names and toggle through them (as we do with the MIDI drivers.

Yes, but for Alsa, the proper enumeration should be clientNumber:portNumber and clientName:portName, which would quickly overflow the gump width, unless we can restrict to the portName. Here is a list from aplaymidi -l on my Linux, with my SB Audigy, with FluidSynth and TiMidity++ :

 Port    Client name                      Port name
 14:0    Midi Through                     Midi Through Port-0
 24:0    SB Audigy 5/Rx [SB1550]          Audigy MPU-401 (UART)
 24:32   SB Audigy 5/Rx [SB1550]          Audigy MPU-401 #2
 25:0    Emu10k1 WaveTable                Emu10k1 Port 0
 25:1    Emu10k1 WaveTable                Emu10k1 Port 1
 25:2    Emu10k1 WaveTable                Emu10k1 Port 2
 25:3    Emu10k1 WaveTable                Emu10k1 Port 3
128:0    FLUID Synth (178130)             Synth input port (178130:0)
129:0    TiMidity                         TiMidity port 0
129:1    TiMidity                         TiMidity port 1
129:2    TiMidity                         TiMidity port 2
129:3    TiMidity                         TiMidity port 3

DominusExult commented 2 years ago

I honestly have no idea about ALSA and only about FluidSynth. Fluidsynth is also special in Exult as you can have multiple soundfonts that "stack". For ALSA enumaration you would probably need to see what makes the most sense to display.

There is a difference between CoreAudio and CoreMidi. CoreMidi is only for connecting to an "external" MIDI device which are connected to a port. Can be both a real device like a Roland MT-32 or a virtual one like the Munt MT32emu. It doesn't make use of a soundfont. CoreAudio is for using the builtin MIDI stuff using a soundfont (which you can change in exult.cfg).

Dragon-Baroque commented 2 years ago

I have a prototype change of the my exult_audio branch that lists the MIDI devices prior to the connection with Alsa :

Trying config specified Midi driver: `Alsa'
Listing midi devices:
14:0 : [ Midi Through : Midi Through Port-0 ], available, 0 channels
24:0 : [ SB Audigy 5/Rx [SB1550] : Audigy MPU-401 (UART) ], available, 16 channels
24:32 : [ SB Audigy 5/Rx [SB1550] : Audigy MPU-401 #2 ], available, 16 channels
25:0 : [ Emu10k1 WaveTable : Emu10k1 Port 0 ], in use, 16 channels
25:1 : [ Emu10k1 WaveTable : Emu10k1 Port 1 ], available, 16 channels
25:2 : [ Emu10k1 WaveTable : Emu10k1 Port 2 ], available, 16 channels
25:3 : [ Emu10k1 WaveTable : Emu10k1 Port 3 ], available, 16 channels
128:0 : [ FLUID Synth (491221) : Synth input port (491221:0) ], in use, 16 channels
129:0 : [ TiMidity : TiMidity port 0 ], available, 16 channels
129:1 : [ TiMidity : TiMidity port 1 ], available, 16 channels
129:2 : [ TiMidity : TiMidity port 2 ], available, 16 channels
129:3 : [ TiMidity : TiMidity port 3 ], available, 16 channels
ALSAMidiDriver: Can't subscribe to default MIDI port [65:0], looking for other MIDI ports
ALSAMidiDriver: ALSA client initialised on MIDI port [25:1] [ Emu10k1 WaveTable : Emu10k1 Port 1 ]
Success!
Midi Output: Enabled

In Alsa the notation is clientNo:portNo, with [ clientName : portName ]. The only portName that should be cleaned up for the Audio Options gump comes from FluidSynth.

DominusExult commented 2 years ago

That's a very verbose but useful output :) And yes, Synth input port (491221:0), is long and doesn't even mention Fluidsynth.

exult / exult

Proposals for changes in Exult Audio #88