So, inspired by the HardMPU project undertaken by ab0tj, as well as the likes of Dreamblaster and especially the recent discussions around the use of a Raspberry Pi 3 as a MUNT host, I have decided to develop and produce (at least some prototypes) an MT-32 WaveBlaster Card.

No, the plan is not to simply attach a Raspberry Pi 3 to the WaveBlaster header... my plan is slightly more involved, but I will admit the thought crossed my mind. I am currently debating between a Broadcom BCM2835 (aka. Raspberry Pi Zero) and Allwinner H2+ (aka. Orange Pi Zero) as the core CPU/SoC. Definitely a Atmega 328 or similar as a MIDI interface, although I will probably try wiring the MIDI signal directly to the SoC, just to see how that works out. Based on my readings, I can expect about 500mA to be available to the card from the WaveBlaster header, which is nothing to shake a stick at, but can be a limiting factor, hence the choice in processor. The Broadcom sips a mere 50-100mA (depending on configuration) where the Allwinner consumes 200-400mA (again, depending on configuration), but the Allwinner has a much better audio output than the Broadcom. The Allwinner also is a quad core... Broadcom a single core, but otherwise nearly identical ARM processor. MUNT is not a particularly multi-threaded process, so I'm not sure if that's much of a deciding factor.

I thought about making a standalone MIDI unit... essentially a modern made MT-32 (albeit somewhat emulated)... but after thinking about it I think the WaveBlaster card is both more challenging (a good thing, in my books) and more versatile. One could simply use a unit like Dreamblaster's WaveBlaster Module MIDI Interface Board to turn it into a standalone unit and, when used as a WaveBlaster board attached to a compatible sound card, it all fits neatly inside your computer case.

I think the really ambitious part of this project is how I'm hoping to allow the user to interact with the card. I could go the same route as the Dreamblaster X2 and provide a USB interface to manipulate files and configuration (which, by the way, very clever, props to Dreamblaster), but I believe I can get it to work via special MIDI SysEx messages from the host system itself (a special interface program would be required on both the host system and card, of course).

One of the main things that would need to be able to be accomplished through the host-card interface is the ability to upload ROM files to it. I'm not 100% sure, but I think there would be some questionable legal issues distributing Roland ROM files with the card.

Anyway, that's my retro-oriented activity that I think is going to occupy me for the next couple of months. Look forward to your thoughts and suggestions.

gdjacobs wrote:I suspect that the Pi Zero will not be capable of emulating the MT-32 without substantial software development. A Cortex A7 can manage this using Munt, so maybe you can look in that direction?

I'm a little afraid of this as well... I plan on initially trying the Pi Zero to see if I can get it to work, as that is by far the most power concious option. Barring that, I'll try the Orange Pi Zero, which is Cortex A7, and go from there. Anything more I'm afraid I'll get over 500mA.

shock__ wrote:Having the emulator run bare bones pretty much any semi-recent RasPi should be enough. This would also help with a potentially 'long' bootup time.

I think so too, which is why I'd like to try the Broadcom/RaspPi Zero first and then have the Allwinner H2+ Cortex A7 as second choice. Good thing I'm a Linux developer by trade!

keropi wrote:I don't see why power is an issue in an internal device - just use a floppy/hdd style molex and problem is solved...

Yeah, this did cross my mind, and am buying the parts to prototype this method as well, but my thought process is about trying to keep this as simple and self-contained as possible though, and potentially useful with other external modules like the Dreamblaster's WaveBlaster Module MIDI Interface Board... although that said, my idea for bidirectional host-card communication through MIDI SysEx messages wouldn't work with the WaveBlaster Module MIDI Interface Board anyway, so... I dunno.

Bottom line, still trying to flush this out, so these suggestions are quite welcome.

PhilsComputerLab wrote:I would love to see something like the NES mini, but for MT-32.

This would be the way to go IMO - in my mind a wavetable header is for a GM device, and doesn't really appear on sound cards of the MT-32 era. It would also mean you had to choose b/w your fave GM daughterboard and MT-32 (or physically switch 'em); better to leave the wavetable header for GM and keep any MT-32 device as external me thinks.

badmojo wrote:This would be the way to go IMO - in my mind a wavetable header is for a GM device, and doesn't really appear on sound cards of the MT-32 era. It would also mean you had to choose b/w your fave GM daughterboard and MT-32 (or physically switch 'em); better to leave the wavetable header for GM and keep any MT-32 device as external me thinks.

I don't disagree with this viewpoint. I have toyed with the idea that you could switch the module from "MT-32 mode" to "GM mode" using tmidity++ or something providing thr ability to upload user SoundFonts... and I still might, but I think for now the focus will be to get MT-32 mode going. I think your point about people have their favorite (non emulated) WaveBlaster card is a valid one.

I think based on this and Phil's comment, I might gear it towards a WaveBalster card (for some reason this idea is sticking with me, but I'm getting less convinced) with an external stand-alone housing the card can be inserted into to provide the famed LCD and standard MIDI interfaces.

One of the reasons I'd like to keep it under 500mA draw is that it could be powered entirely by the host's DB15 gameport connector without the need for external power supply. I'm not hard set on that idea but I think it would be neat.

brostenen wrote: How about porting munt on a barebone linux kernel?(this might not be possible)

Essentially what I feel I will need to do in oder to get it to run well on the RaspPi Zero is to have running the Linux kernel, and only what is required for it, and then the only user space applications that will be running is MUNT, ALSA, and my modified ttymidi for host-card control and monitoring; probably a shell running on ttyS0, but definitely nothing beyond that (especially nothing related to X or any GUI). I may have to modify MUNT to decouple it from Qt (and therefore decouple it from X) but there is a library version of MUNT that may prove useful in this regard.

EDIT: Even then I'm not sure how well it will run..Time to get started I guess...

I can probably help give you a head-start on this on the software side.

I've put together a MUNT/Raspberry Pi 2 system with Buildroot, which is a tool that lets you easily create embedded Linux distributions stripped down to the bare minimum and customised however you like it. With it, you can create a small SD card image that boots a Pi in about 5 seconds to a working MUNT.

I've got it so that you can download Buildroot, clone a Git repository, put some MT-32 ROMs into a designated folder, run 'make', and a flashable SD card image is produced. It takes quite a while to build because the entire toolchain and system needs to be compiled, but subsequent modifications are faster. It makes building a totally custom Linux very straightforward.

It needs work to deal with MIDI ports, sound output device (e.g. when using USB audio and MIDI interfaces) - but it's a good starting point. I'm wanting to get the latency down to the absolute minimum possible, and there's even the option of using a PREEMPT_RT (realtime) kernel, but I'm having pretty good results without that so far.

My intention was to make a standalone 'appliance' type setup with a 3.2" LCD touchscreen sitting on top of the Pi to act as a UI and control method for MUNT, but you can simply omit this for an internal Waveblaster project.

I'll put this project up on GitHub shortly - I got sidetracked with University exams (still ongoing )

keropi wrote:Isn't there a thread here about munt and Pi boards? IIRC only the Pi3 is powerful enough for it...

Yes, this thread was quite recent and I've followed it quite closely. The requirement for using the Pi3 was I think both out of convenience as well as necessity, as the people that were trying this out were running default Rasbian images with full GUI, other applications simultaneously, etc.. A full GUI (nor default Rasbian image) is required in this case. I'm reasonably confident it will run sufficiently on a Raspberry Pi Zero using an extremely cut-down image. But, as mentioned in the original post, I am not putting all my eggs in one basket, so to speak; I will also try the Orange Pi Zero (Allwinner H2+ Cortex A7) which I am sure will run MUNT without breaking a sweat, especially on a cut-down image.

d0pefish wrote:I've put together a MUNT/Raspberry Pi 2 system with Buildroot, which is a tool that lets you easily create embedded Linux distributions stripped down to the bare minimum and customised however you like it. With it, you can create a small SD card image that boots a Pi in about 5 seconds to a working MUNT.

I have quite a bit of experience with assembling custom Linux installations for both embedded and non-embedded deployments, so I'm pretty confident in my own ability, however I've not ever used Buildroot (I only have one Raspberry Pi that I've played with so far). I'm curious to try it now to see how it compares to what I would do manually. My suspicion is that it would be about the same, maybe a bit better. I'm interested to see what your build looks like as well; if MUNT runs well on the Raspberry Pi 2, that makes me all the more confident it will run well on the Zero.

RJDog wrote:I have quite a bit of experience with assembling custom Linux installations for both embedded and non-embedded deployments, so I'm pretty confident in my own ability, however I've not ever used Buildroot (I only have one Raspberry Pi that I've played with so far). I'm curious to try it now to see how it compares to what I would do manually. My suspicion is that it would be about the same, maybe a bit better. I'm interested to see what your build looks like as well; if MUNT runs well on the Raspberry Pi 2, that makes me all the more confident it will run well on the Zero.

Fair enough. I'd highly recommend looking at Buildroot, it is very flexible, and you can structure your project so that it's easy to maintain. You can start with a basic Pi kernel and that gets you a bootable BusyBox image, and work from there, selecting what gets built, adding things to your rootfs, changing kernel config, and so on. I added custom packages to pull in MUNT and build the command-line daemon with the toolchain (I don't build any GUI stuff at all in this).

There are template configs in Buildroot for all Pi models including Zero.

Current problem is that MIDI note timing is off; the sound generation itself doesn't experience any underruns but when a bunch of MIDI notes come in quick succession they seem to lag behind. I don't know if anyone else experienced this in the original thread, as the MIDI code for Qt MUNT may be better, but I haven't dove into the mt32d code yet (it's supposed to be deprecated anyway).

d0pefish wrote:I don't know if anyone else experienced this in the original thread, as the MIDI code for Qt MUNT may be better, but I haven't dove into the mt32d code yet (it's supposed to be deprecated anyway).

how are you reading midi? is it external fed into the pi uart? if so, make sure the pi uart is the correct speed, in order to get it so, you have to (on the pi3) disable the bluetooth on main uart,, switch gpio with a boot loader overlay to get full uart back on gpio, and change the clock speed so you can get correct midi speed with much less margin of error (than if you hadnt changed the uart clock speed)

I'm using a USB MIDI interface, so I'm not hitting the GPIO, and the speed issues are there when outputting with internal audio and USB audio (I have a few different kinds of USB audio device).

I totally agree with disregarding the internal audio - it is dreadful. There's a nasty aliasing hiss even when MUNT is idle, whereas even the most basic USB soundcard produces much nicer output. Additionally, it can't operate at lower latencies because of its design. I have been using MUNT at 5ms buffers without any clicks or pops with USB audio, but internal audio needs something like 10 to not underrun.

I think this is a software issue - remember I'm not using the desktop Qt version of munt; I'm using mt32d which is inside the 'mt32emu_alsadrv' directory of the MUNT repository. It hits ALSA directly and has no JACK/PulseAudio support. I'll try and debug this at some point.