CODEWITHSUNDEEP
linuxmidialsawinesniffing
ssokolow
ssokolow

Reputation: 15345

Bi-directional sniffing/snooping on an ALSA MIDI SysEx exchange

Does anyone know of a good way to get a bi-directional dump of MIDI SysEx data on Linux? (between a Yamaha PSR-E413 MIDI keyboard and a copy of the Yamaha MusicSoft Downloader running in Wine)

I'd like to reverse-engineer the protocol used to copy MIDI files to and from my keyboard's internal memory and, to do that, I need to do some recording of valid exchanges between the two.

The utility does work in Wine (with a little nudging) but I don't want to have to rely on a cheap, un-scriptable app in Wine when I could be using a FUSE filesystem.

Here's the current state of things:

Upvotes: 5

Views: 3466

Answers (4)

Keinstein
Keinstein

Reputation: 357

You could use virtual midi devices for this purpose. So you have to load snd_seq_dummy so that it creates at least two ports:

    $ sudo modprobe -r snd_seq_dummy
    $ sudo modprobe snd_seq_dummy ports=1 duplex=1

Then you should have a device named Midi through:

    $ aconnect -i -o -l
    client 0: 'System' [type=kernel]
        0 'Timer           '
        1 'Announce        '
    client 14: 'Midi Through' [type=kernel]
        0 'Midi Through Port-0:A'
        1 'Midi Through Port-0:B'
    client 131: 'VMPK Input' [type=user,pid=50369]
        0 'in              '
    client 132: 'VMPK Output' [type=user,pid=50369]
        0 'out             '

I will take the port and device numbers form this example. You have to inspect them yourself according to your setup.

Now you plug your favourate MIDI Device to the Midi Through ports:

    $ aconnect 132:0 14:0
    $ aconnect 14:0 131:0

At this time you have a connection where you can spy on both devices at the same time. You could use aseqdump to spy the MIDI conversation. There are different possibilities. I suggest to spy the connection between the loopback devices and the real device. This allows you for rawmidi connections to the loopback devices.

    $ aseqdump -p 14:0,132:0 | tee dump.log

Now everything is set up for use. You just have to be careful about port names in your MIDI application. It should read MIDI data from Midi Through Port-0:B and write data to Midi Through Port-0:B.

Some additional hint: You could use the graphical frontend patchage for connecting and inspecting the MIDI connections via drag and drop. If you do this you will see that every Midi Through port occurs twice once as input and once as output. Both have to be connected in order to make this setup work.

If you want to use GMidiMonitor or some other application you spy on both streams intermixed (without showing the direction) using aconnect suppose 129:0 is the Midi Monitor port :

    $ aconnect 14:0 129:0
    $ aconnect 132:0 129:0

If you want to have exact direction information you could add another GMidiMonitor instance that you connect only to one of the ports. The missing messages come from the other port.

Upvotes: 0

sheffler
sheffler

Reputation: 472

I like using aseqdump for that.

http://www.linuxcommand.org/man_pages/aseqdump1.html

Upvotes: 1

Alan Burlison
Alan Burlison

Reputation: 1052

What about using gmidimonitor? See http://home.gna.org/gmidimonitor/

Upvotes: -1

hiben
hiben

Reputation: 56

This question has been unanswered for some time and while I do not have an exact answer to your problem I maybe have something that can push you in the right direction (or maybe others with similar problems).

I had a similar albeit less complex problem when I wanted to sniff the data used to set and read presets on an Akai LPK25 MIDI keyboard. Similar to your setup the software to setup the keyboard can run in Wine but I also had no luck in finding a sniffer setup for Linux.

For the lack of an existing solution I rolled my own using ALSA MIDI routing over virmidi ports. I understand why you see them as useless because without additional software they cannot help at sniffing MIDI traffic.

My solution was programming a MIDI relay/bridge in Java where I read input from a virmidi port, display the data and send it further to the keyboard. The answer from the keyboard (if any) is also read, displayed and finally transmitted back to the virmidi port. The application in Wine can be setup to use the virmidi port for communication and in theory this process is completely transparent (except for potential latency issues). The application is written in a generic way and not hardcoded to my problem.

I was only dealing with SysEx messages of about 20 bytes length so I am not sure how well the software works for sniffing the transfer of large amounts of data. But maybe you can modify it / write your own program following the example.

Sources available here: https://github.com/hiben/MIDISpy

(Java 1.6, ant build file included, source is under BSD license)

Upvotes: 4

Related Questions