I have a Raspberry Pi 2

[danbee]

This looks like an awesome project, and I'd love to help you test it on my Raspberry Pi 2. Can I just download a regular release or do I need to do anything special?

[dwhinham]

Hi Dan - thanks, this would be really helpful!

Today I switched on Pi 2 builds in GitHub Actions, so whilst the current release (0.2.1) doesn't have a Pi 2 kernel inside the archive, they are available if you take a look in Actions, find the latest build, and download the sdcard artifact: https://github.com/dwhinham/mt32-pi/actions?query=workflow%3A%22mt32-pi+CI%22+branch%3Amaster

We're still trying to figure out what the best test would be - we've found that the mapmaker's theme in Monkey Island 2 can reveal stutters/pops as it has some nice sustained chords - but feel free to try anything!

I've had some feedback from @nswaldman about the Pi 2 and it looks like it can work, albeit with reduced samplerate and/or increased audio chunk size to avoid stuttering (at the cost of reduced quality and increased latency respectively). You can set these options in the mt32-pi.cfg file.

I don't think we've done any testing with overclocking yet though, so if you're feeling adventurous, it'd be great to see if a mild overclock could let the Pi 2 run with the same defaults as what we use on the Pi 3/4 (512 chunk size, 96000Hz, 'good' resampler quality).

[nswaldman]

Hey @danbee - I think @dwhinham already covered all important things with his reply, but I the least I can do is share my fiddling. I've been getting some good results by changing the vanilla cfg with the following three changes:

sample_rate = 32000
chunk_size = 3074
resampler_quality = none

This is on a regular Raspberry Pi 2 Model B with no overclocking whatsoever and it does have the occasional crackle/pop on the MI2 theme discussed above (again, a better benchmark is definitely welcome!)

I have to admit that I found no significant performance change between resampler_quality set to fastest and none, but at least we caught a bug that way 👍

[dwhinham]

Now that 0.7.0 is out, we have multi-core and ARM NEON optimizations enabled.

It may be possible that Raspberry Pi 2 performs better now and it definitely deserves re-testing.
I'd love to hear the results if someone wanted to step up to the plate.

We also have FluidSynth to try too, which should definitely work on slower hardware (as long as polyphony and SoundFont complexity aren't too high).

Perhaps start with completely stock settings and see how it fares.

[danbee]

I can certainly look into this again. Now I have the Pi-MIDI hat it should be much easier to test. I'll find some time to try it this week and let you know.

[danbee]

Finally got my MiSTer outputting MIDI to the Pi. First test with the Pi2 was Speedball 2 (which I didn't even realise had MT-32 support). So far everything is working perfectly! No dropouts or stuttering. Sample rate is set to 32,000hz and resampling is set to none. This is with mt32-pi 0.7.1.

I'll figure out how to get Monkey Island 2 working.

[danbee]

48,000hz and "good" resampling also works with no dropouts or stutters for Speedball 2

[danbee]

I'm hearing some crackles in the mapmakers theme on MI2 at 48,000hz and "good" resampling. I'll try and get a recording of it this weekend and see if overclocking helps.

[danbee]

No crackles or pops at 32,000hz with resampling turned off. Been listening to the mapmakers theme for the last five minutes...

[dwhinham]

Sorry for not replying to this, just revisiting some old issues.

Your testing sounds pretty positive; perhaps the Pi 2 can be upgraded to "compatible, but change xyz settings" status.

It sounds like mapmaker causes stuttering on Pi 2 with all audio-related options at defaults.
The defaults used to be 96000Hz/512 samples - now it's 48000/256 which is a bit more relaxed.

What if we apply an overclock in config.txt? These settings are part of an official preset from raspi-config for the Pi 2:

[pi2]

arm_freq=1000
core_freq=500
sdram_freq=500
over_voltage=2

Also, is your Pi 2 the original, or a v1.2?

The original has Cortex A7s at 900MHz, the v1.2 has Cortex A53s at 900Mhz (more like a Pi 3). This may have a significant impact; the A53 may be able to get away without an overclock.

From https://www.raspberrypi.org/forums/viewtopic.php?t=163856#p1058809:

The Cortex-A7 CPU is an ARMv7, which is purely 32-bit. The Cortex-A53 is an ARMv8A and has 64-bit instructions as well as 32-bit. At present, Raspbian is a 32-bit OS. The Cortex-A53 executes instructions faster than the A7. There have been some test results posted that indicate that the Pi2B v1.2 (aka Pi2B2) is about 20% faster than the v1.1 at the same clock speed. If the program makes heavy use of the NEON (SIMD, I think) instructions, you may see up to a 60% speed boost on the new board.

We definitely use NEON SIMD instructions.

IMHO, the goal is to find the minimum steps required to get Pi 2 stutter-free from a completely stock install.
If an overclock works, we could add a config.txt section exclusively for the Pi 2 that applies the overclock; the user wouldn't have to touch a thing and we can just add a "by the way, Pi 2 will be overclocked - stick a heatsink on it" to the docs. That said, maybe we don't want to overclock the v1.2 Pi 2 - unfortunately the config.txt filters can't differentiate them.

Otherwise, I can amend the docs to instruct the user to relax the samplerate, though this isn't very desirable - we have FluidSynth now and it'd be good to stay at 44100 or 48000.

[getdls]

Hi,
If this issue still is relevant I’ve got a Rbp 2 rev1 running

Setup:

• Mister running toslink to external dac
• mt32-pi hat on RPB2 revision 1, very short USB cable. (mister fpga uk, cheers), separate power supply to Pi
• Mt32 release v0.10.0, Mt32 romset “old”

No overclocking
“High” - Crackle on mapmaker all the time

sample_rate = 48000
chunk_size = 64
resampler_quality = best
(polyphony = 256)

“Default” - Crackle on mapmaker, ~ every 4th second
This is close to working

sample_rate = 48000
chunk_size = 256
resampler_quality = good
(polyphony = 64)

“Increase Cunk / latency” - Some crackle on mapmaker, around 16th beat”
Good enough

sample_rate = 48000
chunk_size = 512
resampler_quality = good
(polyphony = 64)

Overclocking

arm_freq=1000
#arm_freq_min=500
sdram_freq=500
over_voltage=2

“High” - Crackle on mapmaker all the time

sample_rate = 48000
chunk_size = 64
resampler_quality = best
(polyphony = 256)

“Resampler quality” - Some crackle on mapmaker, transitioning between indoor / outdoor

sample_rate = 48000
chunk_size = 256
resampler_quality = best
(polyphony = 256)

“Default on overclocked - Crackles around 16th beat”
Good enough

sample_rate = 48000
chunk_size = 256
resampler_quality = good
(polyphony = 64)

“Increase Chunk / latency overclocked” - No issues”

sample_rate = 48000
chunk_size = 512
resampler_quality = good
(polyphony = 64)

The test feels a bit arbitrary; anything on low enough latency will crackle... But then again, half of the reason I wanted a MT32 was for MI2, so I shouldn't be complaining :P

Anything else you’d like tested before I swap it out for a Rbp3?

Is there any benefit or downside from running 48000 on both mister and Mt32-pi, such as aliasing or noise?
Or are we better off running 32000 (64000?) Mt32 pi and 96000 on Mister?

[dwhinham]

Thanks for taking the time to test the Pi 2!

If I remember correctly, I was talking to @danbee in private some time ago and we worked out that everything in mt32-pi.cfg can be left at defaults except:

• FluidSynth polyphony reduced to 128
• A CPU overclock to 1200MHz (this matches the original Pi 3) - can't remember the exact config.txt settings

IMO it's probably not worth messing with any of the samplerate stuff unless you're trying to increase quality on a faster Pi - it doesn't seem to be hugely beneficial for performance. If you reduce the samplerate to 32000, you don't lose much on the MT-32 synth but I think you'll potentially lower the quality on FluidSynth depending on the SoundFonts used.

This MIDI is a good test case SoundFont mode - use GeneralUser GS (Chun-Li theme from X68000 SF2):
chunli.zip

When there's not enough CPU cycles you'll get stuttering in this MIDI almost instantly. Lowering the polyphony should fix it.

[gdjacobs]

Hey, Dave. I'm not directly involved in your project nor am I building an MT32-pi at the moment, but I did have some early skin in this game, in particular with the Pi 2 (although you've definitely taken things much further). For what little it's worth I created original Vogons thread concerning Munt implementation on the Pi (which then spread to Retropie among others).
https://www.vogons.org/viewtopic.php?t=46899

If you have the time, I've got a few questions I hope help me contrast MT32-pi's requirements and behavior with my experience.

I never tested MI2 as a load score. My go-to is Loom, specifically the Overture section starting at 0:50. The demand on Munt was substantial (much more than any of the other MIDI dumps I have on hand) and quickly apparent even when piping directly from the Pi CLI. As a point of reference, I was typically seeing 65-70% max load on one of the cores of the Pi 2 at stock clocks running Loom under Linux. I hope there's more efficiency to be extracted on this platform (which can be passed on elsewhere), but I want to replicate the testing parameters you use to make sure I'm looking at comparable results first. I'll make a point of testing MI2 myself, but, in your informed opinion, is MI2 more punishing in the more demanding sections than the Loom overture or is it comparable?

Noticing the issues you're having with Pi 2 performance, does your build resample in the mt32emu process or is it resampling via an external thread? Also, a quick comment. The SC-55 line topped out at 28 voice polyphony. XG Level 2 implemented in the MU80 required 64. While a reduction to 128 voices or even less is generally considered noticeable, I don't believe it to be a big sacrifice for retro gaming given the synth hardware commonly used in the pre-Windows gaming era. Slightly lower levels of polyphony will still sound really good and operate similar to period equipment. YMMV, etc.

Lastly, the Pi Zero 2 appears to be more robust CPU wise with slightly higher clock and higher IPC compared to the Pi 2. Assuming no power management and firmware issues, it should perform favourably even at stock clocks. If performance on the Pi 2 can be sorted without an overclock, that in principle will lead to an MT32-Pi solution without any further stress on the PZ2's thermals. The RAM pool is another limitation in particular for Fluidsynth, but good GM, GS, and Emu sound fonts are available at <100MiB and likely cover the needs of a large swath of users. Do you disagree with or have anything you'd like to add to this line of thought?

[dwhinham]

is MI2 more punishing in the more demanding sections than the Loom overture or is it comparable?

I've no idea, I haven't tried Loom. MI2/mapmaker theme will overwhelm the CPU and cause underruns at stock clocks on Pi 2, though remember mt32-pi is running with extremely small buffers and therefore tighter deadlines than what might be the case with Linux.

Noticing the issues you're having with Pi 2 performance, does your build resample in the mt32emu process or is it resampling via an external thread?

mt32-pi's baremetal environment does not have a concept of OS-level threads or processes, only cores. That said, all audio rendering, including any resampling, happens on the same core. Nothing else is allowed to happen on that core; it is 100% dedicated to the audio.

The SC-55 line topped out at 28 voice polyphony [...] Slightly lower levels of polyphony will still sound really good and operate similar to period equipment. YMMV, etc.

Yes, I'm aware of this and agree. For the latest release I lowered the default FluidSynth polyphony value to 200 so that the new Pi Zero 2W (which is same silicon as Pi 3 minus 200MHz) passes my tests. Honestly though, it could probably be a lot lower and no-one would notice.

Lastly, the Pi Zero 2 appears to be more robust CPU wise with slightly higher clock and higher IPC compared to the Pi 2.

Yes, it's similar to comparing Pi 2 vs Pi 3 - it's a huge step up.

...If performance on the Pi 2 can be sorted without an overclock, that in principle will lead to an MT32-Pi solution without any further stress on the PZ2's thermals.

Pi Zero 2W is a solved problem; as it's in the same performance ballpark as the Pi 3 there wasn't much to do. Like I say, there is a pretty big performance gap between Pi 2, with its 32bit 900MHz ARM v7 CPU (at least in the original model) versus the 64bit ARMv8 in the later models. mt32-pi is compiled as a native 64bit kernel for everything except Pi 2, which also helps. I don't have exact numbers but that alone gave me more headroom on the same target when it came to polyphony.

The RAM pool is another limitation in particular for Fluidsynth, but good GM, GS, and Emu sound fonts are available at <100MiB and likely cover the needs of a large swath of users. Do you disagree with or have anything you'd like to add to this line of thought?

Agreed. I (and others who I've talked to about this) am of the opinion that some of these SoundFonts that are hundreds and hundreds of megabytes large are simply mashups of sound sets that just seem to contain tons of samples for the sake of it. Without naming any of them in particular, they tend to be quite unbalanced and have some instruments that sound really out of place, etc. Whereas something like GeneralUser GS is only ~35MB, and sounds fantastic, because it has been carefully crafted by a musician.

But, that's just like, my opinion, man. 🙂

[gdjacobs]

MI2/mapmaker theme will overwhelm the CPU and cause underruns at stock clocks on Pi 2, though remember mt32-pi is running with extremely small buffers and therefore tighter deadlines than what might be the case with Linux.

Indeed, low latency can have it's costs. I'll do a comparison and see if the two scores have sections which can be compared apples to apples. I'll also look at tuning the sound stack on the Linux side for comparable test conditions vis-a-vis buffers.

mt32-pi's baremetal environment does not have a concept of OS-level threads or processes, only cores. That said, all audio rendering, including any resampling, happens on the same core. Nothing else is allowed to happen on that core; it is 100% dedicated to the audio.

Which gives you instant processor affinity. I'll have a look at the compute cost of resampling to see how much it's hogging. Might run it by Serge as well.

Yes, I'm aware of this and agree. For the latest release I lowered the default FluidSynth polyphony value to 200 so that the new Pi Zero 2W (which is same silicon as Pi 3 minus 200MHz) passes my tests. Honestly though, it could probably be a lot lower and no-one would notice.

I suspect 128 voice would be largely adequate given the XV5080 and MU2000EX operate with that limit, although there's certainly no harm in operating to the limit of the rendering hardware. The actual issue is the SF2 format. You need to stack multiple sound fonts to approach the sample selection commercial modules offer, which is actually what Zoltan (Falcosoft) did for FSMP. Of course, what's really far overdue is a more capable standard.

Yes, it's similar to comparing Pi 2 vs Pi 3 - it's a huge step up.

I estimated roughly 30% improved performance from IPC which is no joke.

Pi Zero 2W is a solved problem

Excellent news! I take it Munt didn't require any OC?

mt32-pi is compiled as a native 64bit kernel for everything except Pi 2, which also helps.

In more ways than one. They definitely rationalized the uarch in terms of required execution units with ARMv8. Optimized compiling for the BCM2836 is a real flag soup.

some of these SoundFonts that are hundreds and hundreds of megabytes large are simply mashups of sound sets that just seem to contain tons of samples for the sake of it.

The Katamari Damacy of wavetable synthesis.

[wattyka]

I was looking for something useful to do with my old PI2 B+ 1.1. So I tried the sdcard.zip from the latest build as mentioned above.

I connected a Win10 PC via CP2102 USBtoSerial to the Pi, a 16x2LCD with the I2C backpack and added the "standard" PI2 overclock to it:

[pi2]
arm_freq=1000
core_freq=500
sdram_freq=500
over_voltage=2

I also set the FluidSynth polyphony to 128 in the mt32-pi.cfg as mentioned above.

And it runs and sounds abolutely great with every File I threw at it so far (MidiPlay->loopMIDI->HairLess Midi->CP2102->RPI2 GPIO). I tried MT32 mode and FluidSynth with the various SC55 soundfonts. But there must be a reason why the PI2 is not officially supported? Is there anything known to not work or have sound issues? I'd like to hear that myself.

I'm very happy as it works right now. Tomorrow, I'll try one of those cheap PCM5102 DAC modules that have been collecting dust here. And a rotary encoder module. Once I've boxed this all up this is going to be a great MIDI synth for my retro PC builds.

[dwhinham]

Is there anything known to not work or have sound issues? I'd like to hear that myself.

Read the thread above, mapmaker's theme in Monkey Island 2 is the test I keep using...

Pi 2 is not officially supported simply because I don't have one to test the project with. I provide binaries that will run on the Pi 2 as part of every release, but the point of this thread is to try to establish what the best overclock settings are that work in all common scenarios. I am not comfortable calling it "supported" until this is known and verified.

[wattyka]

I looked into various MI2 midi packages, but it seems there is nothing called "mapmaker's theme". Any hints?

[dwhinham]

I don't have a .MID dump of the track, but it's quick and easy to get to, just start the game, use ESC repeatedly to skip all the intros and the bridge scene, and it's one of the first doors you come to.

This is the area you are looking for.

[wattyka]

Thanks! I'll try installing it. Which romset should I use to test? I'm asking because

https://en.wikipedia.org/wiki/List_of_MT-32-compatible_computer_games

says "Distorted/incorrect sounds on MT-32 'old'" for MI2

[dwhinham]

Don't worry about that too much, I don't notice any distortion on this song with 'old' at least. The distortion you get from a CPU being too slow is different and unrelated.

[wattyka]

I installed it in Dosbox and configured it to use the loopMidi device. Pretty simple. I still have this 5m USB cable with a CP2102 connected to the RPI GPIO and PWM sound from the 3.5mm jack. I'm using the "old" 1.07 romset.

Wow I don't think I've ever heard such beautiful tunes. I am speechless. I remember having played this game on the Amiga back in the 90s. But these MT32 tunes really add so much to the atmosphere of this game.

In the "mapmaker" room I don't hear anything unusual. Beautiful tune, no crackling or noise (besides the hissing/white noise of the PWM output). I need to figure out how to do a recording so one of you can confirm that it indeed sounds right.

Edit: OK I know what you're talking of now. Without the overclock, there is clearly a popping/crackling noise around every 15-20 seconds in this tune. It is reproducably gone with the overclock.

Anyway, this is a beautiful application for my old PI2. I just have to make myself a case.

[dwhinham]

Thanks for reporting back.

So 1000MHz is probably good for MT-32 mode.
For SoundFont mode, please test playback of this MIDI file: https://github.com/dwhinham/mt32-pi/files/6796949/chunli.zip
Make sure you are using the GeneralUser GS SoundFont.

If you hear stuttering, lower the polyphony value in mt32-pi.cfg until it plays without stuttering.
My guess is that 128 will probably be alright.