I have finally assembled an MT32-Pi by utilising a RPi3A+ and a Bulky MT32 Pi hat with a popular no name usb-midi cable (it was compliant with WinXP and Vista). The cable gets bound under Audio class, noting camdusbmidi.class on prefs/usb/devices. MT32 plays fine MT32 and Fluidsynth various Soundfonts, while cable leds also work (power and midi out - red/green when operating).

Every now and then I get a complete system freeze when I use midi. Specifically I have tested latest ScummVm (and an older version 2.5) with Monkey Island and the likes, plus Horny (including the latest beta executable). I have used both MorphOS 3.17 original and latest camd.library and class/usb/camdusbmidi.class as provided on BarsnPipes though I haven't been able to playback anything for the latter program (really weird gui :P).

I have tested the connection under an externally powered usb hub (d-link) which is connected to the onboard usb 1.1 of my Sawtooth PMAC, directly on the onboard usb 1.1 port and on USB 2.0 port of my NEC PCI.

Result is always the same, after 2-10 mins of midi playback, I get system freeze.

I also reduced baud rate of usb connection from MT32-Pi cfg, suspecting that it might reduce the interrupts (wild guess) but again it was a no-go.

SYS:Utilities/Midi/Midi Logger is also operational as far as I can tell.

I do get huge midi output on LogTool when I playback midi and also the following upon system boot:

29.196| camd.library - CreateMidiA - New MidiNode 0x156ee4f4
29.196| Signal bit: 30
29.196| camd.library - AddMidiLinkA - MidiLink Owernode 156ee584
29.196| camd.library - SetMidiLinkAttrsA: Midilink: 156ee574, Tags 15ab1df0
29.197| camd.library - SetMidiLinkAttrsA: 80000041:158f0834
29.197| camd.library - SetMidiLinkAttrsA - Creating cluster: USB Midi Cable.out
29.197| camd.library - SetMidiLinkAttrsA - Adding cluster 15a57a14 named USB Midi Cable.out
29.197| camd.library - SetMidiLinkAttrsA - Cluster: 15a57a14 (USB Midi Cable.out)
29.197| camd.library - SetMidiLinkAttrsA - Adding midilink 15a57a14 to cluster 156ee574 (USB Midi Cable.out) in mcl_Receivers
29.197| camd.library - AddMidiLinkA - Added MidiLink 156ee574 of type 0. Binded to MidiNode 156ee4f4
29.197| camd.library - AddMidiLinkA - MidiLink Owernode 156ee60c
29.197| camd.library - SetMidiLinkAttrsA: Midilink: 156ee5fc, Tags 15ab1df0
29.197| camd.library - SetMidiLinkAttrsA: 80000041:158f0944
29.197| camd.library - SetMidiLinkAttrsA - Creating cluster: USB Midi Cable.in
29.197| camd.library - SetMidiLinkAttrsA - Adding cluster 156ee684 named USB Midi Cable.in
29.197| camd.library - SetMidiLinkAttrsA - Cluster: 156ee684 (USB Midi Cable.in)
29.197| camd.library - SetMidiLinkAttrsA - Adding midilink 156ee684 to cluster 156ee5fc (USB Midi Cable.in) in mcl_Senders
29.198| camd.library - AddMidiLinkA - Added MidiLink 156ee5fc of type 1. Binded to MidiNode 156ee4f4

Any ideas? 'cause once you go midi, you cannot look back.

Hi,

You should not have such debug log. I guess you're using some released privately for testing purpose (TM) but not meant to be distributed camd.library/camdusbmidi.class. But this is probably not related to your system lock.

Other than that, it is hard to say why there is a system lock. Probably (and hopefully ^^) not directly related to camd#?.(library|class).

Do the system lock happens only when enabling midi in ScummVM?

Afaiu, ScummVM is making use of SDL2 layer which does the glue with CAMD.

Doing some dichotomic approch for finding the reason is probably a good start.

I would try the following:

1. get some 'good' midi file (ie: a MIDI file that does CC/PitchBend etc... that weight over 200KB to have quite some data to process). I can provide such midi file, the one I usually use for testing stuff.
2. open a shell
3. type something like

Code:

If this does not break your system, camd components can be excluded from the primary suspects of your system lock.

My camd setup just played a 20mn long MIDI song without any (visible) trouble.

If this test fails, please, install the official camd.library/camdusbmidi.class from MorphOS 3.17.

Thanks for the prompt reply man :)

Did some further tests and indeed when I switched from beta to original MorphOS 3.17 camd et al, debug logs stopped.

However, with beta camd.lib and class: RaspMidi works for 1 command each time and then I get a usb midi cable drop until it comes back to life automatically after a minute. With original camd from MorphOS 3.17 it doesn't work at all. The behaviour can be reproduced. I am in contact with Tolkien for a native port btw.

Edit: I received the native version and behaviour remains the same (kinda works with beta till it drops out, doesn't work with default at all).

Also, with original camd from MorphOS, I get system freeze under latest scummvm in less than a minute every time I fire up a camd game, so behaviour is much worse.

Can you pls upload a relevant midi file for me to test? I checked a random one from the net and it worked on both versions (but it was just 20kb).

Edit: Just had a system freeze when playing this midi tune with latest/beta camd. It happened at third or forth time I was playing it on repeat just by cli command.

[ Edited by Cool_amigaN 18.04.2023 - 00:33 ]

Quote:

You can test with this midi file:

https://tcheko.binaryriot.org/midi/echoes.midi