gdjacobs wrote:

I have other motives. It's handy for making one of my USB PCM/MIDI interfaces work. It only takes a single PCM format as input. JACK looks after format conversion, brilliantly at that.

I can certainly add jack support later, only problem is I don't know if Munt has jack support.
I think there's a ALSA to jack bridge I can use to get those to work. Might be worth a look after I get the SYSEX messaging figured out. I just got MUNT working so SYSEX triggered profile switching is the only bit left before I can start making tutorial youtube videos about it and start trying to make this project public.
I guess I'm also gonna have to figure out how to make a Ras Pi image, for those that don't want to compile all the code...
Not looking forward to dealing with having to host a 8gb img file. (Bittorrent maybe??)

Here's another quick brain dump for compilation notes for MUNT.

1## Setup development enviroment
2sudo apt update
3sudo apt install build-essential cmake libasound-dev libx11-dev libxpm-dev libxt-dev -yy
4
5## Download mt32emu, replace link with latest version...
6cd /usr/src
7sudo wget https://github.com/munt/munt/archive/munt_2_3_0.tar.gz
8sudo tar xzf munt_2_3_0.tar.gz
9cd munt-munt_2_3_0
10
11## Compile and install mt32emu
12sudo -s
13cd mt32emu
14cmake -DCMAKE_BUILD_TYPE:STRING=Release .
15make -j 4
16make install
17cd ..
18exit
19
20## Compile and install mt32emu alsa driver
21sudo -s
22cd mt32emu_alsadrv
23make -j 4
24make install
25cd ..
26exit

Using the -j 4 option I've managed to cut down the compilation time quite considerably, but it'll makes scripting the install script a bit harder when I get there.
maybe I'll just use a simple...
CPU_THREADS = $(nproc)
to the beginning of all the compile scripts and replace -j 4 with -j $CPU_THREADS

t9999clint wrote:

gdjacobs wrote:

I have other motives. It's handy for making one of my USB PCM/MIDI interfaces work. It only takes a single PCM format as input. JACK looks after format conversion, brilliantly at that.

I can certainly add jack support later, only problem is I don't know if Munt has jack support.

I can't remember if I use the ALSA bridge for this. I'll check.

I've been running some more tests to make sure munt is working properly and it seems to be stuttering with everything I try it with. My pi doesn't seem fast enough, I wonder if I'm running into a issue with amperage...
Or maybe I need to roll back to an earlier build of munt.
Looks like more testing is required... -_-
Is Silpheed just a really demanding game or am I doing something wrong here...

What version of Pi? What C flags are you using? Also, under voltage can definitely be an issue with inadequate supplies.

Loom is the most demanding game I'm aware of, although I haven't tested Silpheed.

gdjacobs wrote:

What version of Pi? What C flags are you using? Also, under voltage can definitely be an issue with inadequate supplies.

Loom is the most demanding game I'm aware of, although I haven't tested Silpheed.

OK, I'll start testing with Loom if I ever get Silpheed running.
It's a Ras Pi 3 B+
optimizations are...
export CCFLAGS="-Ofast -march=armv8-a+crc -mtune=cortex-a53 -mfpu=neon-fp-armv8 -mfloat-abi=hard -ftree-vectorize -funsafe-math-optimizations"
export CXXFLAGS="-Ofast -march=armv8-a+crc -mtune=cortex-a53 -mfpu=neon-fp-armv8 -mfloat-abi=hard -ftree-vectorize -funsafe-math-optimizations"

I've tried to use the same version of munt that you used in your project and it didn't make a difference so it's not a munt performance regression issue.

I don't have a proper raspi psu, I'm just plugging it into my powered USB hub so I'm guessing that's the issue. I'm going to see if I can jerryrig something today by tying it into the 5v rail on the computer's PSU, as I was planning on doing this anyway when I mount it to the soundcard.

Yes, if you're undervolting, you'll get all kinds of buffer under runs. Everything else looks good (enabling neon math being most important) so I agree, that's most likely the issue.

I just got a beefy USB wall charger and that worked fine. Be cautious if you're feeding 5V directly to the GPIO supply pin as that bypasses the protection circuit onboard.

gdjacobs wrote:

Yes, if you're undervolting, you'll get all kinds of buffer under runs. Everything else looks good (enabling neon math being most important) so I agree, that's most likely the issue.

I just got a beefy USB wall charger and that worked fine. Be cautious if you're feeding 5V directly to the GPIO supply pin as that bypasses the protection circuit onboard.

Thanks for the warning, I'll keep that in mind, it's a fairly new corsair 80plus silver rated psu so it should be stable enough for me not to worry about it.

Nope, still doing it, even after making sure it's properly powered. Although it does seem to behave slightly better now.
I'm going to test with loom and see if it's just something that Silpheed does.
*edit* Monkey's Island 2 and Loom both do it.
I wonder if I'm using the right compilation settings...

Specifying -mcpu=cortex-a53 is enough to select appropriate options for registers and the neon unit on a Raspi 3. I believe -Ofast specifies unsafe optimizations implicitly as well (compared to more conservative settings, it does break IEEE floating point).

Does one CPU core peg when you're running Loom?

gdjacobs wrote:

Specifying -mcpu=cortex-a53 is enough to select appropriate options for registers and the neon unit on a Raspi 3. I believe -Ofast specifies unsafe optimizations implicitly as well (compared to more conservative settings, it does break IEEE floating point).

Does one CPU core peg when you're running Loom?

yeah one core is pegged basically as soon as I start any game.
Sometimes it plays fine for a few seconds, but then it starts to stutter and play in slow motion, then it just starts cutting out.
I tried the -mcpu=cortex-a53 option already. I'm wondering if I should try an older version of rasbian. What version were you on when you had it running on your board?

I was tracking Debian Jessie.

gdjacobs wrote:

I was tracking Debian Jessie.

That could be something, maybe raspbian has some sort of service or driver running in the background that's preventing mt32d from running properly...
or it could be something I did... that's still possible.

Time to switch to debian

Still the same in debian. I've been checking the logs and whatnot, and raspbian is still reporting power issues, so somehow my molex adapter isn't giving enough power... I always thought the 5v rail had something like a 16a limit on a PSU, but I guess I'm wrong. Anyways I ordered in a proper PSU for testing, and I guess I'll have to add a 7805 or something to the BOM and start using the 12v rail instead on the final design.

7805 or a buck circuit. The 5V rail might have sagged enough to be below the threshold where the Pi is happy (which in my experience doesn't require much droop to complain).

hmm it being overly picky with voltage drops could explain some things. I did some more testing with my PSU and it's providing WAAY more than the 2.5amps needed, it maxed out my cheap multimeter. (thanks Canadian Tire) Maybe what's needed isn't a 7805 or buck circuit, but just a beefy capacitor.
I might need to ask a engineer buddy of mine to recommend a good/cheap cap to use to smooth out the drops and maybe get back to a solid 5v.

yeah this is getting beyond my knowledge here...
I'm trying to wire a 7805 (That I had laying around already) to provide some 5v using the 12v rail from my computer's PSU, but the 7805's are just overheating and turning itself off.
I ran a cap on to be parallel to the input and the output sides, and it does provide a clean 5v for about 20 sec... I think the 7805 must be drawing too much power from the 12v line. I guess I need a resistor or something between the 12v and my circutboard to limit how much power it's allowed to take.
I'm gonna check out some documentation cause I clearly don't know what I'm doing... (Software guy)

*edit* I figured it out, I had it wired correctly. It's just that Linear converters are far to inefficient to properly power a ras pi 3 b+ without overheating. I also tried running a few of them in parallel, but I started running into the limits of the wiring (*fire*/*loss of magic smoke*).

Yeah, I'm gonna need a buck converter or two... *edit*

Linear convertors like the 7805 don't really like being connected in parallel... but it sounds like you already figured that out. You *can* tie them together with diodes, but then you need another diode on their earth to compensate for the voltage loss.

jmarsh wrote:

Linear convertors like the 7805 don't really like being connected in parallel... but it sounds like you already figured that out. You *can* tie them together with diodes, but then you need another diode on their earth to compensate for the voltage loss.

Hmm I do have a few diodes I can try that with. Starting to run out of my jumper wires though...

I'm glad I went with these cheap ones, I'd rather they go than anything important.

k I just tried that, better results the ras pi liked the voltages a little better....
For about 30sec longer than before, still overheated, still dropped voltage. I don't think 7805's are the right tool for the job. No fire though 😀

Bottom is 12v top is 5v

You cannot use 7805 or other linear regulators in parallel fashion without a current sharing mechanism such as resistors (several watt 1ohm things for example) and even then you waste a some power in regulators fighting each other and losses in those resistors. Diodes will not do anything useful either except drop voltage, and such small diodes are gonna drop a whole volt under load while not helping much at all with the load sharing problem.