[alsa-devel] Must MIDI SysEx data contain the start byte 0xf0 and the end byte 0xf7?
Hi,
I've read about SysEx continuations aka. divided SysEx http://www.allegro.cc/forums/thread/607445 http://www.sonicspot.com/guide/midifiles.html
What it means is that within a MIDI file, a long sysex could be split across several events with different delta times, giving the receiver some processing time in between (e.g. flash EEPROM etc.). The delta times tell when to send the parts.
Now, is that truth? How to do that with ALSA? The documentation on snd_seq_ev_set_sysex insists: "the sysex data must contain the start byte 0xf0 and the end byte 0xf7." http://www.alsa-project.org/alsa-doc/alsa-lib/group___seq_middle.html#ga1048...
Would it be the sole business of the low-level ALSA driver to slowly send large (and complete) sysex data, out of application control (e.g. the delta times would get lost)?
Should apps always coalesce partial sysex data and hand out the complete blob to ALSA's snd_seq_ev_set_sysex?
Is divided SysEx too rare to worry about?
I'm asking because we've seen a user of Wine & KORG stumble upon a non-F7-terminated SysEx.
Regards, Jörg Höhle
Joerg-Cyril.Hoehle@t-systems.com wrote:
I've read about SysEx continuations aka. divided SysEx http://www.allegro.cc/forums/thread/607445 http://www.sonicspot.com/guide/midifiles.html
What it means is that within a MIDI file, a long sysex could be split across several events with different delta times, giving the receiver some processing time in between (e.g. flash EEPROM etc.). The delta times tell when to send the parts.
Now, is that truth? How to do that with ALSA?
Just put the partial chunks into separate events. The first must begin with the F0 byte, the last end with F7. (This is not actually checked; you can put arbitrary bytes into SysEx event data.)
The documentation on snd_seq_ev_set_sysex insists: "the sysex data must contain the start byte 0xf0 and the end byte 0xf7."
This is wrong. For that matter, when the sequencer receives from the hardware a SysEx that is too large for its internal buffer, it will split it into pieces.
Regards, Clemens
Clemens,
Just put the partial chunks into separate events. The first must begin with the F0 byte, the last end with F7.
Thank you. So the F7 continuation event / status byte solely exists in MIDI files, but not as an intermediate sub-packet starter on the wire.
For that matter, when the sequencer receives from the hardware a SysEx that is too large for its internal buffer, it will split it into pieces.
I already knew about split packets while recording, but I'm surprised that you talk about recording since I solely mentioned sending via ALSA.
Well, I came across the May 2007 thread "midiOutLongMsg Splitting Sysex Messages??" https://groups.google.com/forum/?fromgroups=#!topic/mididev/1AKG62CGaP0
D>For example, if midiOutLongMsg is called with the data D><F0 00 11 22 33 44 55 66 77 F7> and if some driver cannot allocate D>memory in chunks larger than 8 bytes, the result will be two blocks of D>data, i.e., <F0 00 11 22 33 44 55 66> and <77 F7>.
A>To send such large [150kB] messages with midiOutLongMsg, the A>application has to split it up into several buffers.
As you may know, my context is implementing audio in Wine, and I'm precisely wondering whether Wine's auto-adding F0/F7 around SysEx messages (when missing) is TRT. Now I seriously doubt it.
I interpret your sentence A to imply that midiOutLongMsg will not add such bounds, expecting the app to correctly manage F0/F7 such that precisely, the app has the freedom to insert as many pauses and split into packets as small as it wants, i.e. call midiOutLongMSg(lpData=F0 00 11 22 33 44 55 66) and midiOutLongMsg(77 F7), to keep your 2007 example.
Regards, Jörg Höhle
Joerg-Cyril.Hoehle@t-systems.com wrote:
Just put the partial chunks into separate events. The first must begin with the F0 byte, the last end with F7.
So the F7 continuation event / status byte solely exists in MIDI files, but not as an intermediate sub-packet starter on the wire.
Yes.
I'm precisely wondering whether Wine's auto-adding F0/F7 around SysEx messages (when missing) is TRT. Now I seriously doubt it.
TRT is whatever Windows does. According to the docs, it doesn't: | If you are using multiple data blocks to send a single system-exclusive | message ... http://msdn.microsoft.com/en-us/library/windows/desktop/dd798657(v=vs.85).aspx
Regards, Clemens
participants (2)
-
Clemens Ladisch -
Joerg-Cyril.Hoehle＠t-systems.com