MIDI sound using software synths?

[Newsdee]

How to use softsynths with the latest ao486 core?
I've run the soundfont install script, but I don't seem to be getting any MIDI sound.

Do I need to have SOFTMPU loaded with certain options?
Or I shouldn't use that for softsynths? (i.e. is it only to output MIDI via serial?)

[bbond007]

Try and change:
/media/fat/linux/MidiLink.INI

Code: Select all

[AO486]
MIDI_BAUD = 31250
UDP_BAUD = 38400

Try without SoftMPU first...

[Newsdee]

I notice this setting, do I need to match the IP of my MiSTer? (it doesn't match it)

Code: Select all

UDP_SERVER          = 192.168.1.130

[bbond007]

I notice this setting, do I need to match the IP of my MiSTer? (it doesn't match it)

Code: Select all

UDP_SERVER          = 192.168.1.130

No, that would only be used if you want to send the raw MIDI data to another device (such as MUNT on PC) or can also be use to connect 2 MiSTers (like a null modem cable) for network games.

[Lukage]

I do have a slight problem with MT-32. I do get this message from console:

Code: Select all

SysexHandler: parseSysexFragment: SysEx message lacks end-of-sysex (0xf7), ignored

As a result, MT-32 does not get properly programmed. It plays, but without successful sysex initialization it is not how it should sound.

Tried some three or four different approaches with or without SoftMPU, and still getting this. I cannot find error in setup or anywhere in ao486 verilog code.

[bry111]

Not sure if this is the right thread for this. I've been trying to use FluidSynth with the recent incredible improvements to the core and it's not working out so well. Maybe I'm missing something, or maybe I'm running into limits?

My configuration:

• in MidiLink.INI
  • MIDI_BAUD set to 31250 and UDP_BAUD set to 38400 as per above post
  • FSYNTH_SOUNDFONT set to a soundfont
• UART mode
  • connection: MIDI
  • MidiLink: Local
  • Type: FluidSynth
• In DOS AUTOEXEC.BAT

  Code: Select all

  SET BLASTER=A220 I5 D1 T3 P330
  

With the P330 in the BLASTER environment variable, dosmid ends up using FluidSynth by default (no flags required) and it seems to work fine for simple midi files. But it has trouble playing flourish.mid; about 35 seconds in the tempo gets messed up, sometimes there's static. It's kind of funny actually, it's like if a band was playing and someone kicked the drummer but he tries to keep going anyway... Seems to get better about 55 seconds in. Flourish.mid was used in a DirectX test many years after the days of DOS, maybe complicated midi files are too much? Setting UART speed to 30x does not help.

Duke Nukem 3D behaves similarly to dosmid on a complicated file, music plays fine for a bit but then has trouble, eventually seemingly playing random instruments at random times. Configuring to play music via Sound Blaster seems to work fine via OPL2/3.

A somewhat more serious issue, if I try to configure Sim City 2000 to play music via MPU-401, music plays for a few seconds on startup and then cuts out completely. In order to play any further midi via FluidSynth I need to completely reboot the MiSTer, resetting the core isn't enough to get it back. Again, if I instead configure SC2000 to play music via Sound Blaster so it doesn't use FluidSynth it seems to work fine.

I haven't tried Munt, SoftMPU, or midi-over-TCP/UDP yet.

[bbond007]

I do have a slight problem with MT-32. I do get this message from console:

Code: Select all

SysexHandler: parseSysexFragment: SysEx message lacks end-of-sysex (0xf7), ignored

As a result, MT-32 does not get properly programmed. It plays, but without successful sysex initialization it is not how it should sound.

Tried some three or four different approaches with or without SoftMPU, and still getting this. I cannot find error in setup or anywhere in ao486 verilog code.

In what game?

I notice with Codename Iceman I get correct sounds with SoftMPU but with the MPU-401 It sounds wrong like its missing at least some of the sysex initialization like you describe.

[Newsdee]

Is SoftMPU only for using external MIDI devices?

Without it, do we need to use a specific port for General MIDI (330?)

[NightShadowPT]

Is SoftMPU only for using external MIDI devices?

Without it, do we need to use a specific port for General MIDI (330?)

No, you'll need it as well for any MIDI device (as long as the game requires it). The type of MIDI device does not establish the need to use SoftMPU, the game does.

I never used any other port besides 330 for MIDI.

[Newsdee]

I tried configuring Apogee's Xenophage since the setup menu plays sound FX and MIDI. It recognizes the presence of a General MIDI device, but there is no music. Both music and FX work with SoundBlaster, though.

I'm probably missing a step somewhere. I notice I have no option to set UART to "connection type: MIDI" in the core (there is only an option about UART speed). I also notice the INI file has:

Code: Select all

FSYNTH_VOLUME       = -1

Do I need to change it?

[bbond007]

I'm probably missing a step somewhere. I notice I have no option to set UART to "connection type: MIDI" in the core (there is only an option about UART speed).

it should be in the "System" menu. Press right...
If its not then maybe you need to update MiSTer.exe

I also notice the INI file has:

Code: Select all

FSYNTH_VOLUME       = -1

Do I need to change it?

Changing it will have no effect, so you should leave it as is.

[Lukage]

I do have a slight problem with MT-32. I do get this message from console:

Code: Select all

SysexHandler: parseSysexFragment: SysEx message lacks end-of-sysex (0xf7), ignored

As a result, MT-32 does not get properly programmed. It plays, but without successful sysex initialization it is not how it should sound.

Tried some three or four different approaches with or without SoftMPU, and still getting this. I cannot find error in setup or anywhere in ao486 verilog code.

In what game?

I notice with Codename Iceman I get correct sounds with SoftMPU but with the MPU-401 It sounds wrong like its missing at least some of the sysex initialization like you describe.

This is in Dune 2. There seems to be a MIDI buffer overflow.

Code: Select all

[-158153533] SEQU OUT [64] --> f0 41 10 16 12 05 00 00 02 00 18 32 0c 00 01 00 02 15 18 32 0c 00 01 00 02 01 18 32 0c 00 01 00 02 02 18 32 0c 00 01 00 02 11 18 32 0c 00 01 00 02 0b 18 32 0c 00 01 00 02 0f 18 32 0c 00 01 00
[-158153512] SEQU OUT [64] --> 02 05 18 32 0c 00 01 00 02 12 18 32 0c 00 01 00 02 16 18 32 0c 00 01 00 02 14 18 32 0c 00 01 00 02 08 18 32 0c 00 01 00 02 04 18 32 0c 00 01 00 02 03 18 32 0c 00 01 00 02 06 18 32 0c 00 01 00
[-158153492] SEQU OUT [64] --> 02 07 18 32 0c 00 01 00 02 09 18 32 0c 00 01 00 02 13 18 32 0c 00 01 00 02 1b 18 32 0c 00 01 00 02 1a 18 32 0c 00 01 00 02 19 18 32 0c 00 01 00 02 17 18 32 0c 00 01 00 00 16 18 32 0c 00 01 00
[-158153471] SEQU OUT [64] --> 02 18 18 32 0c 00 01 00 00 18 18 32 0c 00 01 00 02 10 18 32 0c 00 01 00 02 0e 18 32 0c 00 01 00 02 0a 18 32 0c 00 01 00 02 0d 18 32 0c 00 01 00 02 0c 18 32 0c 00 01 00 00 1e 18 32 0c 00 01 00
SysexHandler: parseSysexFragment: SysEx message lacks end-of-sysex (0xf7), ignored
[-158153467] SEQU OUT [10] --> 00 1f 18 32 0c 00 01 00 7e f7
[-158153366] SEQU OUT [64] --> f0 41 10 16 12 05 02 00 00 20 18 32 0c 00 01 00 00 21 18 32 0c 00 01 00 02 28 18 32 0c 00 01 00 02 2d 18 32 0c 00 01 00 02 2c 18 32 0c 00 01 00 00 25 18 32 0c 00 01 00 02 1c 18 32 0c 00 01 00
[-158153346] SEQU OUT [64] --> 00 27 18 32 0c 00 01 00 00 28 18 32 0c 00 01 00 00 29 18 32 0c 00 01 00 00 2a 18 32 0c 00 01 00 00 2b 18 32 0c 00 01 00 02 2a 18 32 0c 00 01 00 02 25 18 32 0c 00 01 00 00 2e 18 32 0c 00 01 00
[-158153325] SEQU OUT [64] --> 02 2e 18 32 0c 00 01 00 02 29 18 32 0c 00 01 00 02 20 18 32 0c 00 01 00 00 32 18 32 0c 00 01 00 00 33 18 32 0c 00 01 00 00 34 18 32 0c 00 01 00 00 35 18 32 0c 00 01 00 00 36 18 32 0c 00 01 00
[-158153305] SEQU OUT [64] --> 00 37 18 32 0c 00 01 00 00 38 18 32 0c 00 01 00 00 39 18 32 0c 00 01 00 00 3a 18 32 0c 00 01 00 00 3b 18 32 0c 00 01 00 00 3c 18 32 0c 00 01 00 02 27 18 32 0c 00 01 00 02 26 18 32 0c 00 01 00
SysexHandler: parseSysexFragment: SysEx message lacks end-of-sysex (0xf7), ignored
[-158153300] SEQU OUT [10] --> 00 3f 18 32 0c 00 01 00 56 f7
[-158153191] SEQU OUT [64] --> f0 41 10 16 12 05 04 00 01 00 18 32 0c 00 01 00 01 01 18 32 0c 00 01 00 02 23 18 32 0c 00 01 00 02 31 18 32 0c 00 01 00 02 30 18 32 0c 00 01 00 01 05 18 32 0c 00 01 00 01 06 18 32 0c 00 01 00
[-158153171] SEQU OUT [64] --> 01 07 18 32 0c 00 01 00 01 08 18 32 0c 00 01 00 01 09 18 32 0c 00 01 00 01 0a 18 32 0c 00 01 00 01 0b 18 32 0c 00 01 00 01 0c 18 32 0c 00 01 00 01 0d 18 32 0c 00 01 00 01 0e 18 32 0c 00 01 00
[-158153150] SEQU OUT [64] --> 01 0f 18 32 0c 00 01 00 01 10 18 32 0c 00 01 00 01 11 18 32 0c 00 01 00 01 12 18 32 0c 00 01 00 01 13 18 32 0c 00 01 00 01 14 18 32 0c 00 01 00 01 15 18 32 0c 00 01 00 01 16 18 32 0c 00 01 00
[-158153128] SEQU OUT [64] --> 01 17 18 32 0c 00 01 00 01 18 18 32 0c 00 01 00 01 19 18 32 0c 00 01 00 02 1f 18 32 0c 00 01 00 01 1b 18 32 0c 00 01 00 01 1c 18 32 0c 00 01 00 01 1d 18 32 0c 00 01 00 01 1e 18 32 0c 00 01 00
SysexHandler: parseSysexFragment: SysEx message lacks end-of-sysex (0xf7), ignored
[-158153125] SEQU OUT [10] --> 01 1f 18 32 0c 00 01 00 03 f7

As you can see, if MIDI message gets past 256 bytes, it just forwards this message, and gets SysEx parse error. The end of SysEx command is past these 256 bytes. As I am not a MIDI expert, I do not know what the maximum SysEx message size should be according to specification, or if it is some ALSA-sepcific issue. Under DosBox, both mt32emu-qt and mt32d works flawlessly.

EDIT: ALSA indeed fragments MIDI messages into 256 byte chunks. But MUNT does have SysEx message reassembly to get past these 256 bytes. I do not know with what settings mt32d was compiled. In globals.h I could find:

Code: Select all

/* This should correspond to the MIDI buffer size used in real h/w devices.
 * CM-32L control ROM is using 1000 bytes, and MT-32 GEN0 is using only 240 bytes (semi-confirmed by now).
 */
#define MT32EMU_SYSEX_BUFFER_SIZE 1000

So there should be a 1000 byte buffer for SysEx message according to CM-32L ROM disassembly, but the current setting in mt32d for me is unknown.

EDIT2:

Code: Select all

This works:
[02441517] SEQU OUT [255] --> f0 41 10 16 12 ..............
This does not:
[02293715] SEQU OUT [256] --> f0 41 10 16 12 ..............
SysexHandler: parseSysexFragment: SysEx message lacks end-of-sysex (0xf7), ignored

[Newsdee]

it should be in the "System" menu. Press right...

Yes! That was the missing step... I had missed there was a change in that menu.

[Lukage]

I think I found the problem with MT-32 emulation. Data which are coming from MPU-401 interface are sent directly into ALSA:

Code: Select all

                int rdLen = read(fdSerial, buf, sizeof(buf));
                if (rdLen > 0)
                {
                    write_alsa_packet(buf, rdLen);
                }

ALSA recognizes SysEx message, and notifies MUNT via event:

Code: Select all

            case SND_SEQ_EVENT_SYSEX:
                debug_msg("SysEx (fragment) of size %d\n", seq_ev->data.ext.len);

                ev->type = EVENT_SYSEX;
                ev->sysex_len = seq_ev->data.ext.len;
                ev->sysex = malloc(seq_ev->data.ext.len);
                memcpy(ev->sysex, seq_ev->data.ext.ptr, ev->sysex_len);

                return;

This in turn produces event for MUNT SysEx message processor, parseStream.

Code: Select all

                    case EVENT_SYSEX:
                        /* record it if needed */
                        if (consumer_types & CONSUME_SYSEX)
                        {
                                fwrite((unsigned char *)newev.sysex, 1, newev.sysex_len, recsyx_file);
                                fflush(recsyx_file);
                        }
                        sysexHandler->parseStream((MT32Emu::Bit8u *) newev.sysex, newev.sysex_len);
                        free(newev.sysex);
                        break;

The problem is, somewhere between MidiLink and parseStream, a segment is lost.

Code: Select all

[-118448687] SEQU OUT [64] --> f0 41 10 16 12 03 01 10 5e 64 07 01 5e 64 07 01 5e 64 07 01 5e 64 07 01 5e 64 07 01 5e 64 07 01 5e 64 07 01 5e 64 07 01 5e 64 07 01 5e 64 07 01 5e 64 07 01 40 64 07 01 40 64 07 01 4a 64 06 01
[-118448666] SEQU OUT [64] --> 41 64 07 01 4b 64 08 01 45 64 06 01 44 64 0b 01 46 64 06 01 44 64 0b 01 5d 64 06 01 43 64 08 01 47 64 06 01 43 64 08 01 42 64 03 01 48 64 06 01 42 64 03 01 49 64 08 01 5e 64 07 01 5e 64 07 01
[-118448646] SEQU OUT [64] --> 56 64 09 01 5e 64 07 01 4c 64 07 01 5e 64 07 01 5e 64 07 01 5e 64 07 01 52 64 02 01 53 64 04 01 4d 64 08 01 4e 64 09 01 4f 64 0a 01 50 64 07 01 51 64 05 01 54 64 02 01 55 64 02 01 5b 64 09 01
[-118448625] SEQU OUT [64] --> 58 64 04 01 5a 64 09 01 59 64 09 01 5c 64 0a 01 5e 64 07 01 57 64 0c 01 5e 64 07 01 5e 64 07 01 5e 64 07 01 5e 64 07 01 5e 64 07 01 5e 64 07 01 5e 64 07 01 5e 64 07 01 5e 64 07 01 5e 64 07 01
SysEx (fragment) of size 256
Send data to MUNT parseStream
Data to parse: F0 41 10 16 12 03 01 10 5E 64 07 01 5E 64 07 01 5E 64 07 01 5E 64 07 01 5E 64 07 01 5E 64 07 01 5E 64 07 01 5E 64 07 01 5E 64 07 01 5E 64 07 01 5E 64 07 01 40 64 07 01 40 64 07 01 4A 64 06 01 41 64 07 01 4B 64 08 01 45 64 06 01 44 64 0B 01 46 64 06 01 44 64 0B 01 5D 64 06 01 43 64 08 01 47 64 06 01 43 64 08 01 42 64 03 01 48 64 06 01 42 64 03 01 49 64 08 01 5E 64 07 01 5E 64 07 01 56 64 09 01 5E 64 07 01 4C 64 07 01 5E 64 07 01 5E 64 07 01 5E 64 07 01 52 64 02 01 53 64 04 01 4D 64 08 01 4E 64 09 01 4F 64 0A 01 50 64 07 01 51 64 05 01 54 64 02 01 55 64 02 01 5B 64 09 01 58 64 04 01 5A 64 09 01 59 64 09 01 5C 64 0A 01 5E 64 07 01 57 64 0C 01 5E 64 07 01 5E 64 07 01 5E 64 07 01 5E 64 07 01 5E 64 07 01 5E 64 07 01 5E 64 07 01 5E 64 07 01 5E 64 07 01 5E 64 07 01 
SysexHandler: parseSysex: Copying incomplete SysEx size 256 into buffer...
SysexHandler: End of parseStream
[-118448621] SEQU OUT [10] --> 5e 64 07 01 5e 64 07 01 2f f7
[-118448520] SEQU OUT [64] --> f0 41 10 16 12 05 00 00 02 00 18 32 0c 00 01 00 02 15 18 32 0c 00 01 00 02 01 18 32 0c 00 01 00 02 02 18 32 0c 00 01 00 02 11 18 32 0c 00 01 00 02 0b 18 32 0c 00 01 00 02 0f 18 32 0c 00 01 00
[-118448500] SEQU OUT [64] --> 02 05 18 32 0c 00 01 00 02 12 18 32 0c 00 01 00 02 16 18 32 0c 00 01 00 02 14 18 32 0c 00 01 00 02 08 18 32 0c 00 01 00 02 04 18 32 0c 00 01 00 02 03 18 32 0c 00 01 00 02 06 18 32 0c 00 01 00
[-118448479] SEQU OUT [64] --> 02 07 18 32 0c 00 01 00 02 09 18 32 0c 00 01 00 02 13 18 32 0c 00 01 00 02 1b 18 32 0c 00 01 00 02 1a 18 32 0c 00 01 00 02 19 18 32 0c 00 01 00 02 17 18 32 0c 00 01 00 00 16 18 32 0c 00 01 00
[-118448459] SEQU OUT [64] --> 02 18 18 32 0c 00 01 00 00 18 18 32 0c 00 01 00 02 10 18 32 0c 00 01 00 02 0e 18 32 0c 00 01 00 02 0a 18 32 0c 00 01 00 02 0d 18 32 0c 00 01 00 02 0c 18 32 0c 00 01 00 00 1e 18 32 0c 00 01 00
SysEx (fragment) of size 256
Send data to MUNT parseStream
Data to parse: F0 41 10 16 12 05 00 00 02 00 18 32 0C 00 01 00 02 15 18 32 0C 00 01 00 02 01 18 32 0C 00 01 00 02 02 18 32 0C 00 01 00 02 11 18 32 0C 00 01 00 02 0B 18 32 0C 00 01 00 02 0F 18 32 0C 00 01 00 02 05 18 32 0C 00 01 00 02 12 18 32 0C 00 01 00 02 16 18 32 0C 00 01 00 02 14 18 32 0C 00 01 00 02 08 18 32 0C 00 01 00 02 04 18 32 0C 00 01 00 02 03 18 32 0C 00 01 00 02 06 18 32 0C 00 01 00 02 07 18 32 0C 00 01 00 02 09 18 32 0C 00 01 00 02 13 18 32 0C 00 01 00 02 1B 18 32 0C 00 01 00 02 1A 18 32 0C 00 01 00 02 19 18 32 0C 00 01 00 02 17 18 32 0C 00 01 00 00 16 18 32 0C 00 01 00 02 18 18 32 0C 00 01 00 00 18 18 32 0C 00 01 00 02 10 18 32 0C 00 01 00 02 0E 18 32 0C 00 01 00 02 0A 18 32 0C 00 01 00 02 0D 18 32 0C 00 01 00 02 0C 18 32 0C 00 01 00 00 1E 18 32 0C 00 01 00
SysexHandler: parseSysexFragment: Nextbyte: F0 at 1
SysexHandler: parseSysexFragment: No end. SysEx message was 256 bytes long, last byte was 0xF0

As you can see, there are 256 bytes sent into parseStream, and MUNT gets them correctly. Then, there is a 10 byte final sequence for that 256 bytes, in form of 5e 64 07 01 5e 64 07 01 2f f7. This part never reaches parseStream, and MUNT continues the SysEx message with start of second SysEx message, bytes f0 41 10 16 12 05 00 00 02 00 18 32 0c....... Because it sees F0, which is start byte of next SysEx message, it fails, and ignores that whole SysEx message in buffer.

I don't know yet, where is exact root cause, but this is problem which affects any game, which produces larger SysEx messages. If the music sounds "incorrect", MT-32 emulation failed to get proper SysEx programming due to this error.

It may be, that ALSA does not correctly recognize that SysEx continues from MidiLink stream, and fails to produce correct event (SND_SEQ_EVENT_SYSEX), and sends those bytes as some other data.

I apologize for a lengthy post, but I hope this will eventually put some clarification for those, who are wondering about "wrong" MT-32 sound.

[Lukage]

The fix is so simple. And there was so much of someone else's code. The SysEx packets were in fact truncated in ALSA, and they were truncated because it was told them to do so....

In MidiLink source, please increase event buffer size in alsa.c, function snd_midi_event_new to some sane value (MUNT has 32768 total bytes SysEx buffer, but expects sizes no more than 1000 bytes in default).

Code: Select all

int alsa_open_seq(int _portNo, int _devNo)
{
    portNo = _portNo;
    devNo  = _devNo;
    misc_print(0, "Opening ALSA address --> %d:%d\n", portNo, devNo);
    if(snd_seq_open(&seq, "default", SND_SEQ_OPEN_DUPLEX, 0) < 0)
    {
        misc_print(0, "ERROR: snd_seq_open(%d, %d)\n", portNo, devNo);
        return FALSE;
    }
    alsa_reset_seq_event(&ev);
    snd_midi_event_new(256, &parser);
    return TRUE;
}

This fixes the whole mess, and large SysEx messages starts to generate events for MUNT to process, and you can enjoy your MT-32 music

[bbond007]

I apologize for a lengthy post, but I hope this will eventually put some clarification for those, who are wondering about "wrong" MT-32 sound.

Thanks for the lengthy post. It helped me identify and fix the problem. I simply initialized the parser encode buffer too small

https://github.com/bbond007/MiSTer_Midi ... d157ca822a

I was able to reproduce the problem with Dune2 and this does seem to fix it.

Could I get you to run this update script to confirm the bug is fixed?

https://github.com/bbond007/MiSTer_Midi ... updater.sh

Thanks!

[Newsdee]

I've found a really nice free soundfont: https://fatboy.site/
It claims to be made to work well with older MIDI games... and so far I'm pretty happy with it.

[Schyz]

Could I get you to run this update script to confirm the bug is fixed?

https://github.com/bbond007/MiSTer_Midi ... updater.sh

Thanks!

Hi,

I'm having issues getting MiSTer FPGA to talk to a Raspberry Pi running munt, (actually, running MT32-PI) and I was wondering if this change was actually in place for everybody.

EDIT: Just to clarify, my MT32-PI works fine with a real DOS machine, my MiSTer FPGA works fine with a real Roland device, but Mister + MT32-PI don't work togetther, there are hanging notes, notes that end too early, and some of the instruments don't sound right sometimes.

[bbond007]

I'm having issues getting MiSTer FPGA to talk to a Raspberry Pi running munt, (actually, running MT32-PI) and I was wondering if this change was actually in place for everybody.

This change will (likely) be in the next SD installer, so its not currently in place for everyone...

However, this bug will effect very few games...

Regardless, this change does not effect USB MIDI (just Munt running on HPS) so it would not effect real Roland hardware or MT32-PI...

[tlaloc]

I'm having issues getting MiSTer FPGA to talk to a Raspberry Pi running munt, (actually, running MT32-PI) and I was wondering if this change was actually in place for everybody.

This change will (likely) be in the next SD installer, so its not currently in place for everyone...

However, this bug will effect very few games...

Regardless, this change does not effect USB MIDI (just Munt running on HPS) so it would not effect real Roland hardware or MT32-PI...

Does the below SD installer update contain the change mentioned in this thread?
https://github.com/MiSTer-devel/SD-Inst ... 200908.rar

[bbond007]

Does the below SD installer update contain the change mentioned in this thread?
https://github.com/MiSTer-devel/SD-Inst ... 200908.rar

yes...

--> viewtopic.php?p=9994#p9994